一項功能不必全部做完，才能把程式整合到主幹。先完成的部分，只要所需的程式都已準備好，並通過驗證，確認新增的行為正常、原有功能也仍能使用，就可以先整合到主幹。

在團隊協作中的整合問題裡，Elvina 只需要 Kevin 修改的一個共用模組，如果取得整條分支，就會一起帶入其他尚待整合的程式，也得等這些程式完成整合與驗證，才能將自己的程式合併回主幹。這些程式也可能有尚未發現的錯誤。如果 Elvina 依照錯誤的行為繼續開發，等問題修正後，她的程式也可能需要跟著調整並重新驗證。

如果 Kevin 能把這個模組分開驗證，先整合到主幹，Elvina 就能直接從主幹取得模組，不必一起帶入他的其他程式。

確認模組的用途與依賴

拆分之前，要先確認使用者需要哪些功能，以及這些功能需要哪些程式。

延續前面 Kevin 與 Elvina 的協作情境，假設 Kevin 正在開發商品清單，Elvina 正在開發客戶清單，兩個頁面都會使用同一個共用清單模組，把系統已保存的資料列出來。主幹上的模組原本只負責顯示資料，欄位沒有值時就留白。

商品清單需要讓使用者找出尚未填寫的商品欄位，也要能匯出清單交給其他人。因此，Kevin 在自己的分支上修改共用模組，同時加入「未填寫提示」與「匯出清單」兩項功能。目前提示功能已經寫好，匯出還在開發，兩部分都還沒整合到主幹。

Elvina 目前先開發客戶清單的顯示功能，只需要模組提供未填寫提示，讓使用者看到哪些客戶欄位還沒填。Kevin 的分支雖然已有這項功能，但如果直接取得整條分支，就會連尚未完成的匯出程式一起帶入。

下圖的外框表示兩人的分支，Kevin 分支內的小框表示共用模組中的兩項功能。箭頭表示頁面需要的功能，不代表合併分支。

分開提示與匯出功能

兩項功能放在同一個模組，不代表它們必須一起完成。Kevin 與 Elvina 要先確認，顯示「尚未填寫」是否需要用到匯出的程式。

在這個例子裡，提示功能只需要檢查欄位有沒有值，沒有值時顯示「尚未填寫」，不需要使用匯出功能的程式。因此，Kevin 可以先整理提示功能所需的程式與測試，驗證後整合到主幹，匯出程式則留在自己的分支繼續開發。

Kevin 要確認，只取出提示功能的程式後，欄位仍能正常顯示內容與提示。提示需要的程式，即使匯出功能也會用到，仍要一起取出並驗證。如果少了尚未完成的匯出程式，提示就無法運作，就要先修改程式，讓提示不必依賴匯出功能。

Kevin 也要保留模組原本的顯示方式。更新模組後，原有頁面的空欄位仍然留白；需要顯示「尚未填寫」的頁面，再由開發者設定使用提示功能。

下圖由上往下呈現提示功能整合到主幹後，兩人取得模組並繼續開發的過程。兩人後續的開發沒有固定先後順序。

提示功能已進入主幹，Elvina 就能取得模組。她仍要將客戶清單接上模組並完成驗證，才能提供給使用者。

原子提交

原子提交（Atomic Commit）是一次提交完成一個明確的修改目的，包含必要的程式與測試，不混入不相關的變更。為了完成同一個目的，可以同時修改多個檔案。

Kevin 這次的目的是讓共用模組支援未填寫提示，因此要把讓頁面選用提示的設定、顯示提示的程式與對應測試放在同一次提交中。套用這次提交後，程式要能正常建置並通過必要測試，不必再等下一次提交補齊。尚未完成的匯出功能則另外提交。

原子提交可以使用先前提交已提供的程式。例如，Elvina 可以在後續提交中，讓客戶清單使用提示功能；Kevin 的模組則不必等待客戶清單完成，才能運作與驗證。

如果 Kevin 修改模組後，原有頁面也要跟著修改才能使用，就要把模組與頁面的程式放在同一次提交中。另一種做法是讓模組繼續支援原本的用法，之後再逐步修改頁面。這樣其他人取得任何一次提交時，原有頁面都仍能使用。

提交訊息除了寫出改了什麼，也要交代原因，例如「新增未填寫提示，讓清單使用者辨認待補欄位」。後來調整模組的人，才能理解這項功能的用途。

版本控制系統的「原子提交」也指一組變更全部記錄，或全部不記錄。這是提交操作的保證，不代表提交的程式一定完整或正確；內容仍要由開發者安排與驗證。

分步整合與驗證

驗證提示功能與原有行為

Kevin 要驗證提示功能是否正常，以及原有頁面是否仍能正常使用模組。缺少的測試要和提示程式一起補齊。

Phoebe 是協助審查的前端工程師。她與 Kevin 一起確認這次提交只包含提示功能需要的程式與測試，沒有帶入尚未完成的匯出程式，再檢視新舊用法與測試結果。

完成必要審查與驗證後，Kevin 將提交整合到主幹，再確認主幹的驗證結果。確認通過後，Elvina 就能取得這個版本。

在客戶清單使用模組

Elvina 從主幹取得模組後，將客戶清單接上模組與 Mandy 已完成整合的後端介面，再驗證它們一起運作的結果。模組本身已通過測試，仍不能省略這一步。

Elvina 將頁面調整與測試一起提交，完成必要審查與驗證後整合到主幹，再確認主幹的驗證結果。這個提交需要主幹上已支援提示的模組，但不必等 Kevin 完成匯出功能。

Kevin 則取得主幹更新，繼續完成匯出功能與商品清單。後續仍需確認匯出與提示能一起運作，不能沿用只有提示功能時的驗證結果。

如果驗證時發現缺少必要程式，或原有頁面的測試失敗，就要先補齊程式或修正問題，再重新驗證。

下圖呈現主幹上的提交順序，各提交都已完成必要審查與驗證。Elvina 從 B 開始就能取得支援提示的模組。

C 依賴 B，但 B 不必等待 C 才能運作。尚未完成的匯出程式不在這組提交裡。

小結

Kevin 的商品清單需要提示與匯出，Elvina 目前只需要提示。確認提示不必依賴匯出程式後，就能把必要的程式與測試安排成原子提交，先整合到主幹，讓 Elvina 取得使用。

程式可以先整合，使用者卻不一定能提早使用。Elvina 的客戶清單需求也包含篩選與匯出；即使清單已能顯示未填寫提示，如果仍要求全部完成才交付，使用者還是得繼續等。接下來回到這項清單需求，說明如何與需求方確認可以先交付的範圍。

參考資料

• Trunk Based Development：Short-Lived Feature Branches：其中的 Pitfalls 說明，同一項需求可以先整合程式整理，再分步加入功能，不必限制為一項需求只有一個 PR。
• Git：gitworkflows — Separate Changes：說明將變更拆成小而完整的邏輯步驟，每個步驟不依賴後續提交才能運作，並通過測試，方便審查與追查歷史。
• Version Control with Subversion：Revisions：說明提交操作將一組變更全部記錄或全部不記錄的原子性，用來區分工具保證與提交內容的安排。