[[342431]]

采用這些 Git 協作策略，讓團隊工作更高效。

Git 非常有助于小團隊管理他們的軟件開發進度，但有些方法能讓你變得更高效。我發現了許多有助于我的團隊的最佳實踐，尤其是當不同 Git 水平的新人加入時。

在你的團隊中正式確立 Git 約定

每個人都應當遵循對于分支命名、標記和編碼的規范。每個組織都有自己的規范或者最佳實踐，并且很多建議都可以從網上免費獲取，而重要的是盡早選擇合適的規范并在團隊中遵循。

同時，不同的團隊成員的 Git 水平參差不齊。你需要創建并維護一組符合團隊規范的基礎指令，用于執行通用的 Git 操作。

正確地合并變更

每個團隊成員都需要在一個單獨的功能分支上開發。但即使是使用了單獨的分支，每個人也會修改一些共同的文件。當把更改合并回 master 分支時，合并通常無法自動進行?？赡苄枰謩咏鉀Q不同的人對同一文件不同變更的沖突。這就是你必須學會如何處理 Git 合并的原因。

現代編輯器具有協助解決 Git 合并沖突的功能。它們對同一文件的每個部分提供了合并的各種選擇，例如，是否保留你的更改，或者是保留另一分支的更改，亦或者是全部保留。如果你的編輯器不支持這些功能，那么可能是時候換一個代碼編輯器了。

經常變基你的功能分支

當你持續地開發你的功能分支時，請經常對它做變基rebase：rebase master。這意味著要經常執行以下步驟：

git checkout master
git pull
git checkout feature-xyz  # 假設的功能分支名稱
git rebase master  # 可能需要解決  feature-xyz 上的合并沖突

這些步驟會在你的功能分支上重寫歷史（這并不是件壞事）。首先，它會使你的功能分支獲得 master 分支上當前的所有更新。其次，你在功能分支上的所有提交都會在該分支歷史的頂部重寫，因此它們會順序地出現在日志中。你可能需要一路解決遇到的合并沖突，這也許是個挑戰。但是，這是解決沖突最好的時機，因為它只影響你的功能分支。

在解決完所有沖突并進行回歸測試后，如果你準備好將功能分支合并回 master，那么就可以在再次執行上述的變基步驟幾次后進行合并：

git checkout master
git pull
git merge feature-xyz

在此期間，如果其他人也將和你有沖突的更改推送到 master，那么 Git 合并將再次發生沖突。你需要解決它們并重新進行回歸測試。

還有一些其他的合并哲學（例如，只使用合并而不使用變基以防止重寫歷史），其中一些甚至可能更簡單易用。但是，我發現上述方法是一個干凈可靠的策略。提交歷史日志將以有意義的功能序列進行排列。

如果使用“純合并”策略（上面所說的，不進行定期的變基），那么 master 分支的歷史將穿插著所有同時開發的功能的提交。這樣混亂的歷史很難回顧。確切的提交時間通常并不是那么重要。最好是有一個易于查看的歷史日志。

在合并前壓扁提交

當你在功能分支上開發時，即使再小的修改也可以作為一個提交。但是，如果每個功能分支都要產生五十個提交，那么隨著不斷地增添新功能，master 分支的提交數終將無謂地膨脹。通常來說，每個功能分支只應該往 master 中增加一個或幾個提交。為此，你需要將多個提交壓扁Squash成一個或者幾個帶有更詳細信息的提交中。通常使用以下命令來完成：

git rebase -i HEAD~20  # 查看可進行壓扁的二十個提交

當這條命令執行后，將彈出一個提交列表的編輯器，你可以通過包括遴選pick或壓扁squash在內的數種方式編輯它。“遴選”一個提交即保留這個提交。“壓扁”一個提交則是將這個提交合并到前一個之中。使用這些方法，你就可以將多個提交合并到一個提交之中，對其進行編輯和清理。這也是一個清理不重要的提交信息的機會（例如，帶錯字的提交）。

總之，保留所有與提交相關的操作，但在合并到 master 分支前，合并并編輯相關信息以明確意圖。注意，不要在變基的過程中不小心刪掉提交。

在執行完諸如變基之類的操作后，我會再次看看 git log 并做最終的修改：

git commit --amend

最后，由于重寫了分支的 Git 提交歷史，必須強制更新遠程分支：

git push -f

使用標簽

當你完成測試并準備從 master 分支部署軟件到線上時，又或者當你出于某種原因想要保留當前狀態作為一個里程碑時，那么可以創建一個 Git 標簽。對于一個積累了一些變更和相應提交的分支而言，標簽就是該分支在那一時刻的快照。一個標簽可以看作是沒有歷史記錄的分支，也可以看作是直接指向標簽創建前那個提交的命名指針。

所謂的“配置控制”就是在不同的里程碑上保存代碼的狀態。大多數項目都有一個需求，能夠重現任一里程碑上的軟件源碼，以便在需要時重新構建。Git 標簽為每個代碼的里程碑提供了一個唯一標識。打標簽非常簡單：

git tag milestone-id -m "short message saying what this milestone is about"
git push --tags   # 不要忘記將標簽顯式推送到遠程

考慮這樣一種情況：Git 標簽對應的軟件版本已經分發給客戶，而客戶報告了一個問題。盡管代碼庫中的代碼可能已經在繼續開發，但通常情況下為了準確地重現客戶問題以便做出修復，必須回退到 Git 標簽對應的代碼狀態。有時候新代碼可能已經修復了那個問題，但并非一直如此。通常你需要切換到特定的標簽并從那個標簽創建一個分支：

git checkout milestone-id        # 切換到分發給客戶的標簽
git checkout -b new-branch-name  # 創建新的分支用于重現 bug

此外，如果帶附注的標記和帶簽名的標記有助于你的項目，可以考慮使用它們。

讓軟件運行時打印標簽

在大多數嵌入式項目中，從代碼版本構建出的二進制文件有固定的名稱，這樣無法從它的名稱推斷出對應的 Git 標簽。在構建時“嵌入標簽”有助于將未來發現的問題精準地關聯到特定的構建版本。在構建過程中可以自動地嵌入標簽。通常，git describe 生成的標簽字符串會在代碼編譯前插入到代碼中，以便生成的可執行文件能夠在啟時時輸出標簽字符串。當客戶報告問題時，可以指導他們給你發送啟動時輸出的內容。

總結

Git 是一個需要花時間去掌握的復雜工具。使用這些實踐可以幫助團隊成功地使用 Git 協作，無論他們的知識水平。