git工作流程的分类和对应场景

一、版本发布 git flow

参考: www.ruanyifeng.com/blog/2012/0...

Git flow的优点:是清晰可控。

缺点1:是相对复杂,需要同时维护两个长期分支。大多数工具都将master当作默认分支,可是开发是在develop分支进行的,这导致经常要切换分支,非常烦人。

缺点2:更大问题在于,这个模式是基于"版本发布"的,目标是一段时间以后产出一个新版本。但是,很多网站项目是"持续发布",代码一有变动,就部署一次。这时,master分支和develop分支的差别不大,没必要维护两个长期分支。

二、持续迭代(以github为代表)

功能分支合并进 master 分支,必须通过Pull Request(Gitlab里面叫做 Merge Request

Github flow 的最大优点:就是简单,对于"持续发布"的产品,可以说是最合适的流程。

缺点:在于它的假设,master分支的更新与产品的发布是一致的。也就是说,master分支的最新代码,默认就是当前的线上代码。经常,master一个主分支就不够用了,你不得不在master分支以外,另外新建一个production分支跟踪线上版本。

三、版本发布和持续迭代的结合 (gitlab为代表)

(1)持续迭代

对于"持续发布"的项目,它建议在master分支以外,再建立不同的环境分支。比如,"开发环境"的分支是master,"预发环境"的分支是pre-production,"生产环境"的分支是production

(2)版本迭代

对于"版本发布"的项目,建议的做法是每一个稳定版本,都要从master分支拉出一个分支,比如2-3-stable2-4-stable等等。

以后,只有修补bug,才允许将代码合并到这些分支,并且此时要更新小版本号。

四、多版本的版本发布, multi git flow

(1) main用于版本发布。

Main上代码永远是测试完毕的,并且需要打相应的tag,比如2.0.0-20250101 (版本号 + 日期)

(2)version分支,相当于develop分支。

根据产品文档需求,比如2.0.4,就产生version2.0.4分支,这个分支是基于当前master的tag 2.0.3最新版本的。

测试过程中:使用持续合并到某个version分支。

(3)个人本地开发分支

基于version分支,新建个人本地的分支。

合并到version分支时候,需要提交 merge request ,指定相应的负责人 code review 每个commit和文件。

备注:

另外,跟开发分支有冲突并且只能手动解决的时候,gitlab会拦截,提交不了merge request, 可以在网页端解决,更建议在vscode端解决。

(4)bugfix分支

基于master,新建一个bugfix分支,修复验证后,合并入master。并且打上最新日期的tag,比如比如2.0.0-20250207 (版本号 + 日期)

五、协作机制

(1)使用机器人提醒merge request,除文案修改外,其他都需要pull request或者说merge request。

(2)安排任务时候,记得预留 codereview时间, 尤其是项目带头人。

形式1:可以结对codereview。

形式2: 项目带头人codereview 小组成员的代码,项目带头人自己的代码安排给有时间的小组成员的代码

相关推荐
&Sinnt&10 小时前
Git 版本控制完全指南:从入门到精通
git·后端
Tiny21413 小时前
多人协同开发时Git使用命令
git
WebGirl14 小时前
代码Revert后再次Merge会丢失的问题
git
小皮侠18 小时前
nginx的使用
java·运维·服务器·前端·git·nginx·github
HalukiSan20 小时前
如何提交PR
git·gitlab·github
爱莉希雅&&&1 天前
shell编程之awk命令详解
linux·服务器·git
baiyu331 天前
成为git砖家(12): 看懂git合并分支时冲突提示符
git
wu_aceo1 天前
将本地项目提交到Gitee
git·gitee·提交·本地提交·上传git
随便取个六字2 天前
GIT操作 学习
git·学习
星源~2 天前
tree 命令集成到 Git Bash:可视化目录结构的指南
git·单片机·物联网·嵌入式·项目开发