Git 版本控制 branch model 分支模型基本介紹

我相信大家對於 Git 版本控制不陌生了，Git 最大強項就是可以任意建立
branch，讓您開發程式不需要擔心原本的程式碼會被動到，造成不知道該怎麼
恢複原來的狀態。為了不影響產品發展，branch 對於大型工作團隊就顯得更重要
了，今天在網路上看到一篇 A successful Git branching model
http://nvie.com/posts/a-successful-git-branching-model/ 文章，裡面把
branch 使用方式寫得非常清楚，底下我會透過指令來說明如何使用簡單 branch
指令，當然請大家先去 github 或者https://bitbucket.org註冊申請帳號，如果不想申請帳號，也可以自己

在 local 端去執行。我用的是bitbucket.org這個伺服器，前面的文章我已經介紹

了這個伺服器，支援免費的私人倉庫，所以我選擇了它。

底下所引用的圖片都是經由 A successful Git branching model 文章所提供。

看到這張圖其實就說明了 branch 最重要的精神:『無限建立分支』，

大家也不用害怕看不懂這張圖，底下會看圖講故事說明 branch 分支狀況

主要分支

    master 主程式(除非重大 bug，則會分出 hotfix 分支)
    develop 開發分支(用來再另外分支出 Release, feature)

次要分支

    Hotfixes(由 master 直接分支，馬上修正 bug)
    Feature(由 develop 直接分支，開發新功能)
    Release(由 develop 直接分支，開發下一版 Release)

一、主要分支 ( The main branches )

當開發開始執行時，我們這時候必須將程式碼分成兩部份，一個是 master 另
一個就是 develop，master 主要用來 Release 產品專用，沒事就不要去動它，
假如要繼續開發新功能，或者是修正 Bug issue 就利用 develop 這分支來開發，
等待開發完成，要 Release 下一版產品時就將 develop merge 到
origin/master 分支，這樣才對，避免有人把 origin/master 改爛，底下這張圖
就說明了一切:

二、次要分支 ( Supporting branches )

次要分支這裡包含了  Feature, Release，Hotfixes。

Feature 跟 Release 都是從 develop 分支出來，最後都merge 回 develop branch，然後主分支 master 

再去 merge develop，這樣就完成了。

其中 Hotfixes 用來修正產品最重大 bug，所以由 origin/master 直接分支出來，修正之後在 merge 回master 跟 develop。

上面的例子，不一定套用在各開發過各中，因為 branch 免費，要多少有多少，

不一定完全都要 follow 此方法。

2.1、新功能分支 ( Feature branches )

branch off from: develop
Must merge back into: develop

看到上面圖說明，我想大家都很清楚，develop 分支出 Feature branch，用來開
發產品新功能，等到開發完整之後，在直接 merge 回 develop，下面直接用實際
例子來操作:

直接由 develop 開出分支 myfeature，並且直接切換過去

git checkout -b myfeature develop# 直接用 git branch 觀看目前位置  develop  master  * myfeature

經過編輯修改並且 commit
git add test.php

  git commit -a -m "Add: test.php"

合并分支:
先切換到 develop
$ git checkout develop

  Switched to branch 'develop'

利用 --no-ff 合并分支(稍後說明為什麼使用 --no-ff)

$ git merge --no-ff myfeature

  Merge made by recursive.   test.php |    3 +++   1 files changed, 3 insertions(+), 0 deletions(-)   create mode 100644 test.php

刪除 myfeature 分支

  $ git branch -d myfeature  Deleted branch myfeature (was dedf7ed).

將資料上傳

  $ git push origin develop

在說明 git merge --no-ff 之前，大家先看底下的圖。

有沒有很清楚發現差別，右邊是正常的 merge，會將原本的 commit log 合并成
一條，然而如果加上 --no-ff option 的話，commit log 會紀錄您是開分支出去
的，清楚紀錄您的分支操作步驟，建議大家多使用此方法，畢竟預設的 merge 看
到的效果不是我想要的。

2.2、Release branches

May branch off from: develop
Must merge back into: develop and master

Release branch 跟 feature branch 不同點就是: 前者需要 merge 回 master，
後者不需要，所以操作步驟會多一點，但是觀念不變啦。底下實際看個例子，操
作一次，大家就可以熟悉了。

從 develop 開新分支 release-1.3  

  git checkout -b release-1.3 develop

