Git 分支 + gitflow

分支

在Git裏，master分支爲主分支。
HEAD嚴格來說不是指向提交，而是指向master，master纔是指向提交的，所以，HEAD指向的就是當前分支。
HEAD的指向就是當前編輯的分支。

---

創建分支

$ git checkout -b dev
Switched to a new branch 'dev'

git checkout命令加上-b參數表示創建並切換，相當於以下兩條命令：

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

用git branch命令查看當前分支：

$ git branch
* dev
  master

git branch命令會列出所有分支，當前分支前面會標一個*號。
繼續對test.txt修改爲：

ABCDEFD
EF
A

然後提交

$ git add test.txt

$ git commit -m "dev 1"
[dev 59f88ff] dev 1
 1 file changed, 2 insertions(+), 1 deletion(-)

然後切換爲原來的master分支：

$ git checkout master
Switched to branch 'master'

查看test.txt：

$ cat test.txt
ABCDEFD
EF

還是原來的內容，因爲剛剛是在dev分支上提交的，master分支並沒有操作。

現在，我們把dev分支的工作成果合併到master分支上：

$ git merge dev
Updating 308670f..59f88ff
Fast-forward
 test.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

git merge命令用於合併指定分支到當前分支。合併後，再查看test.txt的內容，就可以看到，和dev分支的最新提交是完全一樣的。

$ cat test.txt
ABCDEFD
EF
A

合併完成後，就可以放心地刪除dev分支了：

$ git branch -d dev
Deleted branch dev (was 59f88ff).

刪除後，查看branch，就只剩下master分支了：

$ git branch
* master

因爲創建、合併和刪除分支非常快，所以Git鼓勵你使用分支完成某個任務，合併後再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全。

---

衝突問題

準備新的feature1分支，繼續我們的新分支開發：

$ git checkout -b feature
Switched to a new branch 'feature'

修改test.txt，改爲：

ABCDEFD
EF
A
test

在feature分支上提交：

$ git add test.txt 
$ git commit -m "test"
[feature 3e10bba] test
 1 file changed, 2 insertions(+), 1 deletion(-)

切換到master分支：

$ git checkout master
Switched to branch 'master'

在master分支上把test.txt文件的最後一行改爲：

test2

提交：

$ git add test.txt

$ git commit -m "test2"
[master e38be0f] test2
 1 file changed, 2 insertions(+), 1 deletion(-)

現在，master分支和feature分支各自都分別有新的提交，變成了這樣：

這種情況下，Git無法執行“快速合併”，只能試圖把各自的修改合併起來，但這種合併就可能會有衝突，我們試試看：

$ git merge feature
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.

果然衝突了！Git告訴我們，readme.txt文件存在衝突，必須手動解決衝突後再提交。git status也可以告訴我們衝突的文件：

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:   test.txt

no changes added to commit (use "git add" and/or "git commit -a")

我們可以直接查看test.txt的內容：

$ cat test.txt
ABCDEFD
EF
A
<<<<<<< HEAD
test2
=======
test
>>>>>>> feature

Git用<<<<<<<，=======，>>>>>>>標記出不同分支的內容，我們修改如下後保存：

ABCDEFD
EF
A
test3

再提交：

$ git add test.txt

$ git commit -m "test3"
[master aeb90e2] test3

現在，master分支和feature分支變成了下圖所示：

用帶參數的git log也可以看到分支的合併情況：

$ git log --graph --pretty=oneline --abbrev-commit
*   aeb90e2 (HEAD -> master) test3
|\
| * 3e10bba (feature) test
* | e38be0f test2
|/
* 59f88ff dev 1
* 308670f start
* 07605be add F
* e3f073c write a test

最後，刪除feature1分支：

$ git branch -d feature
Deleted branch feature (was 3e10bba).

---

分支管理

合併分支時，如果可能，Git會用Fast forward模式，但這種模式下，刪除分支後，會丟掉分支信息。
如果要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支信息。

下面我們實戰一下–no-ff方式的git merge
請注意–no-ff參數，表示禁用Fast forward：

$ git merge --no-ff -m "no-ff" dev
Merge made by the 'recursive' strategy.
 test.txt | 1 +
 1 file changed, 1 insertion(+)

用git log看看分支歷史

$ git log --graph --pretty=oneline --abbrev-commit
*   9e9b552 (HEAD -> master) no-ff
|\
| * 0c37b1f (dev) add A
|/
*   aeb90e2 test3
|\
| * 3e10bba rest
* | e38be0f test2
|/
* 59f88ff dev 1
* 308670f start
* 07605be add F
* e3f073c write a test

---

隱藏未添加或未提交的內容

Git Stash
切換分支之前先git stash一下，它會把你的修改隱藏起來，這樣切換分支時就不會有問題。
在其他分支修改完之後，回來可以通過git stash list看到你的隱藏記錄，並且通過git stash apply stash@{0}這樣的方式把修改拿回來。

首先修改內容，然後git stash

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   test.txt

no changes added to commit (use "git add" and/or "git commit -a")

$ git stash
Saved working directory and index state WIP on master: 9e9b552 no-ff

$ git status
On branch master
nothing to commit, working tree clean

然後狀態就變爲沒有改動，內容也沒有改動。

查看歷史：

$ git stash list
stash@{0}: WIP on master: 9e9b552 no-ff

有一個歷史編輯，可以恢復

$ git stash apply stash@{0}
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   test.txt

no changes added to commit (use "git add" and/or "git commit -a")

繼續查看歷史記錄的話還是有那一條記錄的 需要用git stash drop刪除

