6 個在團隊中使用 Git 的最佳實踐

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

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

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

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

正確地合併變更

每個團隊成員都需要在一個單獨的功能分支上開發。但即使是使用了單獨的分支，每個人也會修改一些共同的文件。當把更改合併回 master 分支時，合併通常無法自動進行。可能需要手動解決不同的人對同一文件不同變更的衝突。這就是你必須學會如何處理 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 協作，無論他們的知識水平。

via: https://opensource.com/article/20/7/git-best-practices

作者：Ravi Chandran 選題：lujun9972 譯者：LazyWolfLin 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive