Git協作流程

協作必須有乙個規範的流程，讓大家有效地合作，使得專案井井有條地發展下去。"協作流程"在英語裡，叫做"workflow"或者"flow"，原意是水流，比喻專案像水流那樣，順暢、自然地向前流動，不會發生衝擊、對撞、甚至漩渦。

它指的是，需求是開發的起點，先有需求再有功能分支（feature branch）或者補丁分支（hotfix branch）。完成開發後，該分支就合併到主分支，然後被刪除。

最早誕生、並得到廣泛採用的一種協作流程，就是git flow 。

它最主要的特點有兩個。

貼上的影象

450x678 19 kb

首先，專案存在兩個長期分支。

其次，專案存在三種短期分支。

git flow 的詳細介紹，請閱讀我翻譯的中文版《git 分支管理策略》1

。git flow的優點是清晰可控，缺點是相對複雜，需要同時維護兩個長期分支。大多數工具都將master當作預設分支，可是開發是在develop分支進行的，這導致經常要切換分支，非常煩人。

更大問題在於，這個模式是基於"版本發布"的，目標是一段時間以後產出乙個新版本。但是，很多**專案是"持續發布"，**一有變動，就部署一次。這時，master分支和develop分支的差別不大，沒必要維護兩個長期分支。

github flow 是git flow的簡化版，專門配合"持續發布"。它是 github.com 使用的協作流程。

它只有乙個長期分支，就是master，因此用起來非常簡單。

官方推薦的流程如下。

貼上的影象

750x138 10.6 kb

第一步：根據需求，從master拉出新分支，不區分功能分支或補丁分支。

第二步：新分支開發完成後，或者需要討論的時候，就向master發起乙個pull request（簡稱pr）。

第四步：你的pull request被接受，合併進master，重新部署後，原來你拉出來的那個分支就被刪除。（先部署再合併也可。）

問題在於它的假設：master分支的更新與產品的發布是一致的。也就是說，master分支的最新**，預設就是當前的線上**。

上面這種情況，只有master乙個主分支就不夠用了。通常，你不得不在master分支以外，另外新建乙個production分支跟蹤線上版本。

gitlab flow 是 git flow 與 github flow 的綜合。它吸取了兩者的優點，既有適應不同開發環境的彈性，又有單一主分支的簡單和便利。它是 gitlab.com 推薦的做法。

gitlab flow 的最大原則叫做"上游優先"（upsteam first），即只存在乙個主分支master，它是所有其他分支的"上游"。只有上游分支採納的**變化，才能應用到其他分支。

chromium專案就是乙個例子，它明確規定，上游分支依次為：

1.linus torvalds的分支

2.子系統（比如netdev）的分支

3.裝置廠商（比如三星）的分支

貼上的影象

560x618 12.3 kb

對於"持續發布"的專案，它建議在master分支以外，再建立不同的環境分支。比如，"開發環境"的分支是master，"預發環境"的分支是pre-production，"生產環境"的分支是production。

開發分支是預發分支的"上游"，預發分支又是生產分支的"上游"。**的變化，必須由"上游"向"下游"發展。比如，生產環境出現了bug，這時就要新建乙個功能分支，先把它合併到master，確認沒有問題，再cherry-pick到pre-production，這一步也沒有問題，才進入production。

只有緊急情況，才允許跳過上游，直接合併到下游分支。

貼上的影象

550x719 12.6 kb

對於"版本發布"的專案，建議的做法是每乙個穩定版本，都要從master分支拉出乙個分支，比如2-3-stable、2-4-stable等等。

以後，只有修補bug，才允許將**合併到這些分支，並且此時要更新小版本號。

貼上的影象

750x600 29.7 kb

功能分支合併進master分支，必須通過pull request（gitlab裡面叫做 merge request）。

前面說過，pull request本質是一種對話機制，你可以在提交的時候，@相關人員或團隊，引起他們的注意。

master分支應該受到保護，不是每個人都可以修改這個分支，以及擁有審批 pull request 的權力。

github 和 gitlab 都提供"保護分支"（protected branch）這個功能。

issue 用於 bug追蹤和需求管理。建議先新建 issue，再新建對應的功能分支。功能分支總是為了解決乙個或多個 issue。

功能分支的名稱，可以與issue的名字保持一致，並且以issue的編號起首，比如"15-require-a-password-to-change-it"。

開發完成後，在提交說明裡面，可以寫上"fixes #14"或者"closes #67"。github規定，只要commit message裡面有下面這些動詞 + 編號，就會關閉對應的issue。

username/repository#issue_number。

pull request被接受以後，issue關閉，原始分支就應該刪除。如果以後該issue重新開啟，新分支可以復用原來的名字。

git有兩種合併：一種是"直進式合併"（fast forward），不生成單獨的合併節點；另一種是"非直進式合併"（none fast-forword），會生成單獨節點。

前者不利於保持commit資訊的清晰，也不利於以後的回滾，建議總是採用後者（即使用--no-ff引數）。只要發生合併，就要有乙個單獨的合併節點。

為了便於他人閱讀你的提交，也便於cherry-pick或撤銷**變化，在發起pull request之前，應該把多個commit合併成乙個。（前提是，該分支只有你乙個人開發，且沒有跟master合併過。）

git團隊協作流程

開發者 開始工作前 git checkout master git pull git checkout b branchname 工作中 git add git commit m message 工作完畢 git push 管理者 自己寫 開始工作前 git checkout b branchnam...

團隊協作git操作流程

git clone 轉殖 庫 git checkout b test 新建分支 modify some files 完成修改 git add 把修改加入stage中 git commit m 提交修改到test分支 review git checkout master 切換到master分支 git...

小團隊Git協作流程

git和svn 最大的差異在於git是分布式的管理方式而svn是集中式的管理方式。集中式 管理的核心是伺服器，所有開發者在開始coding之前必須從伺服器獲取 然後開發，最後解決衝突，提交。所有的版本資訊都放在伺服器上。基於集中式的 管理，完全依賴於 伺服器，如果是離線的情況下伺服器不能連線，那本地...