[[342431]]

采用這些 Git 協(xié)作策略，讓團(tuán)隊工作更高效。

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

在你的團(tuán)隊中正式確立 Git 約定

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

同時，不同的團(tuán)隊成員的 Git 水平參差不齊。你需要創(chuàng)建并維護(hù)一組符合團(tuán)隊規(guī)范的基礎(chǔ)指令，用于執(zhí)行通用的 Git 操作。

正確地合并變更

每個團(tuán)隊成員都需要在一個單獨的功能分支上開發(fā)。但即使是使用了單獨的分支，每個人也會修改一些共同的文件。當(dāng)把更改合并回 master 分支時，合并通常無法自動進(jìn)行。可能需要手動解決不同的人對同一文件不同變更的沖突。這就是你必須學(xué)會如何處理 Git 合并的原因。

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

經(jīng)常變基你的功能分支

當(dāng)你持續(xù)地開發(fā)你的功能分支時，請經(jīng)常對它做變基rebase：rebase master。這意味著要經(jīng)常執(zhí)行以下步驟：

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

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

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

git checkout master
git pull
git merge feature-xyz

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

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

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

在合并前壓扁提交

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

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

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

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

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

git commit --amend

最后，由于重寫了分支的 Git 提交歷史，必須強(qiáng)制更新遠(yuǎn)程分支：

git push -f

使用標(biāo)簽

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

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

git tag milestone-id -m "short message saying what this milestone is about"
git push --tags   # 不要忘記將標(biāo)簽顯式推送到遠(yuǎn)程

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

git checkout milestone-id        # 切換到分發(fā)給客戶的標(biāo)簽
git checkout -b new-branch-name  # 創(chuàng)建新的分支用于重現(xiàn) bug

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

讓軟件運行時打印標(biāo)簽

在大多數(shù)嵌入式項目中，從代碼版本構(gòu)建出的二進(jìn)制文件有固定的名稱，這樣無法從它的名稱推斷出對應(yīng)的 Git 標(biāo)簽。在構(gòu)建時“嵌入標(biāo)簽”有助于將未來發(fā)現(xiàn)的問題精準(zhǔn)地關(guān)聯(lián)到特定的構(gòu)建版本。在構(gòu)建過程中可以自動地嵌入標(biāo)簽。通常，git describe 生成的標(biāo)簽字符串會在代碼編譯前插入到代碼中，以便生成的可執(zhí)行文件能夠在啟時時輸出標(biāo)簽字符串。當(dāng)客戶報告問題時，可以指導(dǎo)他們給你發(fā)送啟動時輸出的內(nèi)容。

總結(jié)

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