圖文講解，團隊開發中的 Git 最佳實踐

公衆號發現了一篇很是好的有關Git的實踐文章，特意轉載過來，很是感謝做者 芋道源碼 分享的寶貴經驗。

在 2005 年的某一天，Linux 之父 Linus Torvalds 發佈了他的又一個里程碑做品——Git。它的出現改變了軟件開發流程，大大地提升了開發流暢度！直到如今仍十分流行，徹底沒有衰退的跡象。

本文不是一篇 Git 入門教程，這樣的文章一搜一大把，我是要從具體實踐角度，尤爲是在團隊協做中，闡述如何去好好地應用 Git。既然是講在團隊中的應用實踐，我就儘量地結合實際場景來說述。

1、習慣養成

若是一個團隊在使用 Git 時沒有一些規範，那麼將是一場難以醒來的噩夢！然而，規範當然重要，但更重要的是我的素質，在使用 Git 時須要本身養成良好的習慣。

提交

如何去寫一個提交信息，《Git: 教你如何在Commit時有話可說》中作了很好的說明。在具體開發工做中主要須要遵照的原則就是「使每次提交都有質量」，只要堅持作到如下幾點就 OK 了：

• 一、提交時的粒度是一個小功能點或者一個 bug fix，這樣進行恢復等的操做時可以將「誤傷」減到最低；
• 二、用一句簡練的話寫在第一行，而後空一行稍微詳細闡述該提交所增長或修改的地方；
• 三、不要每提交一次就推送一次，多積攢幾個提交後一次性推送，這樣能夠避免在進行一次提交後發現代碼中還有小錯誤。

假如已經把代碼提交了，對此次提交的內容進行檢查時發現裏面有個變量單詞拼錯了或者其餘失誤，只要尚未推送到遠程，就有一個不被他人發覺你的疏忽的補救方法——

首先，把失誤修正以後提交，能夠用與上次提交一樣的信息。

而後，終端中執行命令 git rebase -i [SHA]，其中 SHA 是上一次提交以前的那次提交的，在這裏是 3b22372。

最後，這樣就將兩次提交的節點合併成一個，甚至可以修改提交信息！

誰說歷史不可篡改了？前提是，想要合併的那幾回提交尚未推送到遠程！

推送

當本身一我的進行開發時，在功能完成以前不要急着建立遠程分支。

拉取

請讀張文鈿所寫的《使用 git rebase 避免無謂的 merge》。

合併

在將其餘分支的代碼合併到當前分支時，若是那個分支是當前分支的父分支，爲了保持圖表的可讀性和可追蹤性，能夠考慮用 git rebase 來代替 git merge；反過來或者不是父子關係的兩個分支以及互相已經 git merge 過的分支，就不要採用 git rebase 了，避免出現重複的衝突和提交節點。

2、分支管理

Git 的一大特色就是能夠建立不少分支並行開發。正由於它的靈活性，團隊中若是沒有一個成熟的分支模型的話，那將會是一團糟。

要是誰真把這麼亂的提交圖表擺在我面前，就給他一個上勾拳！

分支模型

有個很成熟的叫「Git Flow」的分支模型，它可以應對 99% 的場景，剩下的那 1% 留給幾乎不存在的極度變態的場景。

須要注意的是，它只是一個模型，而不是一個工具；你能夠用工具去應用這個模型，也能夠用最樸實的命令行。因此，重要的是理解概念，不要執着於實行的手段。

簡單說來，Git Flow 就是給本來普普統統的分支賦予了不一樣的「職責」：

• master——最爲穩定功能最爲完整的隨時可發佈的代碼；
• hotfix——修復線上代碼的 bug；
• develop——永遠是功能最新最全的分支；
• feature——某個功能點正在開發階段；
• release——發佈按期要上線的功能。

看到上面的「master」和「develop」加粗了吧？表明它們是「主要分支」，其餘的分支是基於它們派生出來的。主要分支每種類型只能有一個，派生分支每一個類型能夠同時存在多個。各種型分支之間的關係用一張圖來體現就是：

更多信息可參考 xirong 所整理的《Git工做流指南》。

工具選擇

一直不喜歡「＊＊最好用」這種命題，主觀性太強，不會有一個結論。對於工具的選擇，我一直都是秉承「哪一個能更好地解決問題就用哪一個」這個原則。因此，只要不影響到團隊，用什麼工具都是能夠接受的。但根據多數開發人員的素質狀況來看，建議使用圖形化工具，例如 SourceTree。若是想用命令行，能夠啊！先在內心問下本身：「我 Git 牛逼不？會不會惹麻煩給別人？」

在團隊中應用 Git Flow 時，推薦使用 SourceTree 與 GitLab 配合的形式：

