轉:Git 工作流程
http://www.ruanyifeng.com/blog/2015/12/git-workflow.html
Git 作為一個原始碼管理系統,不可避免涉及到多人協作。
協作必須有一個規範的工作流程,讓大家有效地合作,使得專案井井有條地發展下去。"工作流程"在英語裡,叫做"workflow"或者"flow",原意是水流,比喻專案像水流那樣,順暢、自然地向前流動,不會發生衝擊、對撞、甚至漩渦。
本文介紹三種廣泛使用的工作流程:
- Git flow
- Github flow
- Gitlab flow
如果你對Git還不是很熟悉,可以先閱讀下面的文章。
一、功能驅動
本文的三種工作流程,有一個共同點:都採用"功能驅動式開發"(Feature-driven development,簡稱FDD)。
它指的是,需求是開發的起點,先有需求再有功能分支(feature branch)或者補丁分支(hotfix branch)。完成開發後,該分支就合併到主分支,然後被刪除。
二、Git flow
最早誕生、並得到廣泛採用的一種工作流程,就是 。
2.1 特點
它最主要的特點有兩個。
首先,專案存在兩個長期分支。
- 主分支master
- 開發分支develop
前者用於存放對外發布的版本,任何時候在這個分支拿到的,都是穩定的分佈版;後者用於日常開發,存放最新的開發版。
其次,專案存在三種短期分支。
- 功能分支(feature branch)
- 補丁分支(hotfix branch)
- 預發分支(release branch)
一旦完成開發,它們就會被合併進develop或master,然後被刪除。
Git flow 的詳細介紹,請閱讀我翻譯的中文版《Git 分支管理策略》。
2.2 評價
Git flow的優點是清晰可控,缺點是相對複雜,需要同時維護兩個長期分支。大多數工具都將master當作預設分支,可是開發是在develop分支進行的,這導致經常要切換分支,非常煩人。
更大問題在於,這個模式是基於"版本釋出"的,目標是一段時間以後產出一個新版本。但是,很多網站專案是"持續釋出",程式碼一有變動,就部署一次。這時,master分支和develop分支的差別不大,沒必要維護兩個長期分支。
三、Github flow
是Git flow的簡化版,專門配合"持續釋出"。它是 Github.com 使用的工作流程。
3.1 流程
它只有一個長期分支,就是master,因此用起來非常簡單。
官方推薦的如下。
第一步:根據需求,從master拉出新分支,不區分功能分支或補丁分支。
第二步:新分支開發完成後,或者需要討論的時候,就向master發起一個(簡稱PR)。
第三步:Pull Request既是一個通知,讓別人注意到你的請求,又是一種對話機制,大家一起評審和討論你的程式碼。對話過程中,你還可以不斷提交程式碼。
第四步:你的Pull Request被接受,合併進master,重新部署後,原來你拉出來的那個分支就被刪除。(先部署再合併也可。)
3.2 評價
Github flow 的最大優點就是簡單,對於"持續釋出"的產品,可以說是最合適的流程。
問題在於它的假設:master分支的更新與產品的釋出是一致的。也就是說,master分支的最新程式碼,預設就是當前的線上程式碼。
可是,有些時候並非如此,程式碼合併進入master分支,並不代表它就能立刻釋出。比如,蘋果商店的APP提交稽核以後,等一段時間才能上架。這時,如果還有新的程式碼提交,master分支就會與剛釋出的版本不一致。另一個例子是,有些公司有釋出視窗,只有指定時間才能釋出,這也會導致線上版本落後於master分支。
上面這種情況,只有master一個主分支就不夠用了。通常,你不得不在master分支以外,另外新建一個production分支跟蹤線上版本。
四、Gitlab flow
是 Git flow 與 Github flow 的綜合。它吸取了兩者的優點,既有適應不同開發環境的彈性,又有單一主分支的簡單和便利。它是 Gitlab.com 推薦的做法。
4.1 上游優先
Gitlab flow 的最大原則叫做"上游優先"(upsteam first),即只存在一個主分支master,它是所有其他分支的"上游"。只有上游分支採納的程式碼變化,才能應用到其他分支。
就是一個例子,它明確規定,上游分支依次為:
- Linus Torvalds的分支
- 子系統(比如netdev)的分支
- 裝置廠商(比如三星)的分支
4.2 持續釋出
Gitlab flow 分成兩種情況,適應不同的開發流程。
對於"持續釋出"的專案,它建議在master分支以外,再建立不同的環境分支。比如,"開發環境"的分支是master,"預發環境"的分支是pre-production,"生產環境"的分支是production。
開發分支是預發分支的"上游",預發分支又是生產分支的"上游"。程式碼的變化,必須由"上游"向"下游"發展。比如,生產環境出現了bug,這時就要新建一個功能分支,先把它合併到master,確認沒有問題,再cherry-pick到pre-production,這一步也沒有問題,才進入production。
只有緊急情況,才允許跳過上游,直接合併到下游分支。
4.3 版本釋出
對於"版本釋出"的專案,建議的做法是每一個穩定版本,都要從master分支拉出一個分支,比如2-3-stable、2-4-stable等等。
以後,只有修補bug,才允許將程式碼合併到這些分支,並且此時要更新小版本號。
五、一些小技巧
5.1 Pull Request
功能分支合併進master分支,必須透過Pull Request(Gitlab裡面叫做 Merge Request)。
前面說過,Pull Request本質是一種對話機制,你可以在提交的時候,@相關人員或團隊,引起他們的注意。
5.2 Protected branch
master分支應該受到保護,不是每個人都可以修改這個分支,以及擁有審批 Pull Request 的權力。
和 都提供"保護分支"(Protected branch)這個功能。
5.3 Issue
Issue 用於 Bug追蹤和需求管理。建議先新建 Issue,再新建對應的功能分支。功能分支總是為了解決一個或多個 Issue。
功能分支的名稱,可以與issue的名字保持一致,並且以issue的編號起首,比如"15-require-a-password-to-change-it"。
開發完成後,在提交說明裡面,可以寫上"fixes #14"或者"closes #67"。Github規定,只要commit message裡面有下面這些 + 編號,就會關閉對應的issue。
- close
- closes
- closed
- fix
- fixes
- fixed
- resolve
- resolves
- resolved
這種方式還可以一次關閉多個issue,或者關閉其他程式碼庫的issue,格式是username/repository#issue_number。
Pull Request被接受以後,issue關閉,原始分支就應該刪除。如果以後該issue重新開啟,新分支可以複用原來的名字。
5.4 Merge節點
Git有兩種合併:一種是"直進式合併"(fast forward),不生成單獨的合併節點;另一種是"非直進式合併"(none fast-forword),會生成單獨節點。
前者不利於保持commit資訊的清晰,也不利於以後的回滾,建議總是採用後者(即使用--no-ff引數)。只要發生合併,就要有一個單獨的合併節點。
5.5 Squash 多個commit
為了便於他人閱讀你的提交,也便於cherry-pick或撤銷程式碼變化,在發起Pull Request之前,應該把多個commit合併成一個。(前提是,該分支只有你一個人開發,且沒有跟master合併過。)
這可以採用rebase命令附帶的squash操作,具體方法請參考我寫的《Git 使用規範流程》。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/14710393/viewspace-2131840/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Git工作流程Git
- Git 工作流程Git
- rails git工作流程AIGit
- 單人 Git 工作流程Git
- 初識 Git 工作流程Git
- Git分支工作流程Git
- 理解Git的工作流程Git
- 【第三篇】- Git 工作流程Git
- git 工作流程以及Git 工作區、暫存區和版本庫(筆記)Git筆記
- 轉:Git 使用規範流程Git
- 個人最順手的git工作流程Git
- 5 個 Git 工作流,改善你的開發流程Git
- git rebase 流程Git
- git操作流程Git
- Git基本命令 -- 基本工作流程 + 檔案相關操作Git
- 雅虎網站專案工作流程(轉)網站
- git的使用流程Git
- 工作流程
- git合作開發流程Git
- 簡單的Git流程Git
- 【git】前端使用git分支的開發流程Git前端
- Git 工作流Git
- Git工作流Git
- Gitflow 工作流程Git
- Spark工作流程Spark
- MapReduce工作流程
- Git程式碼版本控制流程Git
- git 小札 - 流程總覽Git
- git團隊開發流程Git
- Git協作流程詳解Git
- 【程式碼管理】GitHub超詳細圖文攻略 - Git客戶端下載安裝 GitHub提交修改原始碼工作流程 Git分支 標籤 過濾 Git版本工作流Github客戶端原始碼
- Git的工作liu'chenGit
- Git Workflow 工作指南Git
- Git工作流指南Git
- 理解Git工作流Git
- Git工作流指南:Gitflow工作流Git
- HTTPS工作流程HTTP
- 測試工作流程