這節介紹的gitflow工作流借鑑自在nvie的vincent driessen。
gitflow工作流定義了乙個圍繞專案發布的嚴格分支模型。雖然比功能分支工作流複雜幾分，但提供了用於乙個健壯的用於管理大型專案的框架。
gitflow工作流沒有用超出功能分支工作流的概念和命令，而是為不同的分支分配乙個很明確的角色，並定義分支之間如何和什麼時候進行互動。除了使用功能分支，在做準備、維護和記錄發布也使用各自的分支。當然你可以用上功能分支工作流所有的好處：pull requests、隔離實驗性開發和更高效的協作。
工作方式
gitflow工作流仍然用**倉庫作為所有開發者的互動中心。和其它的工作流一樣，開發者在本地工作並push分支到要**倉庫中。
歷史分支
相對使用僅有的乙個master分支，gitflow工作流使用2個分支來記錄專案的歷史。master分支儲存了正式發布的歷史，而develop分支作為功能的整合分支。這樣也方便master分支上的所有提交分配乙個版本號。
剩下要說明的問題圍繞著這2個分支的區別展開。
功能分支
每個新功能位於乙個自己的分支，這樣可以push到**倉庫以備份和協作。但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支。當新功能完成時，合併回develop分支。新功能提交應該從不直接與master分支互動。
注意，從各種含義和目的上來看，功能分支加上develop分支就是功能分支工作流的用法。但gitflow工作流沒有在這裡止步。
發布分支
一旦develop分支上有了做一次發布（或者說快到了既定的發布日）的足夠功能，就從develop分支上fork乙個發布分支。新建的分支用於開始發布迴圈，所以從這個時間點開始之後新的功能不能再加到這個分支上 —— 這個分支只應該做bug修復、文件生成和其它面向發布任務。一旦對外發布的工作都完成了，發布分支合併到master分支並分配乙個版本號打好tag。另外，這些從新建發布分支以來的做的修改要合併回develop分支。
使用乙個用於發布準備的專門分支，使得乙個團隊可以在完善當前的發布版本的同時，另乙個團隊可以繼續開發下個版本的功能。
這也打造定義良好的開發階段（比如，可以很輕鬆地說，『這周我們要做準備發布版本4.0』，並且在倉庫的目錄結構中可以實際看到）。
常用的分支約定：
用於新建發布分支的分支: develop
用於合併的分支: master
分支命名: release-* 或 release/*
維護分支
維護分支或說是熱修復（hotfix）分支用於生成快速給產品發布版本（production releases）打補丁，這是唯一可以直接從master分支fork出來的分支。修復完成，修改應該馬上合併回master分支和develop分支（當前的發布分支），master分支應該用新的版本號打好tag。
為bug修復使用專門分支，讓團隊可以處理掉問題而不用打斷其它工作或是等待下乙個發布迴圈。你可以把維護分支想成是乙個直接在master分支上處理的臨時發布。
示例下面的示例演示本工作流如何用於管理單個發布迴圈。假設你已經建立了乙個**倉庫。
建立開發分支
第一步為master分支配套乙個develop分支。簡單來做可以本地建立乙個空的develop分支，push到伺服器上：
git branch develop
git push -u origin develop
以後這個分支將會包含了專案的全部歷史，而master分支將只包含了部分歷史。其它開發者這時應該轉殖**倉庫，建好develop分支的跟蹤分支：
git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop
現在每個開發都有了這些歷史分支的本地拷貝。
小紅和小明開始開發新功能
這個示例中，小紅和小明開始各自的功能開發。他們需要為各自的功能建立相應的分支。新分支不是基於master分支，而是應該基於develop分支：
git checkout -b some-feature develop
小紅完成功能開發
新增了提交後，小紅覺得她的功能ok了。如果團隊使用pull requests，這時候可以發起乙個用於合併到develop分支。否則她可以直接合併到她本地的develop分支後push到**倉庫：
git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature
第一條命令在合併功能前確保develop分支是最新的。注意，功能決不應該直接合併到master分支。衝突解決方法和集中式工作流一樣。
小紅開始準備發布
這個時候小明正在實現他的功能，小紅開始準備她的第乙個專案正式發布。像功能開發一樣，她用乙個新的分支來做發布準備。這一步也確定了發布的版本號：
git checkout -b release-0.1 develop
這個分支是清理發布、執行所有測試、更新文件和其它為下個發布做準備操作的地方，像是乙個專門用於改善發布的功能分支。
只要小紅建立這個分支並push到**倉庫，這個發布就是功能凍結的。任何不在develop分支中的新功能都推到下個發布迴圈中。
小紅完成發布
一旦準備好了對外發布，小紅合併修改到master分支和develop分支上，刪除發布分支。合併回develop分支很重要，因為在發布分支中已經提交的更新需要在後面的新功能中也要是可用的。另外，如果小紅的團隊要求code review，這是乙個發起pull request的理想時機。
git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1
發布分支是作為功能開發（develop分支）和對外發布（master分支）間的緩衝。只要有合併到master分支，就應該打好tag以方便跟蹤。
git tag -a 0.1 -m 「initial public release」 master
git push --tags
git有提供各種勾子（hook），即倉庫有事件發生時觸發執行的指令碼。可以配置乙個勾子，在你push**倉庫的master分支時，自動構建好對外發布。
終端使用者發現bug
對外發布後，小紅回去和小明一起做下個發布的新功能開發，直到有終端使用者開了乙個ticket抱怨當前版本的乙個bug。為了處理bug，小紅（或小明）從master分支上拉出了乙個維護分支，提交修改以解決問題，然後直接合併回master分支：
git checkout -b issue-#001 master
git checkout master
git merge issue-#001
git push
就像發布分支，維護分支中新加這些重要修改需要包含到develop分支中，所以小紅要執行乙個合併操作。然後就可以安全地刪除這個分支了：
git checkout develop
git merge issue-#001
git push
git branch -d issue-#001
git使用簡記 git分支使用
最近使用到git託管專案，記錄一下常用到git命令。這篇文章是專注記錄git分支部分常用的命令。1 檢視本地分支 git branch2 檢視遠端分支 git branch a3 檢視當前所在分支 git branch跟檢視本地分支的命令是一樣的，結果前面有 號的就是當前分支 4 切換到指定分支 如...
git 分支使用方式
需求場景 假如你看著教程完成了乙個專案，但是感覺第一次 掌握不牢，想要進行第二次 練習 如果某某心裡想我還有初始備份檔案，我此時的心裡獨白是你的硬碟還夠用嗎o o 1 建立乙個新分支 git本地倉庫預設是master分支 但是這分支最好只用來合併 merge 其他分支到這個分支上 2 檢視現在所有的...
git 使用彙總
gitclone ssh scp p p 29418 72060377 oscgerrit.vivo.xyz hooks commit msg modem adsp.vt.5.0 git hooks note 此位址為專案倉庫位址，就是 的路徑 b 檢視所有分支 git branch a c 檢出乙...