git分支策略

zhiwehu

    话说当年linux内核开发者林纳斯·托瓦兹（Linus Torvalds）为了更好的管理Linux内核开发，创下git（读『给特』）以来，时至今日，当下最流行的『版本管理系统』已非git莫属了！

    笔者私下认为，git相比其他的版本管理系统（csv, svn等）来，最大的方便莫过于分支（branch）的操作十分便捷，但项目开发分支如何管理，萝卜白菜各有所爱，见仁见智。笔者因工作需要，经常要参与国际化团队的协作开发，git乃是必不可缺之利器之一。在实际的开发过程中，偶有小得，不敢私藏，帖此一来做分享用，二来抛砖引玉。

一、团队开发者人人一个分支
    笔者曾经给一个创业团队从事开发工作，中间和几个印度人一起合作，几个印度人一上来便要强调代码版本管理的方式，即要求每个开发者都有一个branch，我称之为『开发者分支』，即每位开发都都从master分支上创建一个独属于自己的分支，自己所做的开发都在这个分支上进行，具体操作遵循以下步骤：
1. 开始工作前，先pull自己的分支的同时，merge主分支，这样保障自己的分支的代码是最新的（包括了主分支上最新的代码）
2. 在自己的分支上进行工作，commit和push代码
3. 当功能已经完成，并且经过了测试之后，push自己分支的代码
4. checkout到主分支，pull最新的主分支代码，merge自己分支的代码
4.1 如果这个时候，主分支代码并没有别人的代码（即还是步骤1那时的主分支代码的话），主分支merge自己的开发分支应该是没有任何问题
4.2 如果这个时候，主分支代码已经有别人的代码了（别人在你之前操作过同样的步骤），主分支的merge需要自己处理冲突，git merge会自动merge没有冲突的地方，有冲突的地方需要手工处理
5. push主分支， 这样主分支上就会有你的开发分支代码，并且已经进行过merge

    这种方式我们可以看到，适合一些小的，团队开发人员不太多的情况还是非常好的，尤其是每位开发者开发的功能都相对独立，也很容易在每个开发者的分支上查看commit记录等。但对于一些大的项目，或者开发人员比较多，开发功能又相互交叉的情况下，笔者觉得还不是很理想，因为第4步会经常碰到merge和冲突的情况，处理不好会让整个开发团队痛苦。

二、只有一个主分支和一个开发分支，其他为临时分支
    这是笔者从一个米国开发者那里学到的一种策略，后来发现这种方式MS更为流行和科学，尤其是在github上结合了pull request的使用。
    总的来说，就是一个项目只有两个分支，一个分支是主分支，这个分支只用于部署，对于一些大版本的部署就使用主分支；另一个分支为开发分支，所有开发人员都只在这个开发分支上进行操作，主分支可以定期或者定版本的从开发分支上合并用于部署。除了这两个固定的分支外，可以有很多临时性的分支，比如一个功能一个分支，一个bug修改一个分支等。当每个临时性的分支完成后，merge进开发分支，这个临时性分支就完成了历史的使命，可以说拜拜了。当然留着也行，只要你不觉得以后分支太多太花眼的话。具体的操作遵循以下的步骤：
1. 当有一个功能需要开发的时候，某位开发者从开发分支上创建一个新分支，这个分支的全名尽量和要完成的功能相关。假设要实现一个图片上传的功能，我们可以取名为image-upload，如果你取名abcde-123啥的，没人知道什么意思，别的开发人员或者主程以后肯定会砍你的。
2. 这位开发者开发过程中，对image-upload这个分支进行正常的commit和push代码
3. 当功能完成，并且通过测试以后，这位开发者觉得可以合并回开发分支了，这时
3.1 merge开发分支到image-upload分支，确保在他开发image-upload过程中，有别的开发者已经做过类似的操作，合并了其他的功能分支的代码。
3.2 push image-upload分支
3.3 checkout开发分支，再merge image-upload的分支，这个过程中也有可能还会有冲突，因为有可能就在执行3.2和3.3之间这短短的时间内也有别人做过操作了，解决冲突之后顺利把开发分支merge image-upload分支，这样开发分支上就有了image-upload分支的代码，并push开发分支
4. （可选项）可以删除image-upload分支了，然后进行下一个功能的开发操作，重新执行步骤1

    这种方式有一个好处就是不管开发人员有多少，固定的分支只有一个，一个开发分支，一个用于部署的主分支。同时我们可以看到，最有可能发生冲突的地方是在3.1，因为开发者在开发过程中，别人已经merge了新的代码到开发分支，而这部分的代码有可能和这位正在开发的代码有冲突，但是这种冲突发生在自己正在开发的代码上，所以处理起来应该没什么难度。至于3.3的冲突，可能性极小，就算发生了，因为仍然是自己正在开发的那些代码有冲突，处理起来问题不大。

    其实对于策略二来说，笔者曾经工作的项目团队是不允许每个开发者都自己去往开发分支上merge的，有这种权限的只有主程那个人。（这里说的权限并不是实际上一个权限系统，而是事先说好由谁来做这部分工作），因为我们的项目是放在github上的，我们使用了github的pull request的功能，即在步骤3.2之后，开发人员不需要往开发分支上去做merge操作，而是提交一个pull request到开发分支，由主程来审核是否通过，如果主程审核代码觉得没问题，他可以同意这个pull request，代码也就自动合并到开发分支上了，如果他不同意，可以让开发者继续进行某些修改直到同意。当然在此过程中，pull request的代码已经不能自动合并到开发分支上了（过程中有其他的pull request请求先通过了，不过我想一般主程不会干这种事情吧）主程可以要求开发者解决冲突后再同意pull request，顺利merge进开发分支。

    不管是哪种策略，笔者认为，目标是使用git来有效的提高效率，尤其是提高整个团队的协作效率，并且遵循一致的方式。当然，以前很多只有笔者一个人开发的项目，因为没有team member，笔者都是一个主分支到底的:-) 但是采用主分支（用于部署）和开发分支分开的方式，更加科学和明确，应该会在以后项目中自经常采用。

【以上文字，皆为原创，如需转载，请注明出处】

转自 http://www.web4py.com/blog/git%E ... %E7%AD%96%E7%95%A5/
作者：Jeffrey