昨天有朋友在公眾號私信問我幾個關于代碼分支管理的問題，這幾個問題是我去年寫的《在團隊中使用GitLab中的Merge Request工作模式》一文結尾時拋出的幾個問題：

• 如果系統上線后有緊急Bug需要處理，這個流程應該怎樣去調整？

• 每個任務都在單獨分支并行開發，這時如果A和B都依賴C開發的一個模塊，應該怎么解決？

• 理論上Issue管理員和開發人員都可以進行創建，什么樣的Issue可以有開發人員來創建？

這幾個問題在《敏捷下的需求和代碼分支管理》一文中其實已經給出了答案，時隔兩個月，管理方式又有了些調整和改進。我覺得還是有必要單獨寫一寫。

總體的流程沒有大的變化，還是使用Tapd來管理需求和缺陷，使用Gitlab來管理代碼的分支，但有幾個小的調整：

• 迭代周期

• 需求文檔

• 分支管理

迭代周期調整

之前是以一周做為一個迭代周期，實踐中發現，以周為單位，粒度還是太大，有時候緊急上線一個功能或是修復Bug，連續幾天都會有發布，甚至一天內還有多次發布。目前迭代遵循著以下幾點：

• 因為功能發布時間的不確定性，需求的安排還是以周為單位來計劃

• 一個完整功能提測通過后，立即發布上線

• 緊急Bug修復完成后，立即發布上線

像這樣調整，產品的迭代會更加敏捷，同時也對整個團隊提出了更高的要求，怎樣在這樣高速迭代的過程中，還保證產品的穩定性？

需求文檔的調整

自從以任務為導向調整成需求為導向時，就已經意識到需求的重要性，同時也面臨一個問題：需求文檔誰來寫？

一些大公司的研發團隊，配置齊全，有專職的需求分析師，而像我們這種小的創業型產品團隊，我希望每個人都能是需求分析師。

在調整為需求導向的開始階段，是我一個人在寫需求的詳細描述，一旦精力分散，就會導致有疏漏，效果不是很好。現在我要求團隊成員每個人都參與寫需求，在接到任務時，必須先思考，把自己到理解寫出來，然后才開始開發。

我會對需求做review，也會讓經驗豐富的程序員來做review，找出遺漏的點和錯誤的點進行補充和改正。

讓每個人都參與需求的編寫有兩個好處：

• 可以改掉程序員不喜歡思考，拿到任務就直接寫代碼的壞習慣

• 程序員有了自己的思考，并且形成了文字的輸出，對需求的理解會更加的深刻，產出的質量會有提高

另外，需求文檔的工具，也從原來直接在Tapd中編寫，調整到了語雀。在這里強烈推薦下語雀，理由如下：

• 編輯器，對開發人員非常友好，真正意義上的所見及所得

• 文中可以直接嵌入Office文檔和視頻（支持本地視頻上傳），在線瀏覽和觀看

• 整個文檔可以導出成PDF，不知不覺的就可以寫一本電子書

分支的調整

之所以要做調整肯定是遇到了問題，所以，先說問題：

需要更小迭代的發布，常常A功能已經在測試中，這時B功能并入主分支進行測試，A功能測試完，B功能還在測試中，這是如果發布，會導致沒有完成測試的B也發布了，而我只想發布A

客戶A使用的是v6.7.5版本，而現在最新的版本已經迭代到了v6.8.0，在v6.7.5上發現的Bug應該怎么辦？

引入release分支

• 創建release分支做為發布分支，該分支設置為只能管理員提交代碼

• 需求開發完成后，會merge到master分支進行測試

• 測試通過的提交，并到release分支，進行再次驗證，驗證通過，發布上線

引入release分支可以雖然在操作步驟上帶來了一些復雜度，但是可以確保能夠以最小粒度發布。

引入Tag

在release分支發布上線后，以發布的版本號為名稱在GitLab中打一個Tag，這樣就可以解決上面的問題2，分為兩種情況：

以v6.7.5的Tag創建分支來修復Bug，修復后直接在該分支進行測試，驗證通過后發布，最新版本如果該Bug已經修復，則直接更新Tag

以v6.7.5的Tag創建分支來修復Bug，修復后直接在該分支進行測試，驗證通過后發布，最新版本如果沒有修復該Bug，將修復Bug的提交合并到主分支，然后更新Tag

同樣，當程序發布到docker容器中后，在容器的私有倉庫中也打上以版本號命名的Tag，可以便于升級后的回滾。

總結

工具和流程都只是輔助手段，目的是為了團隊能夠更好的溝通協助，能夠持續地有高質量的產出，千萬不能本末倒置。

最后，祝大家端午節快樂！

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總?http://www.csharpkit.com?

總結

以上是生活随笔為你收集整理的不断进化的分支和需求管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。