實用 Git 工做流

在 「讓代碼審覈成爲你的團隊習慣」 一文中，咱們分享了咱們團隊作代碼審覈的一些經驗心得，在微博上引發了熱烈的討論，引出了一些很是有意思的工做流介紹，好比下面的幾點。

咱們有 master-dev 分支，比較大的功能纔會新開 branch，小功能都是直接到 dev 上的，再加上團隊在一塊兒開發因此固定時間看昨日的代碼，效果還不錯。咱們一樣沒有 QA，本身作的 ticket 也會找對方來作測試，但可能是功能的完整性上的測試了。

- @iarmroody

咱們團隊小，每一個開發人員一個 git 分支，基本上工做不會互相打擾。咱們的分支策略是，對於新功能，從主幹開一個功能分支，而後每一個開發在功能分支上開我的分支。合併時，先 BI（Backward Integration)，，再 FI（Forward Integration)。每週四按期合併，合併時 review。之因此放在週四，是由於若是合併出錯，週五還有時間修復。

- @施懿民

每一個團隊都在尋找最適合本身團隊的工做方法，但願能提升工做效率和團隊協做。咱們也是，這也是爲何咱們除了代碼審查以外，還須要過程審查這類的執行過程。像上面提到的兩種方式，確定也是在各自團隊推行中以爲效果不錯的，可是我的以爲在過程上在效率上仍是有改進空間的，具體理由看下面，能夠對比咱們的目標和相應方式。目前咱們使用的這一套 Git 工做流，是咱們這幾年不斷的過程演進而來，目前 4 我的作 Pragmatic.ly 在用，以前 10 我的作 Socialspring 也在用。我的以爲很是適合技術型創業團隊。

在選擇代碼級別的項目管理工做流程的時候，咱們但願能達到這樣的目標：

• 可以持續交付：咱們沒有固定的發佈週期，而是一個更改經過審查就能夠直接上線，這樣咱們才能很快地發佈新的功能或者 bug 修復，也能快速地得到用戶對修改的反饋。因此，有時一天裏就會有好屢次的發佈。
• 方便代碼審查：咱們很重視代碼審查，具體能夠看咱們在「讓代碼審覈成爲你的團隊習慣」 的分享。因此這個流程必須對代碼審查功能很友好。
• 使用代碼溝通：代碼，是程序員溝通的最直接的手段。咱們但願每一次的更改提交都是獨立的，專一併只專一一件事情。這樣，咱們就很容易地去了解此次更改背後要傳達的信息了。

因此，爲了達到持續交付，咱們必須隨時有一個可發佈的分支，同時，工做分支能很簡單很早的 merge 過來。爲了作到隨時隨地的代碼審查，咱們必須每一次更改都要有跡可循，且和其餘更改沒有交叉。爲了方便代碼溝通，咱們必須有獨立的分支來作獨立的事。因此，像開頭列出的兩種方式，首先代碼審查會很麻煩，由於代碼容易混在一塊兒，不夠獨立，作不到異步隨時審查，而須要你們一塊兒花時間專門執行代碼審查。同時，會推遲 merge 的發生，帶來的更多的不肯定性，好比衝突的增長，時間的拖長等等，就更不要說持續交付了。全部這些，都是效率的殺手，是應該儘可能去避免的。下面看看咱們的工做流程。

咱們有三種性質的分支：1) Master 2) Feature or Bug 3) Staging。全部在時間線上的變化都只跟着 feature 或者 bug 走，跟人無關，也就是項目推動的天然法則。對了，版本控制系統咱們用 Git，而不是 SVN，好處就很少講了，主要是三點：1) 分佈式 2) 建分支很容易 3) merge 很簡單。若是你對這個不太瞭解，能夠看看 GitCafe 的 開始 Git 文檔。

Master 分支

對於咱們而言，master 分支是很是特別的，它必須是能夠部署的分支，也就是一般意義上的 production。好比對於 Pragmatic.ly，如今線上跑的等同於咱們代碼裏的 master 分支。因此，master 上的任何代碼更改都只能是從別的分支 merge 過來，在代碼審查事後。

Feature or Bug 分支

