查閱歷史、比較差異，是版本控制提供的基本功能。至於我們希望透過這些功能達成什麼目的，Day 2 已經有說明。
接下來，團隊成員可能需要各自從不同的版本出發，進行修改與測試。版本控制系統提供的分支功能，就能協助我們分開修改。如果讓每個人先在自己的分支上開發，問題是不是就解決了？
分支可以讓開發者分開修改原始碼。但實際開發時，各自修改並測試過的程式，還需要整合成新的版本，讓其他成員取得並使用。最常需要大家一起確認的情況，就是改到同一個檔案。即使各自開發時都沒有問題，最後仍然需要一起討論程式應該長什麼樣，才能把各自修改的程式整合成共同版本。
這裡會發現，在自己的版本裡確認功能正常，跟把大家的修改放在一起後仍然正常，是兩件需要分別確認的事。
回到 Day 2 的共享目錄故事，我是先把程式放在本機修改，再上傳到共享目錄。在本機修改的期間，手上的程式與共享目錄裡的程式，就已經是不同的版本了。我會用「隔離」來理解這種各自保留、各自修改原始碼的狀態。
當時雖然沒有使用版本控制系統的分支功能，卻已經有類似的協作問題：每個人可以在自己的電腦上嘗試修改，但最後仍要決定，哪些修改要放進共同版本。
而版本控制系統的分支功能，提供了管理這些版本的方式。以 Git 的設計為例，分支是指向某個提交、可以隨開發往前移動的參照。在自己的分支上提交，會更新這條分支所指向的提交，另一條分支不會因此指向這個新提交。
這讓我們可以從同一個版本出發，各自修改、提交，再決定什麼時候整合。不同的修改方向可以先分開保留，供開發者嘗試與驗證。
如果只是嘗試某個做法，最後決定不採用，這份修改可以直接捨棄。但如果要讓修改後的程式與其他人的程式一起使用，就需要進一步處理它與共同版本的關係。
《Pro Git》也使用「隔離」來描述分支上的修改。在說明兩條分支各自提交、歷史分岔之後的現象，原文寫道：
Both of those changes are isolated in separate branches.
出處：Pro Git：切換分支。
也就是「這兩份修改分別隔離在不同的分支中」。
對團隊協作而言，各自分頭修改只是過程。如果各自修改的程式要一起使用，就需要把它們整合成共同版本。
在共享目錄的做法裡，把本機修改的程式上傳到共享目錄時，可能會覆蓋其他人的修改，因此需要先比較雙方的內容，再決定如何合併。改用版本控制系統之後，工具可以協助比較差異，並自動合併部分修改；遇到無法自動合併的衝突時，仍需要開發者理解雙方的修改目的，決定如何處理。
我們可以用「A 修改」、「B 修改」、「C 修改」的假設情境，說明整合時需要處理的事。
A 分支做了 A 修改，B 分支做了 B 修改。當兩邊修改同一個檔案的相同部分，工具無法自動合併時，就需要開發者處理衝突。
處理方式不一定是直接選擇其中一邊。如果兩邊的需求都要保留，就可能需要追加一個 C 修改，讓 A 與 B 修改後的程式能一起使用。
C 修改是在整合時產生的，也需要記錄其修改理由，包括 A 與 B 各自的目的、無法直接合併的原因，以及 C 所做的調整。
這也回到 Day 2 談過的目的。提交訊息如果只寫「解決衝突」，後來的人仍然需要重新查閱 A 與 B，才能推測 C 為什麼存在。把整合時遇到的問題與決定留下來，才能讓這段歷史提供更明確的依據。
如果接著還有 D 分支要整合，也要重新確認它與共同版本的差異。是否需要追加調整，要看 D 修改了哪些內容、依賴共同版本中的哪些功能，以及這些修改是否會影響其他功能。
建立分支，讓我們能分開進行修改；合併分支，則協助我們將不同修改合併成共同版本。這些操作仍然需要配合理解差異與記錄修改理由，才能讓團隊知道整合時做了哪些決定。
但還有一個問題：即使工具順利完成合併，也不代表組合後的程式已經確認可以正常運作。
要確認這件事，實際上需要做哪些驗證？Day 4 會接著說明整合的目的，以及如何驗證整合後的結果。
iThome鐵人賽
看影片追技術