經過一堆 commit message

  git commit -a -m "Update: release 1.3"

切回去主分支 master

  git checkout master

master 合并 release-1.3 分支

  git merge --no-ff release-1.3

在 master 上面加上新 tag

  git tag -a v1.3 -m "Release v1.3 Tag"

切換到 develop 分支

  git checkout develop

一樣是 merge release-1.3

  git merge --no-ff release-1.3

上傳資料  

  git push

將新 Tag v1.3 更新到 origin/master

  git push origin v1.3

刪除 release-1.3 分支

  $ git branch -d release-1.3  Deleted branch release-1.3 (was 2c92042).

2.3、重大 issue 分支 ( Hotfix branches )

May branch off from: master
Must merge back into: develop and master
Branch naming 命名方式: hotfix-*

當我們產品線發現 critical bug 時，這就要從 master 拉出 hotfix-* 分支，
儘快將 bug 解決，並且同時 merge 到 develop 跟 master，底下實際例子操作:

從 master 開新分支 release-1.3

  git checkout -b hotfix-1.3.1 master

修改代碼，並且 commit

  git commit -a -m "Hotfix: release 1.3.1"

切換到 master

  git checkout master

merge hotfix-1.3.1 分支

  git merge --no-ff hotfix-1.3.1

加上修正過後的 Tag

  git tag -a v1.3.1 -m "Hotfix v1.3.1 Tag"

切換到 develop 分支  

  git checkout develop

一樣是 merge hotfix-1.3.1 分支

  git merge --no-ff hotfix-1.3.1

合并過後就刪除 hotfix-1.3.1 分支

  git branch -d hotfix-1.3.1

上傳資料

  git push

將 Tag v1.3.1 上傳

  git push origin v1.3.1

看完上面例子，是否清楚瞭解 branch 的基本用法，其實不會很難，看圖說故事而已。

備忘： 執行git push 的時候會提交  所有分支（但同時在伺服器也存在相同的分支）到伺服器上，

(即，本地有某個分支，但伺服器不存在該分支， git push是不會提交這個分支的）

如果想避免一起提交，（可能在其它分支上的工作還沒有完成），就需要設定一下git push的

預設行為。

git config --global push.default tracking

這樣一來，執行git push時，只會提交當前工作的分支到服務上。

FAQ： 

1. What does git push -u mean?

I have two different versions of git. In the 1.6.2 version, git push
does not have the -u option. It only appears in the 1.7.x version.

From the docs, the -u  --set-upstream  is related to the variable

branch.<name>.merge

in git config. This variable is described below:

Defines, together with branch.<name>.remote, the upstream branch for
the given branch. It tells git fetch/git pull which branch to merge.

What is an upstream branch ?

Answer: 

"Upstream" would refer to the main repo that other people will be
pulling from, e.g. your GitHub repo. The -u option automatically sets
that upstream for you, linking your repo to a central one. That way,
in the future, Git "knows" where you want to push to and where you
want to pull from, so you can use git pull or git push without
arguments. 

2. 怎麼把本地分支提交到伺服器上，（伺服器上不存在該分支）

答： 

假如你有分支 test, 做如下操作：

git push origin test

這句的意思是，把本地分支test提交到遠端origin倉庫中）

（ git中， origin  代表是遠程伺服器上的倉庫）

我們可以查看 .git/config  中的 origin的定義， 就知道origin指向什麼地方了（注意：只有用git clone的倉庫才存在該欄位，你也可以手動添加）

3. Can I make fast forwarding be off by default in git?

Answer: 

we can use the following:

git config --global --add merge.ff false

(merge.ff was introduced in Git 1.7.6)

From the documentation (search for merge.ff):

merge.ff

By default, git does not create an extra merge commit when
merging a commit that is a descendant of the current commit.
Instead, the tip of the current branch is fast-forwarded.
When
set to false, this variable tells git to create an extra merge
commit in such a case (equivalent to giving the --no-ff option
from the command line). When set to only, only such fast-forward
merges are allowed (equivalent to giving the --ff-only option
from the command line).

from: http://blog.wu-boy.com/2011/03/git-%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B6-branch-model-%E5%88%86%E6%94%AF%E6%A8%A1%E7%B5%84%E5%9F%BA%E6%9C%AC%E4%BB%8B%E7%B4%B9/