多團隊基於git代碼管理協做流程

多團隊git協同開發流程
1、版本管理的挑戰
雖然有這麼優秀的版本管理工具，可是咱們面對版本管理的時候，依然有很是大得挑戰，咱們都知道你們工做在同一個倉庫上，那麼彼此的代碼協做必然帶來不少問題和挑戰，以下：

1. 如何開始一個Feature的開發，而不影響別的Feature？
2. 因爲很容易建立新分支，分支多瞭如何管理，時間久了，如何知道每一個分支是幹什麼的？
3. 哪些分支已經合併回了主幹？
4. 如何進行Release的管理？開始一個Release的時候如何凍結Feature, 如何在Prepare Release的時候，開發人員能夠繼續開發新的功能？
5. 線上代碼出Bug了，如何快速修復？並且修復的代碼要包含到開發人員的分支以及下一個Release?

2、基於Git Flow擴展的多開發團隊分支協同

經常使用的分支：
• Production 分支
也就是咱們常常使用的Master分支，這個分支最近發佈到生產環境的代碼，最近發佈的Release， 這個分支只能從其餘分支合併，不能在這個分支直接修改
• Develop 分支
這個分支是咱們是咱們的主開發分支，包含全部要發佈到下一個Release的代碼，這個主要合併與其餘分支，好比Feature分支
• Test 分支
這個分支主要是用來對應每一個測試環境打包，構建鏡像
• Personal分支
開發人員基於主開發分支建立的本身提交代碼的分支
3、分支管理
• 初始化分支、拉取Develop主分支
全部在Master分支上的Commit應該Tag

項目立項時，申請開通對應版本的開發主分支，命名規則：vx.xx.xxx
• 開發階段
全部參與版本開發人員從主開發分支拉取本身的personal開發分支，命名規則：v.x.xx.xxx-開發人員姓名小寫全拼，（通常版本迭代開發完成，該分支能夠刪除銷燬，避免代碼庫中分支過多）

• 測試階段
一、開發人員完成功能開發並自測完成能夠申請合併到測![Uploading file...]()試分支，部署到測試環境

二、測試人員在測試環境上，覆蓋測試用例，發現bug並提交給開發人員進行bug修復
三、開發人員完成bug修復，並將代碼合併到測試分支，部署到測試環境進行迴歸測試
• 產品驗收階段

4、多團隊協做開發

嚴格按照版本迭代的前後順序進行代碼更新合併操做，原則上儘可能減小衝突。
5、線上bug緊急修復

線上緊急bug修復，直接從主幹分支上拉取最新版本代碼，命名規則：bug-yyyymmdd-問題描述
6、完成版協做流程圖

本文由博客一文多發平臺 OpenWrite 發佈！