git分支管理

关于git的分支管理，有位兄台做了很好的诠释，详情可以参考他分享的文章。

可是毛泽东他老人家也说了，要实际和理论相结合。具体地说就是他的模型适合大项目，大团队。相比现在的项目，连小米加步枪都不算，好歹老毛当年还有一大票人。这项目来来往往就两人，需求基本上是客户提什么做什么，连个迭代都凑不齐。

可是麻雀再小，也算个鸟，这叫特事特办。

去中心化但仍保持中心化

这话是哪位仁兄总结的，我觉得挺好，够绕口。简单的说，就是原来的svn采用单一的中心化管理方式，这玩意的缺点是一旦中心仓库挂掉甚至丢失，那所有的人都抓瞎了。现在git采用分布式的方式解决了这个问题，具体说就是没有中央仓库，大家都可以相互合成对方的版本，而且为了方便管理，每个人可以在本地提交N多个版本。

但是这也有问题，因为交付的版本最终仅能有一个，也就是说，还得有中心仓库。转了一大圈又回来了，但是使用git的好处，还是可以用一句话总结：谁用谁知道。

通常采用origin指代中心仓库，每个开发者都对origin做push和pull操作。不过除了这种中心化的push-pull关系外，每个开发者还可以从其他开发者或者小组处pull变更。例如，可能两个或更多的开发者一起开发一个大的特性，在往origin永久性的push工作代码之前，他们之间可以执行一些去中心化的操作。在上图中，分别有Alice和Bob、Alice和David、Clair和David这些小组。

我们的模型

我们详细说明。

主要分支

和很多的模型一样，一般都包含develop和master这两个分支。

develope分支为每日构建的代码源，一般到达一定稳定状态时(直观地说就是完成一个功能，然后开发人员测试ok后)，就可以提交版本了。在完成一个迭代，或者达到客户要求部署的功能时，develop的分支就可以提交至master了。

master分支就是部署在正式环境的代码。然后在某个里程碑结束时，还应该在master分支上打一个tag，以记录这个重要时刻。这个tag据说很重要，但是在后来很长一段时间我从来没有使用过，可以想象对于开发产品的团队一定很重要，但对于项目型的，一直未曾学会使用它。

热补丁分支

分支来源：master

必须合并回：develop和master

分支命名约定：hotfix-*

这是除了主要分支后唯一分支了，前面说过，项目团队太小，每次提交的时间和功能都不会太多，基本上不存在测试分支、特性分支等等。基本上是零库存。

但是热补丁分支是必须有的，由于每次提交的代码都是自测，“小小”错误总避免不了。加上政府的官员习惯了发言，不管如何上线后总要提出一点意见(由于领导比较忙，这个意见往往在上线一段时间后才提出来，最快也在下一次发布前才提出)。所以这时候热补丁分支就很重要了，因为这时候往往你机器上总有没有完成的代码，这时候你可以将代码提交在本地，然后从master复制一个热补丁分支，完成修改后，再继续回来。

总结

是一个三点一线的模型--develope->master->hotfix。