git分支管理

1.串行需求

串行需求开发模式: 所有个人分支都是同一个需求的开发,  可随时向develop分支提PR合代码。

2.并行开发

并行需求开发模式：

①不同发布日期的feature必须工作在独立的feature分支上。相同发布日期的需求可以共用一个feature分支，也可以拉单独feature分支。

②只有(距离当前最近的)下一个发布日要上线的feature分支可以随时向develop分支提PR合并, 非下一个发布日上线的feature分支则不可以，必须在下一个发布日的需求发版之后才能向develop分支合并。develop分支只能包含在下一个发布日上线的改动。

③非下一个发布日上线需求要联调且不满足合并到develop分支条件时，在相应feature分支上进行联调，可将feature分支内容发布到dev环境。

思所有feature分支都拉自develop分支。下一个发布日上线的需求应该尽早、频繁地向develop分支合并，以使develop总是保持下一个发布日要上线的最新的代码。

⑤个人分支从feature分支拉出来，提PR merge到feature分支。理论上下一个发布日上线的需求可以不拉个人分支，直接在feature分支上开发，提PR merge到develop分支。随着时间的滚动，是否是下个发布日上线的feature分支这个标签是动态的。因此推荐总是从feature分支拉出个人分支进行开发，提PR merge到feature分支。

Always pull before push/merge. 所有feature分支每日至少从develop分支pull一次代码，所有feature分支到develop分支的PR/merge动作之前必须先pull develop代码到当前feature分支。这是强制且默认的规则，就不体现在图里了。

推荐：feature分支名称包含明确发布日期，比如以0424结尾，表示这个feature分支在4月24号这个发布日上线。

hotfix要PR到QA的Beta分支走测试流程，图里有省略。

存在问题：

develop分支只包含最近一次上线的最新内容，不是所有的最新内容。持续集成是构建在develop分支上的，因此非下个发布日上线的需求无法被每日持续集成覆盖到。

对计划变更敏感。主要是一旦下一个发布日上线需求延迟较大时，会影响到下下个发布日的合并计划。对这种情况需求尽量控制避免发生。当下一个发布日上线的需求因为某些原因要被取消时，其代码已经被merge到develop分支和所有其他feature分支，回滚几乎是不可能的任务了，这种情况就得绝对避免。

gitflow图解：

开发模式的选择:

我们所熟知的开发协作模式有以下三种：
主干开发模式。这也是极限编程里提倡的一种模式，每一次代码提交都是合并到 master 主干分支，确保 master 随时是可发布状态。但是它对代码开发质量以及持续集成自动化和完善程度要求非常高，通常一般的团队很难做到。
gitflow 开发模式。因为 git 的流行，gitflow 是专门基于 git 代码管理的工作流工具，它的特点是在 master 分支之外，会有一条常驻 develop 开发分支，所有功能开发和缺陷修复都在这个分支上再建立分支。发布时合入一个从 master 分支中签出的 release 分支，最终发布的是 release 分支代码，然后 release 分支再合并回 master 和 develop 分支。

分支开发模式。相对于 gitflow 模式，分支开发模式会简单清晰很多。它的特点是，功能开发或缺陷修复从 master 签出独立的一个 feature 或 bug 分支，发布前从 master 分支签出一个 release 分支，并将要发布的 feature 或 bug 分支合入。发布完成后，release 分支合入 master 分支。

开发模式的选型原则
上面我分别介绍了三种开发模式的特点，那么，在实际操作中，我们选择哪一种比较好呢？
这里的选型原则就是：一看这几种模式的适用场景；二看我们实际的使用场景是怎么样的。
下面，我们分别看看主干开发和 gitflow 开发这两种模式。
主干开发模式。它的特点是，所有的代码变更直接提交到 master 分支，这种情况比较适合规模较大的应用，这类应用自身集中了所有的需求功能点，且需求串行开发，需要多人协作共同完成同一个需求，发布时间点明确、统一。
这种模式最简单，且便于管理，不需要再建立各种分支。我们之所以在极限编程中提倡这种模式，也是因为这种模式最简单，最便捷，也最高效。因为我们的软件架构在早期还是单体结构且分层架构的，代码相对集中，所以，主干开发模式也是适用的。
但是，在现实场景下，需求总是层出不穷的，所以就需要需求并行开发。这就会产生这样一种情况：同一应用会有多个团队在同时提交不同需求的代码，且每个需求发布的时间点是不同的。
所以如果采用主干开发模式，就可能会将还没有经过测试验证的代码发布到线上。这时，我们就需要在代码里预设很多功能开关配置，这样一来，在应用正式上线前，代码可以发布，但是功能不开放，而这样也必然会增加代码的复杂度。
所以，就有了 gitflow 开发模式。
gitflow 开发模式能够适应并行开发，解决上述我们所说的问题，而且 gitflow 工具能够从技术层面帮我们解决各种分支合并问题。
通过上面 gitflow 的图示，我们可以看出，gitflow 开发模式带来的分支的管理代价还是比较高的，且随着分支增加，开发人员之间的沟通协作成本也会随之提高。
同时，gitflow 开发模式还是在代码相对集中的应用场景中更加适用，因此，基于这个应用完成较多的并行需求，就需要通过多个分支来管理。
在现实场景中，尽管我们日常需求非常多，但是这些需求拆解下来的功能都是集中在某个或某几个应用上的吗？
其实不然。我们从原来的单体或分层架构演进到微服务架构后，带来的一个好处就是每个应用的职责更加明确和独立，与此同时，针对应用的开发，团队也更加自制，规模更小，符合“两个披萨原则”。
所以，一个需求拆解出功能，对应到每个应用上，这样可以很好地控制并行的功能点数量，大大降低开发协作的沟通复杂度，即使有合并冲突问题，往往内部沟通一下就可以很快解决。
而实际上，我们设想的这种复杂的 gitflow 场景，在微服务架构下的组织架构中极少存在。
在此，经过对主干开发模式和 gitflow 开发模式这二者的综合对比，结合前面我对分支开发模式的介绍，我们可以看出，分支开发模式简单清晰，在实际操作中更适合我们使用。