$ git stash list
stash@{0}: WIP on master: 9e9b552 no-ff

$ git stash drop stash@{0}
Dropped stash@{0} (c1e9b0196aece29ff82e7e2e44d9cbc0ae66f046)

還有一種方法就是用git stash pop恢復：

$ git stash pop
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   test.txt

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (ba5fcc71496ab6d18f069fe0d077c07bfca5717f)

---

強制刪除分支

如果一個分支已經寫了好多東西，但是現在已經不需要了，現在還沒有合併，如果要刪除，需要強制刪除

$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 756d4af).

---

gitflow

Git的優點很多，但是這裏只列出我認爲非常突出的幾點。

由於是分佈式，所有本地庫包含了遠程庫的所有內容。
優秀的分支模型，打分支以及合併分支，機器方便。
快速，在這個時間就是金錢的時代，Git由於代碼都在本地，打分支和合並分支機器快速，使用個SVN的能深刻體會到這種優勢。
感興趣的，可以去看一下Git本身的設計，內在的架構體現了很多的優勢，不愧是出資天才程序員Linus (Linux之父) 之手

版本管理的挑戰

雖然有這麼優秀的版本管理工具，但是我們面對版本管理的時候，依然有非常大得挑戰，我們都知道大家工作在同一個倉庫上，那麼彼此的代碼協作必然帶來很多問題和挑戰，如下：

如何開始一個Feature的開發，而不影響別的Feature？

由於很容易創建新分支，分支多瞭如何管理，時間久了，如何知道每個分支是幹什麼的？
哪些分支已經合併回了主幹？
如何進行Release的管理？開始一個Release的時候如何凍結Feature, 如何在Prepare Release的時候，開發人員可以繼續開發新的功能？
線上代碼出Bug了，如何快速修復？而且修復的代碼要包含到開發人員的分支以及下一個Release?
大部分開發人員現在使用Git就只是用三個甚至兩個分支，一個是Master, 一個是Develop, 還有一個是基於Develop打得各種分支。這個在小項目規模的時候還勉強可以支撐，因爲很多人做項目就只有一個Release, 但是人員一多，而且項目週期一長就會出現各種問題。

Git Flow

就像代碼需要代碼規範一樣，代碼管理同樣需要一個清晰的流程和規範

Vincent Driessen 同學爲了解決這個問題提出了 A Successful Git Branching Model

下面是Git Flow的流程圖

上面的圖你理解不了？ 沒關係，這不是你的錯，我覺得這張圖本身有點問題，這張圖應該左轉90度，大家應該就很用以理解了。

Git Flow常用的分支
Production 分支
也就是我們經常使用的Master分支，這個分支最近發佈到生產環境的代碼，最近發佈的Release， 這個分支只能從其他分支合併，不能在這個分支直接修改

Develop 分支
這個分支是我們是我們的主開發分支，包含所有要發佈到下一個Release的代碼，這個主要合併與其他分支，比如Feature分支

Feature 分支
這個分支主要是用來開發一個新的功能，一旦開發完成，我們合併回Develop分支進入下一個Release

Release分支
當你需要一個發佈一個新Release的時候，我們基於Develop分支創建一個Release分支，完成Release後，我們合併到Master和Develop分支

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

Git Flow如何工作
初始分支
所有在Master分支上的Commit應該Tag

Feature 分支
分支名 feature/*

Feature分支做完後，必須合併回Develop分支, 合併完分支後一般會刪點這個Feature分支，但是我們也可以保留

Release分支
分支名 release/*

Release分支基於Develop分支創建，打完Release分之後，我們可以在這個Release分支上測試，修改Bug等。同時，其它開發人員可以基於開發新的Feature (記住：一旦打了Release分支之後不要從Develop分支上合併新的改動到Release分支)

發佈Release分支時，合併Release到Master和Develop， 同時在Master分支上打個Tag記住Release版本號，然後可以刪除Release分支了。

維護分支 Hotfix
分支名 hotfix/*

hotfix分支基於Master分支創建，開發完後需要合併回Master和Develop分支，同時在Master上打一個tag

Git Flow代碼示例
a. 創建develop分支

git branch develop
git push -u origin develop 

b. 開始新Feature開發

git checkout -b some-feature develop
# Optionally, push branch to origin:
git push -u origin some-feature    

# 做一些改動    
git status
git add some-file
git commit    

c. 完成Feature

git pull origin develop
git checkout develop
git merge --no-ff some-feature
git push origin develop

git branch -d some-feature

# If you pushed branch to origin:
git push origin --delete some-feature    

d. 開始Relase

git checkout -b release-0.1.0 develop

# Optional: Bump version number, commit
# Prepare release, commit

e. 完成Release

git checkout master
git merge --no-ff release-0.1.0
git push

git checkout develop
git merge --no-ff release-0.1.0
git push

git branch -d release-0.1.0

# If you pushed branch to origin:
git push origin --delete release-0.1.0   


git tag -a v0.1.0 master
git push --tags

f. 開始Hotfix

git checkout -b hotfix-0.1.1 master    
g. 完成Hotfix

git checkout master
git merge --no-ff hotfix-0.1.1
git push


git checkout develop
git merge --no-ff hotfix-0.1.1
git push

git branch -d hotfix-0.1.1

git tag -a v0.1.1 master
git push --tags

Git flow工具
實際上，當你理解了上面的流程後，你完全不用使用工具，但是實際上我們大部分人很多命令就是記不住呀，流程就是記不住呀，腫麼辦呢？

總有聰明的人創造好的工具給大家用, 那就是Git flow script.