gitflow存在兩個記錄專案歷史的分支
develop分支將包含專案的完整歷史記錄，而master將包含簡化版本。現在，其他開發人員應該轉殖**儲存庫，並為develop建立跟蹤分支。
⚠️：基於master分支建立develop分支。
每個新功能應駐留在其自己的（特性）分支中，可以將其推送到**儲存庫以進行備份/協作。但是，特性（feature）分支不是基於master分支建立，而是將develop分支作為自己的父分支。功能完成後，它會重新合併到develop分支中，並刪除當前的feature分支。feature分支絕不能直接與master分支進行互動。
⚠️：通常我們基於最新的develop分支建立feature分支。
一旦develop分支獲得了足夠的發布功能（或臨近預定的發布日期），你就需要基於develop分支建立release分支，建立此分支將開始下乙個發行週期，因此此刻之後release分支不能新增任何新功能-除了錯誤修復，文件生成以及其他面向發行版的任務的改動。一旦準備好發布，release分支將合併到master分支並用版本號標記。另外，應該將其合併回develop分支，因為release分支可能已經存在新的提交。
使用專用的分支進行發布可以讓我們在發布的同時，其他團隊可以繼續為下個發行版本開發新功能，而不影響此次發布。它還建立了明確定義的開發階段（例如，可以很容易地說：「本週我們正在為版本4.0做準備，並且可以在儲存庫的結構中實際看到它「）。
一旦release分支準備好發布，它將被合併到master和develop分支中，然後release分支將被刪除。重新合併到develop分支中很重要，因為關鍵更新可能已新增到release分支，並且新功能需要訪問這些更新。如果您的組織強調code review，那麼這將是合併到develop的理想場景。
⚠️：release分支基於develop分支。
維護或「hotfix」分支用於快速修補生產版本。hotfix分支與release分支和feature分支很像，只是hotfix分支是基於主版本而不是開發版本的。
hotfix是唯一應直接從master建立的分支
修復程式完成後，應將其合併到master和develop（或當前release分支）中，隨後刪除hotfix分支，並應使用更新的版本號（tag）標記master分支。
擁有專門的錯誤修復開發線，您的團隊可以在不中斷其餘工作流程或不等待下乙個發布週期的情況下解決問題。您可以將hotfix分支視為直接與master一起使用的臨時發行分支。
本文介紹了gitflow的工作流程
Git Flow分支管理
也就是我們經常使用的master分支，這個分支最近發布到生產環境的 最近發布的release，這個分支只能從其他分支合併，不能在這個分支直接修改。當我們在production發現新的bug時候，我們需要建立乙個hotfix,完成hotfix後，我們合併回master和develop分支，所以hotf...
git flow分支管理總結
git flow 流程例項 分支命名規範 git flow是構建在git之上的乙個組織軟體開發活動的模型，是在git之上構建的一項軟體開發最佳實踐。核心分支是指master和dev分支 主分支 master 開發主分支 develop 臨時分支是指 feature release hotfix分支，...
分支管理策略
通常，合併分支時，如果可能，git會用fast forward模式，但這種模式下，刪除分支後，會丟掉分支資訊。如果要強制禁用fast forward模式，git就會在merge時生成乙個新的commit，這樣，從分支歷史上就可以看出分支資訊。下面我們實戰一下 no ff方式的git merge 1....