Git 使用規范流程以及支管理策略
團隊開發中，遵循一個合理、清晰的Git使用流程，是非常重要的。
否則，每個人都提交一堆雜亂無章的commit，項目很快就會變得難以協調和維護。
下面是ThoughtBot 的Git使用規范流程。我從中學到了很多，推薦你也這樣使用Git。
第一步：新建分支
首先，每次開發新功能，都應該新建一個單獨的分支（這方面可以參考《Git分支管理策略》）。
# 獲取主干最新代碼
$ git checkout master
$ git pull
# 新建一個開發分支myfeature
$ git checkout -b myfeature
第二步：提交分支commit
分支修改后，就可以提交commit了。
$ git add --all
$ git status
$ git commit --verbose
git add 命令的all參數，表示保存所有變化（包括新建、修改和刪除）。從Git 2.0開始，all是 git add 的默認參數，所以也可以用 git add . 代替。
git status 命令，用來查看發生變動的文件。
git commit 命令的verbose參數，會列出 diff 的結果。
第三步：撰寫提交信息
提交commit時，必須給出完整扼要的提交信息，下面是一個范本。
Present-tense summary under 50 characters
* More information about commit (under 72 characters).
* More information about commit (under 72 characters).
http://project.management-system.com/ticket/123
第一行是不超過50個字的提要，然后空一行，羅列出改動原因、主要變動、以及需要注意的問題。最后，提供對應的網址（比如Bug ticket）。
第四步：與主干同步
分支的開發過程中，要經常與主干保持同步。
$ git fetch origin
$ git rebase origin/master
第五步：合并commit
分支開發完成后，很可能有一堆commit，但是合并到主干的時候，往往希望只有一個（或最多兩三個）commit，這樣不僅清晰，也容易管理。
那么，怎樣才能將多個commit合并呢？這就要用到 git rebase 命令。
$ git rebase -i origin/master
git rebase命令的i參數表示互動（interactive），這時git會打開一個互動界面，進行下一步操作。
下面采用Tute Costa的例子，來解釋怎么合并commit。
pick 07c5abd Introduce OpenPGP and teach basic usage
pick de9b1eb Fix PostChecker::Post#urls
pick 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend
# Rebase 8db7e8b..fa20af3 onto 8db7e8b
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
上面的互動界面，先列出當前分支最新的4個commit（越下面越新）。每個commit前面有一個操作命令，默認是pick，表示該行commit被選中，要進行rebase操作。
4個commit的下面是一大堆注釋，列出可以使用的命令。
-
pick：正常選中
-
reword：選中，并且修改提交信息；
-
edit：選中，rebase時會暫停，允許你修改這個commit（參考這里）
-
squash：選中，會將當前commit與上一個commit合并
-
fixup：與squash相同，但不會保存當前commit的提交信息
-
exec：執行其他shell命令
上面這6個命令當中，squash和fixup可以用來合并commit。先把需要合并的commit前面的動詞，改成squash（或者s）。
pick 07c5abd Introduce OpenPGP and teach basic usage
s de9b1eb Fix PostChecker::Post#urls
s 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend
這樣一改，執行后，當前分支只會剩下兩個commit。第二行和第三行的commit，都會合并到第一行的commit。提交信息會同時包含，這三個commit的提交信息。
# This is a combination of 3 commits.
# The first commit's message is:
Introduce OpenPGP and teach basic usage
# This is the 2nd commit message:
Fix PostChecker::Post#urls
# This is the 3rd commit message:
Hey kids, stop all the highlighting
如果將第三行的squash命令改成fixup命令。
pick 07c5abd Introduce OpenPGP and teach basic usage
s de9b1eb Fix PostChecker::Post#urls
f 3e7ee36 Hey kids, stop all the highlighting
pick fa20af3 git interactive rebase, squash, amend
運行結果相同，還是會生成兩個commit，第二行和第三行的commit，都合并到第一行的commit。但是，新的提交信息里面，第三行commit的提交信息，會被注釋掉。
# This is a combination of 3 commits.
# The first commit's message is:
Introduce OpenPGP and teach basic usage
# This is the 2nd commit message:
Fix PostChecker::Post#urls
# This is the 3rd commit message:
# Hey kids, stop all the highlighting
squash和fixup命令，還可以當作命令行參數使用，自動合并commit。
$ git commit --fixup
$ git rebase -i --autosquash
這個用法請參考這篇文章，這里就不解釋了。
第六步：推送到遠程倉庫
合并commit后，就可以推送當前分支到遠程倉庫了。
$ git push --force origin myfeature
git push命令要加上force參數，因為rebase以后，分支歷史改變了，跟遠程分支不一定兼容，有可能要強行推送（參見這里）。
第七步：發出Pull Request
提交到遠程倉庫以后，就可以發出 Pull Request 到master分支，然后請求別人進行代碼review，確認可以合并到master。
#p#
如果你嚴肅對待編程，就必定會使用”版本管理系統”（Version Control System）。
眼下最流行的”版本管理系統”，非Git莫屬。
相比同類軟件，Git有很多優點。其中很顯著的一點，就是版本的分支（branch）和合并（merge）十分方便。有些傳統的版本管理軟件，分支操作實際上會生成一份現有代碼的物理拷貝，而Git只生成一個指向當前版本（又稱”快照”）的指針，因此非常快捷易用。
但是，太方便了也會產生副作用。如果你不加注意，很可能會留下一個枝節蔓生、四處開放的版本庫，到處都是分支，完全看不出主干發展的脈絡。
Vincent Driessen提出了一個分支管理的策略（中文簡譯版），我覺得非常值得借鑒。它可以使得版本庫的演進保持簡潔，主干清晰，各個分支各司其職、井井有條。理論上，這些策略對所有的版本管理系統都適用，Git只是用來舉例而已。如果你不熟悉Git，跳過舉例部分就可以了。
一、主分支Master
首先，代碼庫應該有一個、且僅有一個主分支。所有提供給用戶使用的正式版本，都在這個主分支上發布。
Git主分支的名字，默認叫做Master。它是自動建立的，版本庫初始化以后，默認就是在主分支在進行開發。
二、開發分支Develop
主分支只用來分布重大版本，日常開發應該在另一條分支上完成。我們把開發用的分支，叫做Develop。
這個分支可以用來生成代碼的最新隔夜版本（nightly）。如果想正式對外發布，就在Master分支上，對Develop分支進行”合并”（merge）。
Git創建Develop分支的命令：
git checkout -b develop master
將Develop分支發布到Master分支的命令：
# 切換到Master分支
git checkout master
# 對Develop分支進行合并
git merge –no–ff develop
這里稍微解釋一下，上一條命令的–no–ff參數是什么意思。默認情況下，Git執行”快進式合并”（fast-farward merge），會直接將Master分支指向Develop分支。
使用–no–ff參數后，會執行正常合并，在Master分支上生成一個新節點。為了保證版本演進的清晰，我們希望采用這種做法。關于合并的更多解釋，請參考Benjamin Sandofsky的《Understanding the Git Workflow》。
三、臨時性分支
前面講到版本庫的兩條主要分支：Master和Develop。前者用于正式發布，后者用于日常開發。其實，常設分支只需要這兩條就夠了，不需要其他了。
但是，除了常設分支以外，還有一些臨時性分支，用于應對一些特定目的的版本開發。臨時性分支主要有三種：
* 功能（feature）分支
* 預發布（release）分支
* 修補bug（fixbug）分支
這三種分支都屬于臨時性需要，使用完以后，應該刪除，使得代碼庫的常設分支始終只有Master和Develop。
四、 功能分支
接下來，一個個來看這三種”臨時性分支”。
第一種是功能分支，它是為了開發某種特定功能，從Develop分支上面分出來的。開發完成后，要再并入Develop。
功能分支的名字，可以采用feature-*的形式命名。
創建一個功能分支：
git checkout -b feature-x develop
開發完成后，將功能分支合并到develop分支：
git checkout develop
git merge –no-ff feature-x
刪除feature分支：
git branch -d feature-x
五、預發布分支
第二種是預發布分支，它是指發布正式版本之前（即合并到Master分支之前），我們可能需要有一個預發布的版本進行測試。
預發布分支是從Develop分支上面分出來的，預發布結束以后，必須合并進Develop和Master分支。它的命名，可以采用release-*的形式。
創建一個預發布分支：
git checkout -b release-1.2 develop
確認沒有問題后，合并到master分支：
git checkout master
git merge –no-ff release-1.2
# 對合并生成的新節點，做一個標簽
git tag -a 1.2
再合并到develop分支：
git checkout develop
git merge –no-ff release-1.2
最后，刪除預發布分支：
git branch -d release-1.2
六、修補bug分支
最后一種是修補bug分支。軟件正式發布以后，難免會出現bug。這時就需要創建一個分支，進行bug修補。
修補bug分支是從Master分支上面分出來的。修補結束以后，再合并進Master和Develop分支。它的命名，可以采用fixbug-*的形式。
創建一個修補bug分支：
git checkout -b fixbug-0.1 master
修補結束后，合并到master分支：
git checkout master
git merge –no-ff fixbug-0.1
git tag -a 0.1.1
再合并到develop分支：
git checkout develop
git merge –no-ff fixbug-0.1
最后，刪除”修補bug分支”：
git branch -d fixbug-0.1
