基于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被勾選：
2. 如果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規範得出以上内容