http://www.wtoutiao.com/p/l6fnDR.html
Git 可以幫助你更好地進行版本控制與在線協作，那麼對於創業團隊來說，使用一套合適的工作流將會大大地提高效率。今天，我們邀請到 RubyChina 社區的葉玎玎來與我們分享他之前的一些感悟，我們也歡迎更多的團隊可以使用 GitCafe 來進行協作。
適合創業團隊的實用 Git 工作流
在 「讓代碼審覈成爲你的團隊習慣」 (http://yedingding.com/2013/08/08/dig-into-code-review-process.html) 一文中，我們分享了我們團隊做代碼審覈的一些經驗心得，在微博上引起了熱烈的討論，引出了一些非常有意思的工作流介紹，比如下面的幾點。
我們有 master-dev 分支，比較大的功能纔會新開 branch，小功能都是直接到 dev 上的，再加上團隊在一起開發所以固定時間看昨日的代碼，效果還不錯。我們同樣沒有 QA，自己做的 ticket 也會找對方來做測試，但多是功能的完整性上的測試了。
——@iarmroody
我們團隊小，每個開發人員一個 Git 分支，基本上工作不會互相打擾。我們的分支策略是，對於新功能，從主幹開一個功能分支，然後每個開發在功能分支上開個人分支。合併時，先 BI (Backward Integration)，，再 FI (Forward Integration)。每週四定期合併，合併時 review。之所以放在週四，是因爲如果合併出錯，週五還有時間修復。
——@施懿民
每個團隊都在尋找最適合自己團隊的工作方法，希望能提高工作效率和團隊協作。我們也是，這也是爲什麼我們除了代碼審查之外，還需要過程審查這類的執行過程。像上面提到的兩種方式，我相信也是在各自團隊推行中覺得效果不錯的，但是個人覺得在過程上在效率上還是有很大的改進空間的，具體理由看下面，可以對比我們的目標和相應方式。目前我們使用的這一套 Git 工作流，是我們這幾年不斷的過程演進而來，之前 4 個人做 Fengche.co 在用，之前 10 個人做 Socialspring 也在用。個人覺得非常適合技術型創業團隊。
在選擇代碼級別的項目管理工作流程的時候，我們希望能達到這樣的目標：
-
能夠持續交付：我們沒有固定的發佈週期，而是一個更改通過審查就可以直接上線，這樣我們才能很快地發佈新的功能或者 bug 修復，也能快速地獲得用戶對修改的反饋。所以，有時一天裏就會有好多次的發佈。
-
方便代碼審查：我們很重視代碼審查，具體可以看我們在「讓代碼審覈成爲你的團隊習慣」 的分享。所以這個流程必須對代碼審查功能很友好。
-
使用代碼溝通：代碼，是程序員溝通的最直接的手段。我們希望每一次的更改提交都是獨立的，專注並只專注一件事情。這樣，我們就很容易地去了解這次更改背後要傳達的信息了。
所以，爲了達到持續交付，我們必須隨時有一個可發佈的分支，同時，工作分支能很簡單很早的 merge 過來。爲了做到隨時隨地的代碼審查，我們必須每一次更改都要有跡可循，且和其他更改沒有交叉。爲了方便代碼溝通，我們必須有獨立的分支來做獨立的事。所以，像開頭列出的兩種方式，首先代碼審查會很麻煩，因爲代碼容易混在一起，不夠獨立，做不到異步隨時審查，而需要大家一起花時間專門執行代碼審查。同時，會推遲 merge 的發生，帶來的更多的不確定性，比如衝突的增加，時間的拖長等等，就更不要說持續交付了。所有這些，都是效率的殺手，是應該儘量去避免的。下面看看我們的工作流程。
我們有三種性質的分支：1) Master 2) Feature or Bug 3) Staging。所有在時間線上的變化都只跟着 feature 或者 bug 走，跟人無關，也就是項目推進的自然法則。對了，版本控制系統我們用 Git，而不是 SVN，好處就不多講了，主要是三點：1) 分佈式 2) 建分支很容易 3) merge 很簡單。如果你對這個不太瞭解，可以看看 GitCafe 上的「開始 Git 文檔」(http://gitcafe-file.b0.upaiyun.com/progit.zh.pdf) 以及去 GitCafe 上親自體驗一下。
Master 分支
對於我們而言，master 分支是非常特別的，它必須是可以部署的分支，也就是通常意義上的 production。比如對於 Fengche.co，現在線上跑的等同於我們代碼裏的 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。我們也把這種工作方式集成到了 Fengche.co
中，比如提交到 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 的敏捷創業團隊，能快速迭代快速交付。
目前，葉玎玎正在做一個數據分析類新產品，通過提供全面的革命性分析解決方案，幫助企業增長業務。如果你是希望在技術上登峯造極的人，如果你是遇到越難問題越興奮的人，如果你是在代碼上極其有潔癖的人，如果你是追求完美容不下一個沙子的人，你可以聯繫他。更多信息請點擊「閱讀原文」或者看這裏：http://www.growingio.com/2015/07/29/build-the-fun。