延續 Day 4 最後提到的問題：當完成手上的任務後，其他開發者就能立刻取得並使用修改後的程式嗎？
程式可能還在自己的分支上尚未合併；也可能已經合併，但還在等整合驗證；甚至只存在自己的電腦裡，還沒分享出去。自己寫好的程式，其他人不一定能立刻取得並使用；相反地，別人完成的程式也是如此。
自己的修改要讓其他人使用，可能還需要討論需求、調整程式，以及驗證組合後的行為。我們可以用「距離」來理解從各自修改到程式可以一起使用之間，還沒完成的這些事情。
圖中的模組 A 和模組 B 各自完成後，還需要處理差異、確認組合後的行為，才能讓這些模組一起運作。
回到「改 A 壞 B」的例子，A 修改了共用功能，B 卻還依賴原本的行為。如果雙方在修改時就一起確認需求，就有機會提早發現這個差異，討論兩邊要如何配合。
但如果一直沒有討論，也沒有整合，雙方繼續依照各自的版本開發，後來新增的程式就有機會依賴更多不同的行為。等到真的要整合的時候，除了原本的共用功能，也可能需要調整這些後來的程式。
另一個問題是重複開發。假設兩位開發者都需要同一項共用功能，卻不知道對方已經在做，就可能各自完成一份。等到要一起使用時，除了決定保留哪一份，也要確認呼叫這些功能的程式是否需要調整。
各自開發卻沒有及早交流，可能讓需求差異與重複開發的問題，直到整合時才被發現。這些就是「距離」帶來的具體問題。
從各自開發到其他人實際使用，中間可能因為需求、修改範圍或發布規劃而延後整合，也可能還在等待審查、驗證與同步。
一個原因是需求還沒談清楚。尤其是共用功能，不同開發者可能有不同的使用方式。如果還不知道需要滿足哪些行為，就很難決定程式要如何修改，也無法確認整合後的結果是否符合雙方需求。
另一個原因是修改範圍太大。一次調整多個模組，其中一部分還沒完成，其他部分又依賴這些修改，就可能需要等整份修改完成後，才能一起驗證。即使其中已有別人需要的功能，也還無法直接拿出來使用。
團隊的發布規劃，也可能影響合併的時機。例如，為了穩定準備發布的版本，團隊可能會暫時限制程式變更，也就是「凍版（Code Freeze）」。其他仍在開發的程式會因此被迫留在分支上，即使其中已有其他開發者需要的部分，也會延後合併。
即使程式已經寫好，審查與驗證也需要時間。審查者可能還沒空確認，或開發者需要依照意見修改、再請對方確認；建置驗證如果失敗，也需要找出原因、修改並重新驗證，其他人可能因此繼續等待。
即使共同版本已經通過必要驗證，其他開發者如果還沒同步，仍然會按照舊版本繼續開發。取得更新後，也需要確認這些提交與手上的程式整合後是否符合預期。
要縮短距離，需要讓討論與問題處理提早進行，必要的審查與驗證仍然要完成。
團隊決定是否合併時，不同角色會有不同的考量。產品經理可能關注發布範圍，開發者需要確認對其他功能的影響，審查者則會考慮後續維護的成本。
假設開發者提出一個拉取請求（Pull Request，簡稱 PR），功能已經能執行，但沒有注意到程式累積了不少技術債。審查者看見其中會增加後續理解、測試或修改成本的設計，因此要求先調整再合併。開發者認為功能已經完成，審查者則認為還需要處理維護問題，雙方對合併時機的判斷因此不同。
在這個情境裡，延後合併可以暫時避免維護問題進入共同版本。不過，如果其他人在這段期間繼續修改相關功能，之後整合時，就可能需要一起處理新增的差異。因此，團隊需要一起確認哪些問題必須先處理，以及完成哪些調整與驗證後就可以合併。
下圖整理了幾種延後合併的考量。
Trunk Based Development 的五分鐘概覽，一開始談的就是開發者之間的距離，並引用了 Frank Compagner 的這句話：
Branches create distance between developers and we do not want that
— Frank Compagner, Guerrilla Games
也就是「分支會在開發者之間造成距離，而這不是我們想要的」。
前面談了這麼多，從各自寫好程式，到其他人可以一起使用，中間的這段距離，正是主幹開發在意的事。
主幹開發追求的是縮短這段距離。如何處理讓團隊延後合併的問題，同時完成必要的審查與驗證，是採用主幹開發要面臨的挑戰。
Day 6 會用一個假想的故事，說明各自的開發安排與合併決定，如何影響整個團隊。
iThome鐵人賽
看影片追技術