概況
當前文檔包涵開發流程規范與上線（OP）流程規范。
通過規范開發流程可以嚴格控制線上分支的代碼質量及穩定性。使用成熟的工作流程模型，可以使團隊協作更加流暢。
通過規范上線（OP）流程，保證線上環境的穩定，明確職責。
涉及人員
- 研發工程師
- 代碼審核員（技術負責人或由技術負責人指定的研發工程師，不可以是開發者本人）
- 產品經理
- 測試工程師（未到崗前，產品經理負責）
多人協作流程與規范
一、工作流
選用GitFlow工作流模式作為協作流程規范。
1、gitflow
Gitflow工作流定義了一個圍繞項目發布的嚴格分支模型。雖然比功能分支工作流復雜幾分，但提供了一個健壯的用於管理大型項目的框架。
Gitflow為不同的分支分配一個很明確的角色，並定義分支之間如何和什么時候進行交互。 除了使用功能分支外在做Bug修復、維護和預發布時也使用各自的分支。同時通過Pull Requests、隔離實驗性開發實現更高效的協作。
2、工作方式
Gitflow工作流仍然用一個遠程倉庫作為所有開發者的交互中心。和其它的工作流一樣，開發者在本地工作並push分支到中央倉庫中。
二、主要分支: Master、Develop
Gitflow工作流使用2個分支來記錄項目的歷史。master分支存儲了正式發布的歷史，而develop分支作為功能的集成分支。 這樣也方便master分支上的所有提交分配一個版本號。
- Master(綠色): 永遠處在 production-ready 狀態
- Develop(橙色): 最新的下次發布開發狀態
三、支援性（臨時）分支:
1、Feature功能分支
每個新功能位於一個自己的分支，這樣可以push到中央倉庫以備份和協作。 但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支。當新功能完成時，合並回develop分支。 新功能提交應該從不直接與master分支交互。
Feature(藍色): 開發新功能都從 develop 分支出來，完成后 merge 回 develop
2、release發布分支
一旦develop分支上有了做一次發布（或者說快到了既定的發布日）的足夠功能，就從develop分支上fork一個發布分支。 新建的分支用於開始發布循環，所以從這個時間點開始之后新的功能不能再加到這個分支上—— 這個分支只應該做Bug修復、文檔生成和其它面向發布任務。 一旦對外發布的工作都完成了，發布分支合並到master分支並分配一個版本號打好Tag。 另外，這些從新建發布分支以來的做的修改要合並回develop分支。
使用一個用於發布准備的專門分支，使得一個團隊可以在完善當前的發布版本的同時，另一個團隊可以繼續開發下個版本的功能。 這也打造定義良好的開發階段（比如，可以很輕松地說，『這周我們要做准備發布版本4.0』，並且在倉庫的目錄結構中可以實際看到）。
常用的分支約定：
用於新建發布分支的分支: develop
用於合並的分支: master
分支命名: release-* 或 release/*
Release(黃色): 准備要 release 的版本，只修 bugs。從 develop 分支出來，完成后 merge 回 master 和 develop
3、hotfix維護分支
維護分支或說是熱修復（hotfix）分支用於生成快速給產品發布版本（production releases）打補丁，這是唯一可以直接從master分支fork出來的分支。 修復完成，修改應該馬上合並回master分支和develop分支（當前的發布分支），master分支應該用新的版本號打好Tag。
為Bug修復使用專門分支，讓團隊可以處理掉問題而不用打斷其它工作或是等待下一個發布循環。 你可以把維護分支想成是一個直接在master分支上處理的臨時發布。
- Hotfix(灰色): 等不及 release 版本就必須馬上修 master 趕上線的情況。會從 master 分支出來，完成后 merge 回 master 和 develop
四、代碼Review
使用pull request進行代碼review
在Gitflow工作流中使用Pull Request讓開發者在發布分支或是維護分支上工作時， 可以有個方便的地方對關於發布分支或是維護分支的問題進行交流。
當一個功能、發布或是熱修復分支需要Review時，開發者簡單發起一個Pull Request， 團隊的其它成員會通過Bitbucket收到通知。
新功能一般合並到develop分支，而發布和熱修復則要同時合並到develop分支和master分支上。 Pull Request可能用做所有合並的正式管理。
OP流程
規范開發協作流程之后，其實OP流程就相對簡單了。
首先規定所有代碼合並到Develop、或Master都經過了測試、review及驗收。
此時OP只需要執行線上部署即可。
一、基本約定
- master 技術負責人 讀寫，開發 只讀
- develop 技術負責人 讀寫，開發 只讀
- release/hotfix/hotfix 等需要合並到 master的分支需要由技術負責人創建
- 其它臨時分支，ALL 讀寫
二、一般開發任務的OP流程
三、緊急任務的OP流程
職責分工
一、產品經理
- 參與技術方案確認
- 預上線測試
- 線上回歸及后續跟進
二、研發工程師
- 代碼開發、bug修復（必須自測完成才能提交）
- 配合預上線測試
1、一般開發
（1）、更新版本庫
git pull origin master:master
git pull origin develop:develop
（2）、創建功能分支
git checkout develop
git checkout -b feature/<功能名稱>
（3）、開發和測試
（4）、提交功能分支
git push origin feature/<功能名稱>
（5）、通過gitlab申請review (合並目標develop)
（6）、解決沖突
git checkout develop
git pull origin develop:develop
git merge feature/<功能名稱>
（7）、提交合並結果
git push origin develop: feature/<功能名稱>
（8）、檢查通過
git branch -D feature/<功能名稱>
2、緊急修復
（1）、獲取修復用分支
git checkout master
git pull origin master:master
git checkout -b hotfix/<編號>
（2）、開發和測試
（3）、提交功能分支
git push origin hotfix/<編號>
（4）、通過gitlab申請review (合並目標master)
（5）、解決沖突
git checkout master
git pull origin master:master
git merge hotfix/<編號>
（6）、提交合並結果
git push origin master:hotfix/<編號>
（7）、檢查通過
git branch -D hotfix/<編號>
3、預上線集成
（1）、獲取集成分支
git fetch origin release/<編號>: release /<編號>
git checkout release /<編號>
（2）、測試、微調 （嚴禁引入新功能和大的修改，針對某一個bug或功能超過50行的修改即認為大型修改，本次上線終止）
（3）、提交功能分支
git push origin release /<編號>
（4）、通過gitlab申請review (合並目標master)
（5）、解決沖突
git checkout master
git pull origin master:master
git merge release /<編號>
（6）、提交合並結果
git push origin master: release /<編號>
（7）、檢查通過
git branch -D release /<編號>
4、代碼審核員
代碼review，結果合並
5、技術負責人
任務分配
臨時分支創建工作：release\hotfix\hotfix
代碼review，結果合並（結果需要同時合並到master、develop）
6、OP
按郵件說明，將master指定版本上線
示例
下面的示例演示本工作流如何用於管理單個發布循環。假設你已經創建了一個中央倉庫。
一、創建開發分支
第一步為master分支配套一個develop分支。簡單來做可以本地創建一個空的develop分支，push到服務器上：
git branch develop
git push -u origin develop
以后這個分支將會包含了項目的全部歷史，而master分支將只包含了部分歷史。其它開發者這時應該克隆中央倉庫，建好develop分支的跟蹤分支：
git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop
現在每個開發都有了這些歷史分支的本地拷貝。
二、程序員A和程序員B開始開發新功能
這個示例中，程序員A和程序員B開始各自的功能開發。他們需要為各自的功能創建相應的分支。新分支不是基於master分支，而是應該基於develop分支：
git checkout -b some-feature develop
他們用老套路添加提交到各自功能分支上：編輯、暫存、提交：
git status git add <some-file> git commit
三、程序員A完成功能開發
添加了提交后，程序員A覺得她的功能OK了。如果團隊使用Pull Requests，這時候可以發起一個用於合並到develop分支。 否則她可以直接合並到她本地的develop分支后push到中央倉庫：
git pull origin develop git checkout develop git merge some-feature git push git branch -d some-feature
第一條命令在合並功能前確保develop分支是最新的。注意，功能決不應該直接合並到master分支。 沖突解決方法和集中式工作流一樣。
四、程序員A開始准備發布
這個時候程序員B正在實現他的功能，程序員A開始准備她的第一個項目正式發布。 像功能開發一樣，她用一個新的分支來做發布准備。這一步也確定了發布的版本號：
git checkout -b release-0.1 develop
這個分支是清理發布、執行所有測試、更新文檔和其它為下個發布做准備操作的地方，像是一個專門用於改善發布的功能分支。
只要程序員A創建這個分支並push到中央倉庫，這個發布就是功能凍結的。任何不在develop分支中的新功能都推到下個發布循環中。
五、程序員A完成發布
一旦准備好了對外發布，程序員A合並修改到master分支和develop分支上，刪除發布分支。合並回develop分支很重要，因為在發布分支中已經提交的更新需要在后面的新功能中也要是可用的。 另外，如果程序員A的團隊要求Code Review，這是一個發起Pull Request的理想時機。
git checkout master git merge release-0.1 git push git checkout develop git merge release-0.1 git push git branch -d release-0.1
發布分支是作為功能開發（develop分支）和對外發布（master分支）間的緩沖。只要有合並到master分支，就應該打好Tag以方便跟蹤。
git tag -a 0.1 -m "Initial public release" master git push --tags
Git有提供各種勾子（hook），即倉庫有事件發生時觸發執行的腳本。 可以配置一個勾子，在你push中央倉庫的master分支時，自動構建好對外發布。
六、最終用戶發現bug
對外發布后，程序員A回去和程序員B一起做下個發布的新功能開發，直到有最終用戶開了一個Ticket抱怨當前版本的一個Bug。 為了處理Bug，程序員A（或程序員B）從master分支上拉出了一個維護分支，提交修改以解決問題，然后直接合並回master分支：
git checkout -b issue-#001 master # Fix the bug git checkout master git merge issue-#001 git push
就像發布分支，維護分支中新加這些重要修改需要包含到develop分支中，所以程序員A要執行一個合並操作。然后就可以安全地刪除這個分支了：
git checkout develop git merge issue-#001 git push git branch -d issue-#001
到了這里，但願你對集中式工作流、功能分支工作流和Gitflow工作流已經感覺很舒適了。 你應該也牢固的掌握了本地倉庫的潛能，push/pull模式和Git健壯的分支和合並模型。
記住，這里演示的工作流只是可能用法的例子，而不是在實際工作中使用Git不可違逆的條例。 所以不要畏懼按自己需要對工作流的用法做取舍。不變的目標就是讓Git為你所用。