Git前端项目分支管理指南

本文介绍git前端项目的线上、开发、修复等分支的管理，作为一种行之有效的方式，为目前的项目和之后的项目分支管理提供参考和指导。

线上分支master

master为线上的分支，受保护，规定有以下特点

1. 代码始终与线上保持一致，当有代码合并进master时，立即发布上线，当代码上线时，立即将上线的代码合并进master

2. master受保护，禁止直接向master分支提交代码

3. master分支为稳定版本，避免将未经测试通过的分支合并进master

4. 当线上出现问题时，从master分支切出一个新的hotfix分支调试定位问题

测试分支

测试分支为专用分支，取名test或者trunk，专门用于测试，开发完成的分支在自测通过后即合并进test分支，具有以下特点

1. 最初由开发分支或者特性分支切出

2. 可合并开发待测试的分支

3. 可合并修复分支

4. 其版本最前，可以出现线上未发布的版本

5. 可以配合持续集成，推送后自动发布测试

6. 专用分支，不能随意删除

开发分支

当有新的需求出现时，根据需求的实现周期预估，基于master分支或者dev分支切出新的分支开发，开发分支具有以下特点

1. 当需求的实现周期在1周内时，基于master分支切出特性分支

2. 当需求的实现周期在1周以上时，根据实际情况切出dev分支用作长期的开发

3. 开发分支的命名应表明开发、关联需求id（或者起始日期）、英文释义

4. 上述情况适用产品主要开发已经完成，已经基本稳定上线的情况

5. 如果是新建的项目，或者处于开发的初始阶段，可以暂时将master分支作为开发分支

6. 开发分支开发完成后合并进测试分支待测

7. 测试通过的分支，在接上线许可后合并进master分支上线

8. 合并进master分支的开发分支可以删除，也可以保留在本地

9. 开发过程中的分支建议推送至远程仓库，便于备份和协作

修复分支

修复分支主要用于解决线上出现的bug。由于测试服务器和生产服务器的环境差异，数据的不一致导致产品上线后仍有极少bug，影响使用。在这种情况下，为了保证线上的产品，应基于线上的分支，即master分支，切出热修复分支进行修复，在修复完成并通过测试合并回master。修复分支应遵循以下的一些实践

1. 一个修复分支原则上只用于修复一个特定的bug

2. 修复分支的修复功能影响范围必须可控，避免影响正常的代码

3. 修复分支本身应该是有效的，确定可修复bug

4. 修复分支编写完成可以后可以合并进master的副本待测试

5. 修复分支测试通过后合并进master上线

补充说明

本文不涉及上线管理和版本号管理。

多人协作时，如何合并主分支和尽量避免冲突。

请填写。