從2011.10月左右，開始在后台組推行git版本控制，到現在也差不多半年了，也形成了一套基於git flow的副官模式工作流程：
版本定義：
版本號使用x.x.x進行定義，第一個x代表大版本只有在項目有重大變更時更新
第二個x代表常規版本有新需求會更新
第三個x代表緊急BUG修正
一個常見的版本號類似於：0.11.10
分支定義：
- master分支對應線上版本，上線都使用master；
- develop是開發分支，用於生成提測分支release，始終保持最新；
- hotfix是緊急分支，從master生成，bug修正后自動合並到master和develop並且生成tag；
- feature是私有分支，用於開發新需求和需要較長時間的BUG修改
- release是提測分支也即常規分支，測試並且bug修改結束后生成該版本tag，后續可以使用git show tagname來查看版本信息或者回滾
工程師： clone版本庫后，首先git flow init初始化工作目錄。
開發工作流程：
- git flow feature start xxxxx（開始新需求）
- 在feature/xxxxx分支下進行開發
- git flow feature finish xxxxx（開發完成后等待研發經理確認可以完成時執行）
- git push origin develop（發布develop分支）
- 每天工程師都需要git pull origin develop來更新develop分支，然后將develop分支合並到你正在開發得feature/xxxxx分支上來保持代碼最新
- 切記不能直接在develop上進行開發
常規分支debug流程：
- 由研發經理通知相關工程師release版本x.x
- git fetch
- git checkout -b release/x.x origin/release/x.x（拉回release版本）
- git pull release/x.x（更新該分支）
- 修改測試中發現的BUG
- git push origin release/vx.x（修改完后提交分支）
- 循環4-5
緊急debug流程：
- 由研發經理通知相關工程師hotfix分支名稱x.x.x
- git fetch
- git checkout -b hotfix/x.x.x origin/hotfix/x.x.x（拉回hotfix分支）
- git pull hfx.x（更新hotfix分支）
- 在熱修復分支下修改bug
- git push origin hfx.x（修改完成，提交分支）
在日常工作中不能修改master分支下得代碼
研發經理：
開發和DEBUG流程同工程師流程
常規分支debug流程：
- git pull origin develop（更新develop分支為最新）
- git checkout develop（切換到develop分支）
- git flow release start x.x（生成一個release分支）
- 通知測試和相關得工程師分支名稱
- git pull origin release/x.x（最終測試完成后拉回分支最新代碼）
- git flow release finish x.x（最終修改和測試完成后，結束release版本以供發布）
- git push origin develo (發布最新的develop)
- git push origin master（發布最終得master分支）
緊急debug流程：
- git pull origin master（更新master分支為最新）
- git checkout master（切換到master分支）
- git flow hotfix start x.x.x（生成一個hotfix分支）
- 通知相關得工程師和測試人員hotfix分支名稱
- git pull origin hotfix/x.x.x（最終測試完成后拉回分支最新代碼）
- git flow hot fix finish x.x.x（最終修改和測試完成后，結束hot fix以供發布）
- git push origin master（發布最終得master分支）
在全部的流程中，工程師必須維護自己的feature分支保證代碼最新，減少合並時的沖突。
研發經理必須維護release分支，將最新的hotfix都合並進去，保證代碼最新，減少合並時的沖突。
在提交代碼時還要注意判斷對代碼的修改是否是自己的，多用diff工具，多查看log，防止代碼回溯
轉載自: http://zeroq.me/p/451 作者: zeroq