敏捷过程实践-git代码分支管理规范

2018-01-28 11:40:17   645  举报





在敏捷过程实践中，Git代码分支管理规范至关重要。首先，主分支（如master或main）用于存放稳定的、经过测试的代码。开发人员应在自己的分支上进行工作，避免直接修改主分支。其次，功能分支（如feature-*）用于开发新功能，每个功能应有一个单独的分支。当功能开发完成后，将其合并到主分支。此外，还有修复分支（如bugfix-*），用于修复主分支中的bug。修复完成后，同样需要将其合并回主分支。最后，发布分支（如release-*）用于准备发布新版本。在发布之前，将主分支上的代码合并到发布分支，然后进行最后的测试和部署。总之，遵循这些规范可以确保代码的稳定性和可维护性，提高团队协作效率。

git 代码分支管理

git

敏捷

迭代

代码管理

作者其他创作

大纲/内容

发布5.1.38版本合并稳定代码到master分支同步到dev分支

远端分支remote repository

release分支：迭代版本发布和发布过程bug修改

bug修复

主分支 master

dev

迭代38开始

合并代码

迭代40开始

完成发版

迭代39开始

发版测试

Tag5.1.38

发布分支 release

合并代码

迭代39发布完成

master

稳定版本

修复bug分支hotfix

本地分支local repository

迭代开发完成

开发中...

开始迭代39发布

主开发分支dev

开发版本

git checkout -b hotfix origin/hotfix //创建hotfix分支git branch --set-upstream-to origin/hotfix //关联到远端hotfix分支

代码管理后台：GitLab*主分支：master，稳定版本代码分支，对外可以随时编译发布的分支，不允许直接Push代码，只能请求合并（pull request），且只接受hotfix、release分支的代码合并。gitlab上做限制。*热修复分支：hotfix，针对现场紧急问题、bug修复的代码分支，修复完后合并到主分支、开发分支。*发版分支：release，版本发布分支，用于迭代版本发布。迭代完成后，合并dev代码到release，在release分支上编译发布版本，以及修改bug（定时同步bug修改到dev分支）。测试完成后此版本可以作为发版使用，然后把稳定的代码push到master分支，并打上版本标签。*开发分支：dev，开发版本分支，针对迭代任务开发的分支，日常开发原则上都在此分支上面，迭代完成后合并到release分支。*其他开发分支：dev-***，开发人员可以针对模块自己创建本地分支，开发完成后合并到dev开发分支，然后删除本地分支。

主开发分支 dev

紧急bug

Tag5.1.37.1

迭代39结束

新的迭代开发

release

修复bug分支 hotfix

开始版本5.1.38发版（合并代码，编译测试版本）之后这个分支演进，只能是修复该版本的问题定期同步到dev分支

hotfix

生产环境BUG修复，分别合并到开发分支和主分支

参考资料：Git Flow—Git团队协作最佳实践： https://yq.aliyun.com/articles/68655Git工作流指南： https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md廖雪峰的 Git教程：https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000

本地与远端分支配置：

主分支master

master分支禁止提交代码，只能在gitlab申请合并

功能开发分支feature

开发人员可以基于安排的开发功能建立功能开发分支

迭代任务开发

Tag5.1.39

bug修复完成

pull代码

注意featrue分支是本地分支，不可push到服务端

最终功能分支需要合并到开发分支并删除

代码合并