概念
创建分支
分支是 Git 的核心概念，同时 Git Workflow 也是基于分支进行操作.
当你新增功能或修复 bug 时候，新建一个分支是一个不错的选择，这将不会影响主分支 master. 所以你可以放心地尝试和提交更改，直到代码审查和运行通过，才会被合并到 master 分支.
- 细微的 bug，可以在原分支进行修改，不必新建分支.
- 一般新增功能而建立的分支，称为「特性分支或功能分支」
此外，分支的命名应该是可理解的，比如：
refactor-authentication ,
user-content-cache-key ,
make-retina-avatars ...
对了，你还需要记住一条规则是「任何时候， master 分支都处于可部署状态」.
提交 commit 信息
commit 信息是一件值得注重的事情. 当你提交代码时，Git 会跟踪代码的改变和对应的 commit 信息，这就是你工作的隐形记录. 当你的小伙伴在查阅代码的时候，清晰的 commit 信息会让他们迅速地明白 你做了什么，以及为什么这样做.
commit 规范
add -新增需求
fix -修复 bug
update -更新代码
change -修改代码
小改动，一句 commit 信息说明
大改动，新建 issue 说明情况，方案，变化:
git commit -m 'fix #[issue number]: [Short summary of the change].'
注：fix #[issue number] 会将对应的 #[issue number] 关闭
粒度控制
代码的提交，以完成一个独立的功能单元为粒度. 切忌粒度过大或过小，比如完成多个功能或新增一个文件的提交，这不是一个推荐的做法. 粒度的关键在于，提交的代码为独立的功能单元，以便今后通过提交信息快速定位，进行回滚或合并分支.
合并分支
Git 主分支的名字，默认叫做 master。它是自动建立的，版本库初始化以后，默认就是在主分支进行开发。在日常工作中，需要新增功能，可以在另一条分支 branch_name 完成后，合并入主分支 master，部署发布.
创建 branch_name 分支：
git checkout -b branch_name master
完成功能开发后，将 branch_name 分支合并入 master：
# 切换至 master 分支
git checkout master
# 将 branch_name 分支合并入 master
git merge --no-ff branch_name
默认情况下使用 git merge branch_name， Git 将会执行 “快进式合并“ ( fast-farward merge )，直接将 master 分支指向 branch_name 分支 , 不保留 branch_name 分支的开发记录.
而使用 --no-ff ( no fast foward ) 参数后，将会在 master 分支新增一个 commit 提交记录，并强制保留 branch_name 分支的开发记录. 对将来的代码分析给予方便.
git merge
解决分支合并的冲突
有时候合并操作并不会如此顺利。如果在不同的分支中都修改了同一个文件的同一部分，Git 就无法干净地把两者合到一起，仅能依靠人手来解决.
$ 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 作了合并，但没有提交，它会停下来等你解决冲突。要看看哪些文件在合并时发生冲突，可以用 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")
任何包含未解决冲突的文件都会以未合并（unmerged）的状态列出。Git 会在有冲突的文件里加入标准的冲突解决标记，可以通过它们来手工定位并解决这些冲突。可以看到此文件包含类似下面这样的部分：
<<<<<<< HEAD
<div id="footer">
contact : orangehat@gmail.com
</div>
=======
<div id="footer">
please contact me at Aaaaaashu@gmail.com
</div>
>>>>>>> branch_name
可以看到 ======= 隔开的上半部分，是 HEAD（即 master 分支，在运行 merge 命令时所切换到的分支）中的内容，下半部分是在 branch_name 分支中的内容。解决冲突的办法无非是二者选其一或者由你亲自整合到一起。比如你可以通过把这段内容替换为下面这样来解决：
<div id="footer">
please contact me at orangehat@gmail.com
</div>
这个解决方案各采纳了两个分支中的一部分内容，而且还删除了 <<<<<<<，======= 和 >>>>>>> 这些行。在解决了所有文件里的所有冲突后，运行 git add 将它们标记为已解决状态。因为一旦暂存，就表示冲突已经解决。
再运行一次 git status 来确认所有冲突都已解决：
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: index.html
如果觉得满意了，并且确认所有冲突都已解决，也就是进入了暂存区，就可以用 git commit 来完成这次合并提交。提交的记录差不多是这样：
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.
#
如果想给将来看这次合并的人一些方便，可以丰富 commit 信息，提供更多合并细节。比如你都作了哪些改动，以及这么做的原因。有时候裁决冲突的理由并不直接或明显，有必要略加注解。
实践步骤
| 步骤 | git 操作 |
|---|---|
| 克隆代码 | git clone 远端代码 |
| 创建分支 | git checkout -b branch_name |
| 在分支中开发 | 无 |
| review 代码 | 无 |
| 第一轮测试 | 无 |
| 添加代码至分支 | git add somefile |
| 提交代码至分支 | git commit -m "本次提交注释" |
| 切换至主版本 | git checkout master |
| 获取远端最新代码 | git pull origin master |
| 合并分支至 master 分支 | git merge branch_name |
| 解决合并时产生的冲突 | |
| 第二轮测试 | 无 |
| 获取远端最新代码 | git pull origin master |
| 推送至 master 分支 | git push origin master |
| 若无问题，删除本地分支 | git branch -d branch_name |
待续 ...
网友评论