🌈慢慢的公司内部的项目逐渐增多，并且前期项目的版本发布相对来说比较频繁，为了更好的进行团队开发，定义了一套适用于版本发布的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，并勾选最下方两个选项：
等待review通过，通过后点击merge，请再次确认squash和delete branch被勾选：
如果merge request有description，可以点击Modify commit message并点击最下方的include description，然后再点击merge：
7.done(完成)
bugfix 流程
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(完成)。
hotfix 流程
需要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(完成)。
总结
实际上，每个公司的团队协作gitflow可能都不太一样，甚至有些小公司没有这方面的多人协作管理，然而我仅仅总结了以往公司已经借鉴的Git的gitflow规范得出以上内容
3013
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
