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

名词解释

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

分支规范

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

协作流程

开发流程

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

5. 等待 review 通过，通过后点击 merge ，请再次确认 squash 和 delete branch 被勾选：
6. 如果 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 descriptio n，然后再点击 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规范得出以上内容