1.前言

在工作中因为要考虑到安全和维护的问题，不会像前面理论中说的那样直接。就像改个文件，总是拷贝一份，在副本中进行修改，可以了再替换原件，否则仍使用原件，这样可以有效避免偶然的失误影响整体的工作。当从这个角度去看时，会发现公司的许多繁琐的规定都是为了保护之前的劳动成果。

2.代码审查

代码审查通常称为Code Review或Review，常用的是谷歌开源的项目Gerrit。虽然界面不太友好，但是功能还是强大的，初次使用可以参考乐学乐的博客。

2.1.推送到远端

Gerrit可以理解为一个代理，封装了Git的远程仓库，通常不允许用户直接推送（push）内容到仓库分支上，而是refs/for/<远程分支名>。因为Gerrit监听refs/for/对应分支的主机端口，当有推送时，获取推送中的提交（commit）信息展示在服务的网页上，让用户选择交予哪个注册用户审查。通过了就合并到远程仓库对应的分支中，否则就退回修改，准备下次推送。

2.2.添加Change-Id

使用Gerrit时需注意的另一个问题就是给commit信息中添加Change-Id，一个SHA1的字符串。类似commit id，用来唯一标识某一次Review任务。这个不需要自己实现，可以拷贝相应脚本到本机Git的钩子路径下，具体命令如下：

$ gitdir=$(git rev-parse --git-dir); scp -p -P 29418 <你的注册邮箱>:hooks/commit-msg ${gitdir}/hooks/

有了这个脚本，每次推送时会自动添加Change-Id，最后在Gerrit上审查时看到的结果如下图所示：

Push.png

3.重新推送

当上次审查被拒或者审查前发现问题时，需修改并再次推送。若还按照上面的操作就会产生新的Review任务，令审查人员不知道哪个才是审查对象。所以应该保持Change-Id不变，在原有的任务下生成新的Patch Set。其实上次的代码也在任务的Patch Set中，不过Gerrit默认只使用最新的。

3.1.不改变提交信息

一般推荐使用git commit --amend命令重提，这样可以保持提交信息（commit message）不变，包括其中的Change-Id，特别方便还不容易错。但是需注意的是这个命令仅仅替换git commit，git add和git push仍不能少。

3.2.改变提交信息

若想完全控制新的提交，比如修改提交信息，其实也不难，就是多一步而已。

• git reset HEAD^，撤销上一次的提交，将版本回到上一版本；
• git add .，添加上次和这次的所有修改到暂存区；
• git commit -m <提交信息>，提交修改，提交信息最后添加上次的Change-Id；
• git push origin HEAD:refs/for/<远程分支名>，推送全部代码给Gerrit分配审查。

4.管理分支

Gitflow工作流是围绕项目发布时所包含的场景而严格定义交互的分支模型。它明确了每种分支的作用，不同分支在什么情况下交互等，让开发人员能够清楚地按照规范进行操作，避免彼此之间相互影响，导致整个项目的进度受到影响。具体的内容可以参考哲良的文章，介绍的相当详细。

Gitflow.png

• Master分支，作为默认分支，承担着记录历史的作用，存放着正式发布的版本代码，并打上标签（tag），告知版本号。
• Develop分支，从Master分支上拉出的新分支，专门用来开发，所有开发中的代码最后都合并到上面，平常最多使用的就是它。
• Feature分支，由Develop分支上根据功能拉出的新分支，数量不限，适合并行开发多个功能，提高开发效率。功能开发完毕，通过审查合并到Develop分支。
• Release分支，当完成需求，准备发布版本时，fork出的分支。在上面只操作和发布有关的，比如修复Bug等。不再添加功能和更改需求，这些可以在Develop上继续开发，但得到下个版本才能发布。
• 当发布了这个版本，就将代码合并到Master上，同时更新Develop上的代码。由于新功能也在开发，注意冲突的解决。
• Hotfix分支，用于处理紧急问题。那些严重影响用户使用的地方，等不到计划的下个版本发布，临时决定发个版本。由于也是发版，得和Release一样，将最终代码合并到Master和Develop上。

5.总结

Git相关的常见用法差不多都讲到了，毕竟内容很多，只能大概地指引个方向，大家在工作中肯定会遇到新的问题。别怕，不会就问谷哥和度娘，这是一个必然的学习过程。学以致用，你会发现自己慢慢地向着大神的地方爬去。