gitflow工作流通過為功能開發、發布準備和專案維護分配獨立的分支，讓發布迭代過程更流暢。gitflow工作流定義了乙個圍繞專案發布的嚴格分支模型，它會相對複雜一點，但提供了用於乙個健壯的用於管理大型專案的框架，非常適合用來管理大型專案的發布和維護。 貫穿整個開發周期，master和develop分支是一直存在的，master分支可以被視為穩定的分支， 而develop分支是相對穩定的分支，特性開發會在feature分支上進行，發布會在release分支上進行，而bug修復則會在hotfix分支上進行，這樣也有效避免了不同型別的開發工作在**層級的耦合和干擾。
1、歷史分支
gitflow工作流使用2個分支來記錄專案的歷史。 master分支儲存了正式發布的歷史，而develop分支作為功能的整合分支。 這樣也方便master分支上的所有提交分配乙個版本號。
2、功能分支
每個新功能位於乙個自己的分支，這樣可以push到**倉庫以備份和協作。 但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支。 當新功能完成時，合併回develop分支。 新功能提交應該從不直接與master分支互動。
3、發布分支
一旦develop分支上有了做一次發布（或者說快到了既定的發布日）的足夠功能，就從develop分支上checkout乙個發布分支。 新建的分支用於開始發布迴圈，所以從這個時間點開始之後新的功能不能再加到這個分支上，這個分支只應該做bug修復、文件生成和其它面向發布的任務。 一旦對外發布的工作都完成了， 發布分支合併到master分支並分配乙個版本號打好tag。 另外，這些從新建發布分支以來的做的修改要合併回develop分支。使用乙個用於發布準備的專門分支，使得乙個團隊可以在完善當前的發布版本的同時，另乙個團隊可以繼續開發下個版本的功能。
4、維護分支
維護分支或說是熱修復（hotfix）分支用於快速給產品發布版本（production releases）打補丁， 這是唯一可以直接從master分支fork出來的分支。 修復完成，修改應該馬上合併回master分支和develop分支（當前的發布分支），master分支應該用新的版本號打好tag。為bug修復使用專門分支，讓團隊可以處理掉問題而不用打斷其它工作或是等待下乙個發布迴圈。
如果你沒有認識到這個工作流很有用，那可能是因為你的開發工作還沒有複雜到乙個程度，乙個必須要規避**干擾、保證並行推進的程度。gitflow 工作
git flow工作流總結
寫在前面 文章的出處是由於作者本人對於gitlab 以及sourcetree的使用實在是摸不著頭腦，所以決定將各個地方詳細的截圖下來 因為我找的資料裡面對我來說都是不夠用的 由於在學校的時候沒有接觸過git，所以實習有些不適應，就這些天的使用就行相關的總結。現在在實習公司用的gitlab sourc...
Git Flow工作流總結
gitflow 工作流定義了乙個圍繞專案發布的嚴格分支模型。雖然比功能分支工作流複雜幾分，但提供了用於乙個健壯的用於管理大型專案的框架。gitflow 工作流沒有用超出功能分支工作流的概念和命令，而是為不同的分支分配乙個很明確的角色，並定義分支之間如何和什麼時候進行互動。除了使用功能分支，在做準備 ...
git flow工作流實際專案實踐
公司專案的開發流程主要是這樣 分為 develop分支 master分支 平時我開發的時候，主要在develop分支上改動 一般來講，有以下幾種改動方式 1.直接在develop上修改 這種一般是當前沒有大需求，沒有其他同事一起開發的情況下為了快速完成乙個任務才選擇直接改develop上的 實際上這...