代码管理的规范

目录

分支管理

master

release分支

hotfix分支

feature分支

develop / test分支

版本分支的管理

图1：保持相对稳定的test分支

图2：定期基于最新的master拉取新的test分支

---

为了规范代码仓库主干和分支的管理，使代码分支管理及版本关系清晰，方便维护，避免由于管理混乱导致的错误代码发布等问题。代码分支管理规范因此而生。

分支管理

master

• master主分支，也是持续保持相对稳定的分支。
• 一般在develop分支测试稳定后，才会将稳定的代码合到master。

release分支

• release分支是用来发布上线的专用分支。所有release分支的单独改动都需要合回到master。
• release分支的代码一定是稳定的，但不一定是最新的。
• release分支是不允许做大的未经测试的变更的，只允许小的紧急问题以hotfix的方式缺陷修正。

hotfix分支

• hotfix分支一般规范命名为hotfix-*。
• hotfix分支一般基于release分支拉取，通过紧急修复、回归测试后，再立即合回到release进行发布。
• hotfix分支的改动在合并release到同时，也需要合到master，合到最新的developer分支。

feature分支

• feature分支一般是匹配产品需求或者开发技术的，以开发一项新的功能或一项新的优化为目的，相应也需要以feature-* 或者tech-*的规范命名。
• feature分支一般会从比较稳定的master拉取，但特殊情况下，当多个开发需求有冲突或依赖的时候，也会基于一个不稳定的feature分支，或者是最新的develop分支来拉取新feature分支。
• feature分支的代码，也是未经过测试，极其不稳定的。
• feature分支开发的代码，一旦合到master后就可以被弃掉，后续基本不会再用到。

develop / test分支

• develop分支，一般所有分支中代码是最全的。不仅包含了稳定的master代码，以及所有最新的feature分支的代码，是用来测试的分支。
• develop分支是不稳定的，用于测试的，因此有的公司也会直接命名为test分支。

版本分支的管理

至于怎么保证test分支所包含的代码一定是最全的，一般可以有两种方案：

• 一种保持固定的test分支，并定期同步最新的master到test分支。此时的test分支相当于起到了一个集成测试分支的作用。
• 另一种是定期基于最新的master拉取新的test分支。这里的test分支相当于一个阶段测试分支的作用。

至于哪种方式更好，和不同团队的项目流程和版本迭代节奏有关。

可以看看下方这两个图的比较：

图1：保持相对稳定的test分支

• 优势在于：开发只需要解决一次冲突：从feature分支到test分支。master的代码和release分支都非常稳定，可作为发布分支。
• 缺点在于：同一批集成测试的内容必须要同时稳定下来，才可合并到master并最终完成上线。一旦个别feature未稳定，则会影响到整个分支内容的上线时间。

因此这个分支管理，只适合团队默契度非常高，版本节奏非常固定，并且相对迭代节奏比较慢的团队使用。

图2：定期基于最新的master拉取新的test分支

• 优势在于：测试稳定的项目不用互相等待，随时可以合并到master，并且尽早完成上线
• 缺点在于：开发需要解决至少两次冲突：从feature分支到test分支，再从feature分支到release分支（因为存在test分支一起测试的代码并不会一起上线的可能）。同时因为要解决冲突，master也承担了集成测试分支的作用，因此master的代码只是相对稳定，不会像图1流程一样做到绝对的稳定。

至于各个团队的代码分支管理，都会有适合自己团队的规范。没有最完美的，只有最合适自己项目和团队的，遵守自己团队的代码分支管理规范，才能减少生产问题。