基于gitlab适用于版本发布的git-flow团队开发协作规范

作者：austin流川枫链接：https://juejin.cn/post/7199192593279991867。

程序一逸 · 2023-02-14 11:03:21 发布

🌈慢慢的公司内部的项目逐渐增多，并且前期项目的版本发布相对来说比较频繁，为了更好的进行团队开发，定义了一套适用于版本发布的git-flow协作规范，我大概整理了一下，大家可以借鉴一下。

LTS版本：Long Term Support长期支持版本，简称LTS。
MR/PR：是Merge Request/Pull Request，我们常说的提PR的意思是开发人员在某个分支功能开发完了，需要发送一个请求，请求将某个源分支代码合并到目标分支，这个过程为了让项目组长/负责人进行code review（代码审查），check没有问题之后允许合并。

一共拥有以下几个（种）branch：

分支	描述
master	master上的都是`production-ready`的`stable`的代码
develop	作为开发的主分支，所有的`merge`操作都应该先合并到`develop`分支，再定期`merge`到`master` 发版
release-xxx	LTS版本需要有独立的`branch`，以作为后续（万一）`hotfix`使用，精确到`minor version`，如`release-v1.2`，为长期保留的分支。
feature/xxx	所有新的`feature`（如新功能、性能优化）都应当先`checkout`到一个新的`feature`分支开发，原则上必须且只能`merge`到`develop`分支
bugfix/xxx	`bug`的修复分支，原则上必须且只能`merge`到`develop`分支
test/xxx	`test`分支主要做以下三件事：1. 增加`unit test`；2. 修改仓库级别配置文件（如`.gitlab-ci.yml`）；3. 用来承载一些一次性的测试（最好不合并入develop）
hotfix/xxx	用来发布`hotfix`的分支，大多是用于承载线上比较紧急的`bug`修复
release/xxx	用来做发版工作（如更新版本号，`bugfix`）的分支，还有一个作用是`freeze feature`, 不允许合入`feature`，只允许合入`bugfix`

首先，确认自己在develop分支上，基于开发分支切一个功能分支出来；
git checkout -b feature/your_feature；
开发完成后，push到origin；
提pr（如果是性能优化，请在description中附带上benchcmp的结果），target branch为develop，并勾选最下方两个选项：

如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge：

7.done(完成)

develop上的bugfix

首先，确认自己在develop分支上；
git checkout -b bugfix/your_bugfix；
开发完成后，push到origin；
提mr，target branch为develop，并如开发流程一样勾选最下方两个选项；
等待review通过，通过后点击merge，请再次确认squash和delete branch被勾选；
如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge；
done(完成)。

release/xxx上的bugfix

这里不需要直接merge回develop是因为release/xxx最终会merge回develop。

首先，确认自己在release/vX.Y.Z分支上；
git checkout -b bugfix/your_bugfix；
开发完成后，push到origin；
提mr，target branch为release/vX.Y.Z，并如开发流程一样勾选最下方两个选项；
等待review通过，通过后点击merge，请再次确认squash和delete branch被勾选；
如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge；
done(完成)。

需要merge到develop

按照 普通bugfix流程 完成bug修复，记得要更新代码中的版本号（为了防止merge到master后忘记 merge回develop）；
切换到master分支上；
git checkout -b hotfix/your_hotfix；
cherry-pick bugfix的commit；
检查无误后，push到origin；
提mr，target branch为master，并如开发流程一样勾选最下方两个选项；
等待review通过，通过后点击merge，请再次确认squash和delete branch被勾选；
如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge；
切换到master分支上，打一个新的tag；
done(完成)。

仅需要merge到master

适用于需要修复的bug在develop分支上已不存在的情况。

版本号的更新不需要同步到develop，在下次merge的时候解决冲突即可。

首先，确认自己在master分支上；
git checkout -b hotfix/your_hotfix；
修复完成后，新增一个独立的commit，更新代码中的版本号，push到origin；
提mr，target branch为master，并如开发流程一样勾选最下方两个选项；
等待review通过，通过后点击 merge，请再次确认squash和delete branch被勾选；
如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge；
切换到master分支上，打一个新的tag；
将第三步中更新版本号的独立的commit cherry-pick到develop分支上；
done(完成)。

需要merge到LTS release branch

根据情况，完成需要merge到develop或者仅需要merge到master中的一个；
切换到release-vX.Y.Z分支上（待修复的分支）；
git checkout -b hotfix/your_hotfix；
cherry-pick hotfix的commit；
更新代码中版本号，检查无误后，push到origin；
提mr，target branch为release-vX.Y，并如开发流程一样勾选最下方两个选项；
等待review通过，通过后点击merge，请再次确认squash和delete branch被勾选；
如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge；
切换到release-vX.Y.Z分支上，打一个tag；
done(完成)。

发版流程比较特殊，和其它流程有较大区别，请注意细节。

这么做的原因是，如果先把release branch merge到develop分支上，再将develop分支merge进master 的话，可能会带上预料之外的commit（在整理release的时候有新的mr被merge到develop）。

首先，确认自己在develop分支上；
git checkout -b release/vX.Y.Z；
做一些发版需要的工作（如更新版本号等）；
完成后，push到origin；
提mr，target branch为master，不勾选 suqash 和 remove source branch；
等待review通过，通过后点击merge，请再次确认 squash 和 delete branch 未被勾选；
如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge；
切换到master，打一个vX.Y.Z的tag。
再提一个mr，target branch为develop，不勾选 suqash 和 remove source branch；
等待review通过，通过后点击 merge，请再次确认 squash 和 delete branch 未被勾选；
如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge；
done(完成)。