• 一、用 SourceTree 建立 feature 等分支以及本地的分支合併、刪除；
• 二、用 GitLab 作代碼審覈和遠程的分支合併、刪除。

SourceTree 和 GitLab 應該是相輔相成的存在，而不是互相取代。

3、事前準備

爲了將一些規範性的東西和 Git Flow 的部分操做自動化處理，要對 SourceTree 和 GitLab 進行一下配置。

SourceTree

按下 command + , 調出「Preferences」界面並切換到「Git」標籤，勾選「Use rebase instead of merge by default for tracked branches」和「Do not fast-forward when merging, always create commit」。

這樣設置以後，在點「Pull」按鈕拉取代碼時會自動執行 git pull --rebase；而且，每次合併時會自動建立新的包含分支信息的提交節點。

接下來，點擊工具欄中的「Git Flow」按鈕將相關的流程自動化。若是沒有特殊需求，直接按下對話框中的「OK」就行了。初始化完成後會自動切換到 develop 分支。

這下再點「Git Flow」按鈕所彈出的對話框就是選擇建立分支類型的了。

GitLab

在建立項目倉庫後必定要把主要分支，也就是 master 和 develop 給保護起來。爲它們設置權限，只有項目負責人能夠進行推送和刪除等操做。

被保護的分支在列表中會有特殊的標記進行區分。

4、開發流程

在引入 Git Flow 以後，全部工做都要圍繞着它來展開，將本來的流程與之結合造成「基於 Git Flow 的開發流程」。

開發功能

在肯定發佈日期以後，將須要完成的內容細分一下分配出去，負責某個功能的開發人員利用 SourceTree 所提供的 Git Flow 工具建立一個對應的 feature 分支。若是是多人配合的話，建立分支並作一些初始化工做以後就推送建立遠程分支；不然，直到功能開發完畢要合併進 develop 前，不要建立遠程分支。

功能開發完並自測以後，先切換到 develop 分支將最新的代碼拉取下來，再切換回本身負責的 feature 分支把 develop 分支的代碼合併進來。合併方式參照上文中的「合併」，若是有衝突則本身和配合的人一塊兒解決。

而後，到 GitLab 上的項目首頁建立合併請求（merge request）。

「來源分支」選擇要被合併的 feature 分支且「目標分支」選擇 develop 分支後點擊「比較分支」按鈕，在出現的表單中將處理人指派爲項目負責人。

項目負責人在收到合併請求時，應該先作下代碼審覈看看有沒有明顯的嚴重的錯誤；有問題就找負責開發的人去修改，沒有就接受請求並刪除對應的 feature 分支。

在將某次發佈的所需功能所有開發完成時，就能夠交付測試了。

測試功能

負責測試的人建立一個 release 分支部署到測試環境進行測試；若發現了 bug，相應的開發人員就在 release 分支上或者基於 release 分支建立一個分支進行修復。

發佈上線

當確保某次發佈的功能能夠發佈時，負責發佈的人將 release 分支合併進 master 和 develop 並打上 tag，而後打包發佈到線上環境。

建議打 tag 時在信息中詳細描述此次發佈的內容，如：添加了哪些功能，修復了什麼問題。

修復問題

當發現線上環境的代碼有小問題或者作些文案修改時，相關開發人員就在本地建立 hotfix 分支進行修改，具體操做參考「開發功能」。

若是是至關嚴重的問題，可能就得回滾到上一個 tag 的版本了。

5、額外說明

這裏所提到的事情，雖非必需，但知道以後卻會如虎添翼。

分支命名

除了主要分支的名字是固定的以外，派生分支是須要本身命名的，這裏就要有個命名規範了。強烈推薦用以下形式：

• feature——按照功能點（而不是需求）命名；
• release——用發佈時間命名，能夠加上適當的前綴；
• hotfix——GitLab 的 issue 編號或 bug 性質等。

另外還有 tag，用語義化的版本號命名。

發佈日期

發佈頻率是影響開發人員與測試人員的新陳代謝和心情的重要因素之一，頻繁無規律的發佈會致使內分泌失調、情緒暴躁，導致爆粗口、砸電腦等情況出現。因此，確保一個固定的發佈週期相當重要！

在有一波或幾波需求來臨之時，想擋掉是不太可能的，但能夠在評審時將它（們）分期，在某個發佈日以前只作一部分。這是必需要控制住的！否則任由着需求方說「這個今天必定要上」「那個明天急着用」的話，技術人員就等着進醫院吧！

---

特此註明：
本文爲轉載 芋道源碼公衆號文章，原文地址：圖文講解，團隊開發中的 Git 最佳實踐