咱們開發時不區分功能特性和 Bug，全部都一致按任務處理。因此，爲了方便持續交付和代碼審查，咱們會人爲的細分任務，好比在 9 月份，咱們有下面這些任務計劃。

咱們在開始實現這個功能或者修復這個 bug 的時候，就基於 master 支持建立一個新分支。之因此基於 master，正是由於上面提到過 master 永遠是能夠部署的分支，那麼基於 master 開的分支就能夠直接被 merge 回 master 作發佈。

(yedingding)$ ~/Pragmatic.ly › git checkout -b 754_usage_analytics -t master
Switch to a new branch named "754_usage_analytics"
(terry)$ ~/Pragmatic.ly › git checkout -b 746_integrate_mobile -t master
Switch to a new branch named "746_integrate_mobile"
(roy)$ ~/Pragmatic.ly › git checkout -b 77_comment_via_email -t master
Switch to a new branch named "77_comment_via_email"

從分支建立例子上來看，咱們是按照 <sid>_<ticket title> 的方式來命名。sid 是這個任務在 Pragmatic.ly 的任務 ID，ticket title 是任務在 Pragmatic.ly 上的標題概述。經過每一個任務開發都基於 master 開新分支，就保證了，這個新分支能很容易的跟 master 作 diff 來作代碼審查，而後被 merge 回 master。咱們也把這種工做方式集成到了 Pragmatic.ly 中，好比提交到 754_usage_analytics 的 commits 會自動關聯到 Pragmatic.ly 這個任務的動態裏，也能夠在 commit 消息里加上 "ref #754", "resolved #754" 這樣的文本，也會自動作關聯，以下圖。

這裏，在建立 pull request 發佈作代碼審查前，咱們須要先同步 master，也就是 merge master 到正在開發的分支，確保沒有 break 和能夠正常 merge。而後，團隊其餘成員會介入作代碼審查，固然以前會要求齊全的測試，經過後就能夠 merge 會 master 作發佈了。用這種方法，須要注意的是，merge 必須得及時，否則若是留下不少個分支沒有 merge 的話，解決衝突是個麻煩的事情，更不要說有時會遇到功能有依賴關係的狀況時。

Staging 分支

Staging 分支也是一個特殊的分支，是部署到咱們的 staging 服務器上的版本。理想狀況下，全部的更改作完代碼審查後，在 merge 回 master 發佈以前，會先 merge 到 staging 分支，發佈到 staging 服務器作人工測試，經過後再 merge 到 master 發佈到生產線上。因此，大部分時候，Staging 分支是 master 的一個備份保護，每次測儘量少的改變。因此，仍是會回到同一個注意點，要及時 merge。並且，有時候，根據任務的複雜度不一樣，咱們可能不會經過 staging 而是會直接 merge 到 master 分支上線，好比一些簡單的 bug 修復。

關於 CI

目前，咱們沒有專門的 CI 服務器作持續集成測試，由於在咱們團隊的理解力，CI 並非意味着必須有專門的 CI server，而是每一個開發人員在提交代碼時必須保證經過了集成測試。因此咱們的作法是發出每一個 Pull Request 的時候，必須確保咱們全部的測試仍然經過。

Pull Request VS Merge Reuqest

嚴格意義上來講，咱們使用的是 Merge Request，而不是 Pull Request。Pull Request 要解決的問題是防止遠程分支過多形成混亂，這樣由每一個開發人員創建本身的一個版本庫，在本身的版本庫建分支操做，而後往產品生產版本庫發起一個 Pull 請求，同時，又要不斷的跟遠程的產品版本庫同步保持一致，對於 10 我的如下的團隊，我的感受過重了。像豆瓣這樣的團隊，爲了利用好 Pull Request，專門開發了一整套工具鏈來自動作這些操做下降複雜度，小團隊可能就沒這個條件了。而對於開源項目來講，組織鬆散，Pull Request 是個很是好的方式。Merge Request 就是我前面一直提到的工做方式，一個遠程代碼庫，多個分支來管理，簡單直接。

總結

以上就是咱們代碼級別的項目管理工做流程，但願對你有幫助。我的以爲這個流程很適合 lean 的敏捷創業團隊，能快速迭代快速交付。大家是怎麼作的呢，歡迎交流，能夠在微博上直接 @yedingding 或者 @pragmaticly！