Git Flow，Git團隊協作最佳實踐Git Flow，Git團隊協作最佳實踐

Git是一個很好的版本管理工具，不過相比于傳統的版本管理工具，學習成本比較高，

實際開發中，如果團隊成員比較多，開發疊代頻繁，對Git的應用比較混亂，會産生很多不必要的沖突或者代碼丢失等。

就像寫代碼需要代碼規範一樣，使用Git進行代碼管理同樣需要一個清晰的流程和規範， Git Flow就是一個被廣泛認可的Git使用最佳實踐。

應用這個規範可以使得版本庫的演進保持簡潔，主幹清晰，各個分支有不同的職責，在很大程度上減少沖突的産生。

Git Flow通過對分支的管理，實作版本疊代的清晰。

這個流程圖是應用Git Flow的标準流程，可以看到，不同的分支在産品研發和上線的不同階段有不同的作用，扮演了不同的角色。

結合圖檔，簡單介紹一下不同分支的職責。

這個分支是釋出到生産環境的代碼，這個分支隻能從其他分支合并，不能在這個分支直接修改。

這個分支是主開發分支，包含所有要釋出到下一個Release的代碼，這個主要合并自其他分支，比如Feature分支。

Feature 分支主要用來開發一個新的功能，一旦開發完成，合并回Develop分支，并且進入下一個Release，Feature分支可以選擇删除或者保留。

當需要釋出一個新Release的時候，基于Develop分支建立一個Release分支，Release分支在測試過程中可能會修改，完成Release後，合并到Master和Develop分支。

當在Production發現新的Bug時候，需要建立一個Hotfix分支, 完成Hotfix後，合并回Master和Develop分支，是以Hotfix的改動會進入下一個Release。

Master分支是線上穩定分支，Release通常用作測試分支，Develop分支是開發應用的主分支

所有的功能開發都在Feature分支進行，然後合并到Develop分支

Release分支釋出後出現問題，直接在Release分支修改，避免Develop分支代碼污染

我們在應用Git Flow的時候，也遇到了一些問題，比如開發結束後，在develop分支進行merge開發分支操作，出現沖突如果不能很好的解決，容易對develop分支的代碼造成污染。

下面是實際開發中使用的流程，在Feature分支上合并develop代碼，然後合并到develop分支上，流程更加清晰，沖突優先在開發分支解決。

一個開發人員典型的送出流程：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

<code>//</code><code>建立分支</code>

<code>git checkout develop</code>

<code>git pull origin develop</code>

<code>git checkout -b myfeature</code>

<code>//</code><code>在分支上開發</code>

<code>git add ***</code>

<code>git commit -m </code><code>"*****"</code>

<code>//</code><code>在分支開發過程中合并develop分支到本分支（先把自己的工作commit到本地）</code>

<code>git checkout myfeature</code>

<code>git merge develop</code>

<code>（如果沒有沖突，就繼續開發，如果有沖突，執行下面過程）</code>

<code>首先在本地解決沖突，再把沖突解決commit</code>

<code>//</code><code>在分支開發結束，需要将本分支合并到develop分支（先把自己的工作commit到本地）</code>

<code>git merge myfeature</code>

<code>（如果沒有沖突，就推送到遠端）</code>

<code>git push origin develop</code>

<code>（如果有沖突，則解決沖突，再commit，并推送到遠端：）</code>

應用Git Flow的目的是更好的進行版本管理和持續內建，有些細節并不一定要遵循這個模型，可以根據團隊規模進行簡單的調整，适合的才是最好的。　　

本文轉自邴越部落格園部落格，原文連結：http://www.cnblogs.com/binyue/p/5972141.html，如需轉載請自行聯系原作者