科技新知
git 分支整合問題
不知道大家的開發團隊、專案規模有多大，但只要系統或程式已發佈，同時又要做維護更新，git 庫都至少會有兩條分枝：
- 新功能 - main / feature
- 最新的穩定發佈版本 - Release / v1.x.x
最好的情況下，在開發完新功能之前，穩定版本都沒有需要緊急修正的地方，開發者可以專心開發新功能（main / feature)。然而這個情況並不能經常維持。
情況1:有Bug要馬上修正
最常見到的情況，就是穩定發佈版本有瑕疵，可以經過小修小改來止血，由v1.x.x ⇒ 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,… 16.9.x)，但它不會強逼大家更新，對於過去一段時間的功能版本，也會推出安全性更新(前述的x會不斷修正問題)。
這是一個很負責任的發佈模式，不過對於開發者來講就一定很地獄。因為16.0.x的安全更新並不能無痛地整合到16.9.x中，可能每個版本重新人工修改還要來得穩健。
建議
各個分支人工修改可能更適合。最後就是取決於商業政策的考量，到底公司願意為已發佈的功能版本提供多久的支援。就以gitlab為例，其實它也只承諾維持兩三個月前的功能版本。是否會backport到多個月之前的版本，就看問題的嚴重性和backport難易度。
也分享一些筆者朋友的經驗，他們開發的是軟件跟硬件整理的軟件庫。但因為硬件有限制，例如庫的大小、算力的差異，所以最後分支多到爆炸。這也是軟硬整合的痛，問題暫時無解。除非老闆肯放棄市場。
