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

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

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

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

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

正確地合并變更

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

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

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

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

這些步驟會(huì)在你的功能分支上重寫歷史（這并不是件壞事）。首先，它會(huì)使你的功能分支獲得 master 分支上當(dāng)前的所有更新。其次，你在功能分支上的所有提交都會(huì)在該分支歷史的頂部重寫，因此它們會(huì)順序地出現(xiàn)在日志中。你可能需要一路解決遇到的合并沖突，這也許是個(gè)挑戰(zhàn)。但是，這是解決沖突最好的時(shí)機(jī)，因?yàn)樗挥绊懩愕墓δ芊种А?/p>

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

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

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

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

在合并前壓扁提交

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

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

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

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

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

git commit --amend

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

git push -f

使用標(biāo)簽

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

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

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

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

讓軟件運(yùn)行時(shí)打印標(biāo)簽

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

總結(jié)

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