團隊開發中，遵循一個合理、清晰的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莫屬。

[[144500]]

相比同類軟件，Git有很多優點。其中很顯著的一點，就是版本的分支（branch）和合并（merge）十分方便。有些傳統的版本管理軟件，分支操作實際上會生成一份現有代碼的物理拷貝，而Git只生成一個指向當前版本（又稱”快照”）的指針，因此非?？旖菀子谩?/p>

但是，太方便了也會產生副作用。如果你不加注意，很可能會留下一個枝節蔓生、四處開放的版本庫，到處都是分支，完全看不出主干發展的脈絡。

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