git 分支整合問題
科技新知
MacauYeah・2024-02-20
不知道大家的開發團隊、專案規模有多大，但只要系統或程式已發佈，同時又要做維護更新，git 庫都至少會有兩條分枝： 新功能 main feature 最新的穩定發佈版本 Release v1.x.x 最好的情況下，在開發完新功能之前，穩定版本都沒有需要緊急修正的地方，開發者可以專心開發新功能（main feature。然而這個情況並不能經常維持。 情況1有Bug要馬上修正 最常見到的情況，就是穩定發佈版本有瑕疵，可以經過小修小改來止血，由v1.x.x rArr; v1.x.y，這些可能對用戶來說，是沒有太大感覺的改動。不過對於開發流程，就免不了由v1.x.y整合（merge）回main時，出現修改衝突的問題。 建議 若屬於日後不再需要的改動，不需於整合到main中， 當然什麼都不用做。但若屬於必要的更新，就需要早早整合到main中。整合雖然痛苦，但延後整合沒有好處。以筆者的經驗，每次整合時有衝突，而越早整合越有條件知道該取用自動混合的那個版本。以整合工具的語言來說，就是更容易的作出use mine use theirs edit。 情況2 不同功能之間有衝突 上述情況1，已經算是可控的。主要因為穩定發佈版本都只會接受小修小改，大改都會直接在main中開當為新功能開發。當你有多個很重要的功能在不同時期被提出，而有些功能你沒有信心在下個發佈中提出，你就會選擇以獨立分支來實現不同的功能，最後選擇信心度高、權重也比較高的功能來發佈。這樣的好處是你可以有限時間先完成最必要的功能，但問題是多個功能分支之間，更容易地有衝突，後期也需要很廢心力地整合。 建議 少做資料夾層面的改動，因為git rename的功能並不是萬能的，會令很多git自動選擇版變得不可讀。筆者的經驗，就是錯把後端和前端的資料夾混在一起，令後端的一些重命名影響到前端。前端也因為有重寫的需要，對資料夾結構大改。最後結果就是很多看不懂的git自動選擇版。有一些有選對，但有一些就選錯。 可以做一些事前處理，來減經痛苦。在筆者的資料夾問題情境，在把後端將要整合的多個commit中，挑選最早前沒有命名問題的commit先整合一次。然後前端先手動模擬後端的人工命名，自行commit一次，最後再把後端剩餘的commit再做整合。這個做法不是完全解決問題，但至少可以讓use mine use theirs edit更新易理解。 而另一個建議是，縮短發佈週期，逼使其他開發中的功能越早做整合，也逼使每個功能不要做太大規模的改動。如果真的做大規模改動，就要有心理準備要多次重要的整合。 情況3 多個穩定發佈版本需要同時維護 若然大家面對的工作規模真的很大，同時有多個版運行版本，就如gitlab，每一個月都有一個新功能版本16.0.x, 16.1.x, 16.2.x,hellip; 16.9.x，但它不會強逼大家更新，對於過去一段時間的功能版本，也會推出安全性更新前述的x會不斷修正問題。 這是一個很負責任的發佈模式，不過對於開發者來講就一定很地獄。因為16.0.x的安全更新並不能無痛地整合到16.9.x中，可能每個版本重新人工修改還要來得穩健。 建議 各個分支人工修改可能更適合。最後就是取決於商業政策的考量，到底公司願意為已發佈的功能版本提供多久的支援。就以gitlab為例，其實它也只承諾維持兩三個月前的功能版本。是否會backport到多個月之前的版本，就看問題的嚴重性和backport難易度。 也分享一些筆者朋友的經驗，他們開發的是軟件跟硬件整理的軟件庫。但因為硬件有限制，例如庫的大小、算力的差異，所以最後分支多到爆炸。這也是軟硬整合的痛，問題暫時無解。除非老闆肯放棄市場。
LifeMag Editor・2015-12-31
Lifemagshopper・2021-03-09
文創遊樂場 // 米米 Esther Lim・2020-01-05
Cheers!・2022-05-30
君尋・2021-03-22
澳門生活圈・2019-08-23
StanSteve・2017-09-15
半島師奶・2020-02-04
Benjamin・2016-06-01