企業級開發：Gitflow Workflow工做流

我說的如下流程，sourceTree等工具已經完美的支持了，鼠標點兩下就完成了。簡直是完美。

簡介

Feature Branch Workflow是一種很是靈活的開發方式。對於一些規模比較大的團隊，最好就是給特定的分支賦予不一樣的角色。除了功能分支(feature branch)，Gitflow Workflow還使用獨立的分支來準備發佈(preparing)，維護(maintaining), 和記錄版本(recording releases)。

分支類型和流程

下圖能說明整個流程，只要你看得懂的話。該模式來自 Nvie

• feature（多個、玫紅）。主要是本身玩了，差很少的時候要合併回develop去。從不與master交互。

• develop（1個、黃色）。主要是和feature以及release交互。

• release（同一時間1個、綠色）。老是基於develop，最後又合併回develop。固然對應的tag跑到master這邊去了。生命週期很短，只是爲了發佈

• hotfix（同一時間1個、紅色）。老是基於master，並最後合併到master和develop。生命週期較短，用了修復bug或小粒度修改發佈。

• master（1個藍色）。沒有什麼東西，僅是一些關聯的tag，因從不在master上開發。

在這個模型中，master和develop都具備象徵意義。master分支上的代碼老是穩定的（stable build），隨時能夠發佈出去。develop上的代碼老是從feature上合併過來的，能夠進行Nightly Builds，但不直接在develop上進行開發。當develop上的feature足夠多以致於能夠進行新版本的發佈時，能夠建立release分支。

release分支基於develop，進行很簡單的修改後就被合併到master，並打上tag，表示能夠發佈了。緊接着release將被合併到develop；此時develop可能往前跑了一段，出現合併衝突，須要手工解決衝突後再次合併。這步完成後就刪除release分支。

當從已發佈版本中發現bug要修復時，就應用到hotfix分支了。hotfix基於master分支，完成bug修復或緊急修改後，要merge回master，打上一個新的tag，並merge回develop，刪除hotfix分支。

因而可知release和hotfix的生命週期都較短，master/develop雖然老是存在但卻不常使用。

分支詳解

主分支 （Historical Branches）

主分支是全部開發活動的核心分支。全部的開發活動產生的輸出物最終都會反映到主分支的代碼中。主分支分爲master分支和development分支。

master 分支

master分支上存放的應該是隨時可供在生產環境中部署的代碼（Production Ready state）。當開發活動告一段落，產生了一份新的可供部署的代碼時，master分支上的代碼會被更新。同時，每一次更新，最好添加對應的版本號標籤（TAG）。

develop分支

develop分支是保存當前最新開發成果的分支。一般這個分支上的代碼也是可進行每日夜間發佈的代碼（Nightly build）。所以這個分支有時也能夠被稱做整合分支（integration branch）。

輔助分支

輔助分支是用於組織解決特定問題的各類軟件開發活動的分支。輔助分支主要用於組織軟件新功能的並行開發、簡化新功能開發代碼的跟蹤、輔助完成版本發佈工做以及對生產代碼的缺陷進行緊急修復工做。這些分支與主分支不一樣，一般只會在有限的時間範圍內存在。

輔助分支包括：

1. 用於開發新功能時所使用的feature分支；

2. 用於輔助版本發佈的release分支；

3. 用於修正生產代碼中的缺陷的hotfix分支。

以上這些分支都有固定的使用目的和分支操做限制。從單純技術的角度說，這些分支與Git其餘分支並無什麼區別，但經過命名，咱們定義了使用這些分支的方法。

feature 分支

使用規範：

1. 能夠從develop分支發起feature分支

2. 代碼必須合併回develop分支

3. feature分支的命名可使用除master，develop，release-*，hotfix-*以外的任何名稱

feature分支（有時也能夠被叫作「topic分支」）一般是在開發一項新的軟件功能的時候使用，這個分支上的代碼變動最終合併回develop分支或者乾脆被拋棄掉（例如實驗性且效果很差的代碼變動）。

release分支（preparing）

使用規範：

• 能夠從develop分支派生

• 必須合併回develop分支和master分支

• 分支命名慣例：release-*

release分支是爲發佈新的產品版本而設計的。在這個分支上的代碼容許作小的缺陷修正、準備發佈版本所需的各項說明信息（版本號、發佈時間、編譯時間等等）。經過在release分支上進行這些工做可讓develop分支空閒出來以接受新的feature分支上的代碼提交，進入新的軟件開發迭代週期。

當develop分支上的代碼已經包含了全部即將發佈的版本中所計劃包含的軟件功能，而且已經過全部測試時，咱們就能夠考慮準備建立release分支了。而全部在當前即將發佈的版本以外的業務需求必定要確保不能混到release分支以內（避免由此引入一些不可控的系統缺陷）。

成功的派生了release分支，並被賦予版本號以後，develop分支就能夠爲「下一個版本」服務了。所謂的「下一個版本」是在當前即將發佈的版本以後發佈的版本。版本號的命名能夠依據項目定義的版本號命名規則進行。

hotfix分支（maintaining）

使用規範：

• 能夠從master分支派生

• 必須合併回master分支和develop分支

• 分支命名慣例：hotfix-*

除了是計劃外建立的之外，hotfix分支與release分支十分類似：均可以產生一個新的可供在生產環境部署的軟件版本。

當生產環境中的軟件遇到了異常狀況或者發現了嚴重到必須當即修復的軟件缺陷的時候，就須要從master分支上指定的TAG版本派生hotfix分支來組織代碼的緊急修復工做。

這樣作的顯而易見的好處是不會打斷正在進行的develop分支的開發工做，可以讓團隊中負責新功能開發的人與負責代碼緊急修復的人並行的開展工做。

問題

管理衝突

1. 多個Feature 分支開發完成，提交到develop 分支時，修改了共同的模塊。

2. release 分支或者hotfix 分支修改了bug合併回develop時，發現develop分支已經往前面走了一截。

在執行可能有衝突的操做前，先查看一下 暫存區 和 工做目錄，保證其中沒有修改。

好比使用git stash就能夠把暫存區 和 工做目錄的修改保存起來，讓暫存區 和 工做目錄處於乾淨的狀態。

更進一步

Gitflow workflow 和pull request 組合起來使用，代碼審查機制的加入，會讓這個模式大放異彩。下一篇文章中， 我會詳細介紹 代碼審查????。

擴展：Forking Workflow

Forking Workflow與以上討論的工做流很不一樣，一個很重要的區別就是它不僅是多個開發共享一個遠程倉庫(central repository)，而是每一個開發者都擁有一個獨立的服務端倉庫。也就是說每一個contributor都有兩個倉庫：本地私有的倉庫和遠程共享的倉庫。

Forking Workflow

Forking Workflow這種工做流主要好處就是每一個開發者都擁有本身的遠程倉庫，能夠將提交的commits推送到本身的遠程倉庫，但只有工程維護者纔有權限push提交的commits到官方的倉庫，其餘開發者在沒有受權的狀況下不能push。Github不少開源項目都是採用Forking Workflow工做流。

文章來源

Git版本控制與工做流

基於git的源代碼管理模型——git flow