概念

創(chuàng)建分支

分支是 Git 的核心概念，同時(shí) Git Workflow 也是基于分支進(jìn)行操作.

當(dāng)你新增功能或修復(fù) bug 時(shí)候，新建一個(gè)分支是一個(gè)不錯(cuò)的選擇，這將不會(huì)影響主分支 master. 所以你可以放心地嘗試和提交更改，直到代碼審查和運(yùn)行通過(guò)，才會(huì)被合并到 master 分支.

• 細(xì)微的 bug，可以在原分支進(jìn)行修改，不必新建分支.
• 一般新增功能而建立的分支，稱為「特性分支或功能分支」

此外，分支的命名應(yīng)該是可理解的，比如：
refactor-authentication ,
user-content-cache-key ,
make-retina-avatars ...

對(duì)了，你還需要記住一條規(guī)則是「任何時(shí)候， master 分支都處于可部署狀態(tài)」.

提交 commit 信息

commit 信息是一件值得注重的事情. 當(dāng)你提交代碼時(shí)，Git 會(huì)跟蹤代碼的改變和對(duì)應(yīng)的 commit 信息，這就是你工作的隱形記錄. 當(dāng)你的小伙伴在查閱代碼的時(shí)候，清晰的 commit 信息會(huì)讓他們迅速地明白 你做了什么，以及為什么這樣做.

commit 規(guī)范

add -新增需求
fix -修復(fù) bug
update -更新代碼
change -修改代碼

小改動(dòng)，一句 commit 信息說(shuō)明
大改動(dòng)，新建 issue 說(shuō)明情況，方案，變化:
git commit -m 'fix #[issue number]: [Short summary of the change].'

注：fix #[issue number] 會(huì)將對(duì)應(yīng)的 #[issue number] 關(guān)閉

粒度控制

代碼的提交，以完成一個(gè)獨(dú)立的功能單元為粒度. 切忌粒度過(guò)大或過(guò)小，比如完成多個(gè)功能或新增一個(gè)文件的提交，這不是一個(gè)推薦的做法. 粒度的關(guān)鍵在于，提交的代碼為獨(dú)立的功能單元，以便今后通過(guò)提交信息快速定位，進(jìn)行回滾或合并分支.

合并分支

Git 主分支的名字，默認(rèn)叫做 master。它是自動(dòng)建立的，版本庫(kù)初始化以后，默認(rèn)就是在主分支進(jìn)行開發(fā)。在日常工作中，需要新增功能，可以在另一條分支 branch_name 完成后，合并入主分支 master，部署發(fā)布.

創(chuàng)建 branch_name 分支：

git checkout -b branch_name master

完成功能開發(fā)后，將 branch_name 分支合并入 master：

# 切換至 master 分支
git checkout master

# 將 branch_name 分支合并入 master
git merge --no-ff branch_name

默認(rèn)情況下使用 git merge branch_name， Git 將會(huì)執(zhí)行 “快進(jìn)式合并“ ( fast-farward merge )，直接將 master 分支指向 branch_name 分支 , 不保留 branch_name 分支的開發(fā)記錄.

而使用 --no-ff ( no fast foward ) 參數(shù)后，將會(huì)在 master 分支新增一個(gè) commit 提交記錄，并強(qiáng)制保留 branch_name 分支的開發(fā)記錄. 對(duì)將來(lái)的代碼分析給予方便.
　　

git merge

解決分支合并的沖突

有時(shí)候合并操作并不會(huì)如此順利。如果在不同的分支中都修改了同一個(gè)文件的同一部分，Git 就無(wú)法干凈地把兩者合到一起，僅能依靠人手來(lái)解決.

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

Git 作了合并，但沒(méi)有提交，它會(huì)停下來(lái)等你解決沖突。要看看哪些文件在合并時(shí)發(fā)生沖突，可以用 git status 查閱：

$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")

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

    both modified:      index.html

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

任何包含未解決沖突的文件都會(huì)以未合并（unmerged）的狀態(tài)列出。Git 會(huì)在有沖突的文件里加入標(biāo)準(zhǔn)的沖突解決標(biāo)記，可以通過(guò)它們來(lái)手工定位并解決這些沖突。可以看到此文件包含類似下面這樣的部分：

<<<<<<< HEAD
<div id="footer">
      contact : orangehat@gmail.com
    </div>
=======
<div id="footer">
  please contact me at Aaaaaashu@gmail.com
</div>
>>>>>>> branch_name

可以看到 ======= 隔開的上半部分，是 HEAD（即 master 分支，在運(yùn)行 merge 命令時(shí)所切換到的分支）中的內(nèi)容，下半部分是在 branch_name 分支中的內(nèi)容。解決沖突的辦法無(wú)非是二者選其一或者由你親自整合到一起。比如你可以通過(guò)把這段內(nèi)容替換為下面這樣來(lái)解決：

<div id="footer">
  please contact me at orangehat@gmail.com
</div>

這個(gè)解決方案各采納了兩個(gè)分支中的一部分內(nèi)容，而且還刪除了 <<<<<<<，======= 和 >>>>>>> 這些行。在解決了所有文件里的所有沖突后，運(yùn)行 git add 將它們標(biāo)記為已解決狀態(tài)。因?yàn)橐坏捍妫捅硎緵_突已經(jīng)解決。

再運(yùn)行一次 git status 來(lái)確認(rèn)所有沖突都已解決：

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

     modified:   index.html

如果覺(jué)得滿意了，并且確認(rèn)所有沖突都已解決，也就是進(jìn)入了暫存區(qū)，就可以用 git commit 來(lái)完成這次合并提交。提交的記錄差不多是這樣：

Merge branch 'branch_name'

Conflicts:
  index.html
#
# It looks like you may be committing a merge.
# If this is not correct, please remove the file
#       .git/MERGE_HEAD
# and try again.
#

如果想給將來(lái)看這次合并的人一些方便，可以豐富 commit 信息，提供更多合并細(xì)節(jié)。比如你都作了哪些改動(dòng)，以及這么做的原因。有時(shí)候裁決沖突的理由并不直接或明顯，有必要略加注解。

實(shí)踐步驟

待續(xù) ...