团队开发Git分支管理策略

开发生涯的前三年都是使用 svn，回首放佛如前世。自从用了 git ，整我的都神经了。

下面的内容确定不是什么教你如何用git提交代码，合并分支之类的。如今本人要从写术的层面提高一下本身文章的品质到道的层面。

使用git带来的分支疑惑

git 为何好，为何要用 git，这不是我本文想要说明的问题。

这里想要给你们分享一下本身使用过程当中产生的疑惑，以及解决的这些疑惑的过程。话又说回来，我如今依然充满疑惑。真不知道30岁的时候会不会不惑。

在使用 git 过程当中，它的分支功能让我真的欣喜若狂，不过这是把双刃剑，一不当心你会获得这种git路径图：

图片来源：阮一峰老师博客

个人疑惑：

1. 那么团队中咱们该使用怎样的分支策略来进行开发协做？

2. 在多人的团队中，咱们应该在 master 分支上直接开发吗？

3. 若是线上产生了bug该经过什么样方式的分支去修复？

4. 当有多个分支的时候，测试如何有效的参与进来每个分支的测试？

用成熟的工做流来解决问题

在解答上面的疑惑前，先介绍几个工做流，而后经过工做流的模式，来进行解答。由于咱们必须在某种设定的情景下，才能讨论解决问题的思路。

下面三种工做流方式，都是采用功能驱动开发，也就是先有需求产生，而后诞生对应的分支，而后开发，最后合并回来，完成使命被删除。

• Git flow

• Github flow

• Gitlab flow

关于这三种工做流的详细介绍，建议看看这篇文章-阮一峰

我如今采用的是 Git flow ，通过本身的实践，确实好用，解决很多问题。而后若是发现与本身的实际状况有些出入，能够根据需求作出些变更调整。

个人选择

我选择了 Git flow，它的主要特色是，长期存在两个分支：

• 主分支master

• 开发分支develop

而后，存在三种辅助分支，都是短时间的，而且一半状况下只应该存在本地，不要提交到远程库。

• 功能分支（feature branch）

• 补丁分支（hotfix branch）

• 预发分支（release branch）
  在进行上面的分支时，建议的命名规范：feature-xxx、release-xxx、hotfix-xxx

话外：我之前喜欢用下划线，后来发现打中线不须要按 shift ，哈哈，今后开始中线时代。

何时要功能分支？

当你拿到一个需求，或者不是一个立马需求上线的bug修复，那么就应该从 develop 开一个分支出来，完成这部分工做。完成后合并到 develop 分支。

何时要预发分支？

这个分支是为预发准备的，测试的介入，也只应该在该分支产生时才介入。当咱们不论是新功能开发，仍是通常的bug修改都差很少了。就应该从develop产生一个release分支，交给测试，若是有bug直接在上面修改。所有完成后，合并回develop，而且合并到master。

关于这个分支我得再多说几句。由于这是很是重要的一步，若是咱们使用了 git 钩子，当合并到 master 的时候，会自动发布到线上，因此这是临上线的最后一道屏障。

同时这里也解决了我一个疑惑，测试如何参与到git的每一个分支中来？答案是：测试不该该参与到每一个分支中来，只应该参与到release分支中去。其它的开发分支，都应该由开发人员本身测试，测试没有问题的时候才准许合并到develop，这就要求每个开发要提升本身交付的产品质量，如何确保本身交付的产品质量？自动化测试是个不错的选择，好了，打住，这不是咋们今天的主要任务，这个话题改天再聊。

何时须要补丁分支？

这种状况越少越好。由于它产生的缘由是：线上出了bug，而且必须立刻修复，无论你身在何方，当手机响起，拿出电脑改bug吧。

它与release 很像，都须要完成后，同时合并到:master与develop。不一样的是，它须要从master 上开一个分支出来。

注意这里没有测试的介入，一半来讲都是代码上某一个小的紧急bug，虽然很严重，可是能够很容易改动。固然若是有一些例外状况，应该让测试进行测试后再合并、发布。

总结

git 开发很好用，可是要按照必定规则合理使用分支。

另外，除了:master与develop 分支，其它分支都不该该出如今远程仓库中。

用git必定要结合它的各类钩子来使用，提高开发效率。这里后面来介绍下。

参考资料:

• [1]Git 工做流程

• [2]介绍一个成功的 Git 分支模型

介绍

我是何磊，主要工做就是写代码，持续创业者（之因此持续是由于到如今尚未干成功过一件事）。若是你有兴趣欢迎关注我，我会分享技术，还有生活，固然还有我创业的故事（说出个人痛，让你开心一下）。