git分支规范对比

现在普遍流行的git规范是GitFlow，但是最近又看到一个新的Git规范，感觉这个新的规范，设计更加合理，并且可以解决GitFlow在项目运用中存在的问题，本文罗列了这两种规范的主要内容，并做了对比。

Git并行规范

分支流转规范

• 发布分支：该分支从 预发布分支 合并而来；如果没有 预发布分支，则从 测试分支 合并而来；在将分支（如：预发布分支 或 测试分支）合并到发布分支前，需要确保 该分支 已经包含了发布分支上的所有版本；如果没有包含发布分支上的所有版本，则取消本次的分支流转，并重新转测 或 从 原始分支 重新发起流转；

• 预发布分支：该分支从 测试分支 合并而来；如果不需要，也可以不设 预发布 分支；

• 测试分支：该分支从 被转测的分支 合并而来；如：功能、修复、协作、合并；在转测前，需要确保 被转测的分支 已经包含了发布分支上的所有版本；即：如果被转测的分支在转测前，发布分支上有新的版本发布，且这些新的版本并没有包含在 被转测的分支上，则需要先把发布分支上那些新的版本合并到被转测分支，然后才能转测，即：将被转测分支合并到测试分支上；

• 合并分支：该分支是对 需要合并的多个分支 进行合并而来的分支；

• 功能分支：基于 发布 分支创建；

• 修复分支：在没有不需要与被修复的问题一起转测的代码的情况下，应该在 问题所在的 流转链 中的 原始分支 上直接修复问题，不必创建单独的修复分支（这是为了保证原始分支的完整性）；如果 问题 所在的 流转链 中的 原始分支 不存在 或者 原始分支 中包含了不能与被修复的问题一起转测的代码，则应该 基于 问题所在的 流转链 中的 终点分支 创建 修复分支，然后在该 修复分支 上修修复问题（这是为了保证 多个任务或多个功能 之间 互不干扰）；当问题被修复完问题后，再将该 修复分支 合并到 其对应的专门用于测试该修复问题的测试分支中，不应该把 修复分支 合并到 该修复分支的 母分支 或者 母分支 对应的 测试分支 中；即：每个修复分支 都有其对应的、专门的测试分支 （这是为了保证 测试分支 和 对应的 被转测分支 的代码的一致性，多个任务 或 多个功能之间 独立、互不干扰）；
  比如：
  如果，被修复的问题是由 功能A 导致的，且 功能A分支 上不包含不能与被修复的问题一起转测的代码，则应该直接在 功能A分支 中修复问题，不用创建专门的 修复分支；
  如果 功能A 分支 已经被删除了 或者 包含不能和 被修复的问题 一块转测的代码，则应该基于 被修复问题所在的 流转链 的 终点分支 创建 专门用于修复该问题的 修复分支；问题被修复完后，再将该修复分支 合并到 专门用于测试该问题的 测试分支 中；

• 临时分支：被合并到发布分支（即正式发布之后）才可以被删除；建义正式发布运行一段时间之后再删除；如果不必要，也不建义永久留着，以便仓库保持整洁；

• 每个 预发布分支 都有其唯一对应的 测试分支，每个 测试分支 都有其唯一对应的 被转测分支；即：每个 被转测分支 都有其 单独对应的 测试分支，每个 测试分支 都有其 单独对应的 预发布分支；（这是为了保证对应的 预发布分支、测试分支、被转测分支 的代码的一致性，多个任务 或 多个功能之间 独立、互不干扰）。

示例图如下：

Git并行规范流转图

GitFlow规范

git常用分支

• Production 分支 ： 也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改。

• Develop 分支：这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支。

• Feature 分支：这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release。

• Release 分支：当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支。

• Hotfix 分支：当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release。

示例图如下：

GitFlow规范流程图

对比

GitFlow的问题：

1. 需要同时维护两个分支，会存在代码不同步的可能性
   (master,develop);
   假如已经上线的项目发现了bug，需要及时修复，GitFlow的规范是在Hotfix分支进行修改，修改以后，要分别合并到master和develop分支，这样才能保证master和develop的代码同步，因为这两个分支都是长期维护的分支。如果我们哪一次忘记了同步，项目可能会出现问题。

2. 其他功能的开发，包含其他未开发完成的功能的代码；
   假如多个功能在不同的时间，并行进行开发，后面功能分支会包含之前功能分支的代码，因为他们都是基于develop分支创建的，如果之前的功能存在bug，这个可能会影响后面功能的开发。

3. 上线的功能，可能包含未上线功能的代码；
   这个问题也是由于第2个问题导致的，多个功能并行开发，如果前面的部分功能临时决定暂不上线，先上线后面开发的功能，那上线的功能会包含前面暂时不上线的功能的代码。

而Git并行规范不存在这样的问题。因为它只有一个长期的产品分支，一个新的功能，都是基于这个产品分支而创建的，每一个功能在没有测试完成之前是不会合并到产品分支的，这样不管你有多少并行的开发分支，都是互不影响的。

相关文章

• GitFlow规范
• Git并行规范