Git分支管理及命名规范

1、分支类型及命名

1.1、master分支

master分支一般在创建远程仓库时，Git初始化后自动创建的，该分支的代码应该是稳定的，可随时部署到生产环境的

• master 分支一般不能直接修改，只能由 其它分支 合并而来
• master 分支的合并操作应该让管理员操作，并且管理员需要 review将要合并的代码之后才能合并，避免随意合并不稳定的代码到master分支

1.2、develop分支

develop为开发分支, 始终保持最新开发完成以及bug修复后的代码，该分支的代码一般作为测试环境部署的代码，也是随时可以部署的代码。

• 该分支的代码是master合并代码的主要来源之一，所以一般开发新功能时也会基于该分支创建新分支进行开发

1.3、feature分支

该分支主要用于开发新特性或功能的

• 命名规则：feature/[新特性或功能简短描述]
• 该分支一般由 develop 分支中创建而来，并最终合并回去 develop 分支

1.4、fix分支

修复分支，主要用于修复已知的bug

• 命名规则：fix/[bug的简短描述]

1.5、hotfix分支

该分支用于修复生产环境中出现的紧急bug

• 该分支一般从 master 分支或 release 创建而来，然后在修复后合并回 master 分支和 release 分支，并且还要合并到 develop 分支，以保证 develop 分支依然保存当前最新开发成果的代码
• 命名规则：hotfix/[bug的简短描述]

1.6、release分支

该分支用于准备代码发布，例如进行代码打包，版本更新等

• 命名规则：release/[该版本的版本号]

2、分支操作注意事项

多人同时开发一个项目时，经常会遇到代码冲突的问题，此时，就需要正确的操作流程才能保证我们的解决冲突的过程中，不至于影响其他人的代码。具体的操作流程如下：

• 新建分支之前，必须要先 pull 最新代码，防止本地仓库代码比远程仓库代码旧
• commit 之前一定要先 add 到暂存区，防止代码提交遗漏
• push 之前一定要先 pull 当前分支的最新代码，防止其他人跟自己使用同一分支时无法正确提交代码
• 操作分支合并之前，一定要先切换目标分支并 pull 最新代码之后再进行合并
• 合并分支时如果有冲突，一定要在本地仓库解决完冲突之后才能进行提交
• 之前的一系列操作完成之后，就可以愉快的 push 啦