git flow 与 gerrit

关于git flow

什么是git flow

git flow是一个用于管理多人合作的工作方式。在多人合作的项目中，通过制定一些使用git的规范，来避免多人开发导致的相互干扰。
想象一下，当你正在开发的一个功能A，需要某个其他人完成的功能B，而别人在这个功能B的提交中又参杂了另外一个还没有开发完的功能C。这个时候，你如果将功能B获取下来，就会同时获取到还未开发完的功能C的代码，这会导致你的功能A从完成变成了未完成，因为你当前的代码是不能运行的。
git flow就是让git的使用变得容易理解和管理而提出的。

git flow的基本概念

网上有很多git flow的使用说明，我就不在这里一一细说了，大家自行传送过去看看，git flow详解

git flow有些什么特点

1. 一个分支对应一件事。不管是feature开发、hotfix还是版本发布，都会对应一个分支。在这个分支上，只做关于这件事的开发。开发完成之后，合并到develop分支，如果需要加tag，就先加tag。然后把该分支删掉，这个事就算做完了。
2. 用分支的命名规则来区分该分支是做什么的。feature、hotfix、release等前缀，都是用于说明该分支是干什么的。当你用git branch -a的时候，就能一目了然地知道每个分支都是干什么的。
3. 清晰明了的分支职能。master分支永远都是稳定的，上面的每一个commit几乎都是用于发布的。develop是开发分支，每完成一个feature都会合并到develop，所以develop理论上应该都是功能完整的，不存在开发到一半的代码。feature分支是用于开发新功能的分支，由每个功能负责人进行管理。release分支是用于发布的分支，该分支应该只进行bugfix。
4. 简单的分支管理。release和hotfix完成后都要合并到master。每一个分支开发完成后，都要合并到develop。feature分支完成，合并到develop后就可以删除。release和hotfix要打上tag后才能删除。

明明白白用git flow

上面已经介绍了git flow的概念和流程，git flow其实是一种管理模型，并不是新增加了一种功能。如果想用省事的方式使用git flow，建议安装git flow命令集。不过不用命令集也是没有问题的。
只要我们理解了这套管理模型的意图，使用branch和merge等命令完全是可以的。

gerrit与git flow的结合

gerrit是什么

gerrit是用来进行code review的系统，相信在多人合作开发时会有很多团队选择使用它。gerrit的官网有相关的使用说明。
网上也有很多介绍gerrit的文章，我就不在这里介绍了。我想在这里记录的是我在使用gerrit中碰到的一些问题和解决办法。

Q & A

• 我提交的代码在review之后，发现别人在我之前merge了他的提交，我该怎么办？
• 答：这个时候你应该pull别人的代码，然后重新提交进行code review。因为你合并别人的代码后，可能导致当前的代码无法正常运行，比如别人修改了你使用到的接口。别以为没冲突就万事大吉了。具体操作为：在你要提交的分支上执行git pull --rebase，然后再push一次
• 我提交的代码被abandoned了，怎么办？
• 答：用git reset --soft HEAD^把这次提交的commit删掉，重新commit一次。--soft参数表示只删除commit信息，保留当前的代码，并且已经是stage的状态。
• push的时候提示unpack error（missing tree），怎么办？
• 答：解决办法是在push的时候加上--no-thin参数，具体命令为git push --no-thin origin HEAD:refs/for/master。这个问题是gerrit与git不兼容导致的bug。该bug的具体原因是git提交时，在gerrit生成了一个未关闭的review请求，但是这个请求并不属于任何一个提交。gerrit版本为2.6， git版本高于1.8.3就会有这个bug。
• 使用git flow时，feature开发完成，使用git merge feature合并到develop，push时提示no changes，gerrit拒绝提交，怎么办？
• 答：合并代码时使用git merge feature --squash，然后commit，再push一次。出现这种情况的原因是新开发的功能在feature分支上已经提交，merge到develop分支时，由于develop分支并没有更新，所以是一个完全合并，feature分支上的commit都被完整保留下来，每一个commit的Change-Id在gerrit看来都是已经经过code review的，所以gerrit拒绝了提交。这种方式会将feature分支上的所有commit合成为一个，将丢失中间的commit message。但能够更加符合git flow的管理方式，因为主程只关心最后将要进入到develop中的代码。