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

🌈慢慢的公司内部的项目逐渐增多，并且前期项目的版本发布相对来说比较频繁，为了更好的进行团队开发，定义了一套适用于版本发布的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

协作流程

开发流程

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

1. 等待review通过，通过后点击merge，请再次确认squash和delete branch被勾选：

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

7.done(完成)

bugfix 流程

develop上的bugfix

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

release/xxx上的bugfix

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

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

hotfix 流程

需要merge到develop

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

仅需要merge到master

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

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

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

需要merge到LTS release branch

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

发版流程

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

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

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

总结

实际上，每个公司的团队协作gitflow可能都不太一样，甚至有些小公司没有这方面的多人协作管理，然而我仅仅总结了以往公司已经借鉴的Git的gitflow规范得出以上内容，文章全部介绍就到这里了，如果文章对你有所帮助，欢迎 点赞👍+评论💬+收藏❤，我是：👨‍austin流川枫，我们下期见!