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 啦
版权归原作者 小陆_39194983 所有, 如有侵权,请联系我们删除。