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
- $ 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/
