>[info] git工作流的好處，為什么要用它 GIT工作流是團隊協作積累的代碼治理經驗。在敏捷開發中，選擇合理的、靈活的、可靠的代碼管理方式，可優化產研各階段的在制品數量限制并<span style="color:red;"><b>提高協作效率，保障生產安全。</b></span> ***** 每個團隊都會有一套自己代碼管理流程，隨著業務發展和項目規模變化，管理流程也需要不斷適應改變。就像敏捷一樣，是方法論而非生搬硬套。 ***** 1. 項目管理 **模塊分工：** 前端模塊分工可通過一個codebase多個文件夾，采用集中式工作流在一個主分支上協作開發。對于規模復雜度較高 的項目，涉及跨工種且模塊化開發，可通過git子項目關聯，或者類似lerna分包分版本管理。 **代碼 Review：** 促成了PR工作流，代碼庫的生產代碼統一管控，即可做到技術層面的代碼審查。借助于gitlab的issue管理、代碼批 注功能，可以使版本代碼可溯源，可沉淀知識庫。 ***** 2. 版本控制 **集成版本樹：** 版本控制需要從需求版本到部署應用版本建立統一的版本樹。項目復雜度越高，不確定和不可控是需求推進的阻礙。 建立集成版本樹即可輔助團隊協作亦可推動各模塊自檢梳理應用 **生產安全控制：** 有了版本控制，不是一定杜絕了生產隱患。而是通過版本去鎖定事故范圍，快速定位問題 ***** **SVN 工作流：**  ***** >[info] git有哪些主流的工作流，及其分析 1. 集中式工作流 類似于集中式版本控制，以中央倉庫作為項目所有修改的單點實體，在git中我們使用master分支作為主干分支，所 有修改都提交到master上，在集中式工作流中我們只使用master。  **注意事項：** 設定分支保護，防止沖突者強制覆蓋 ***** 2. 功能分支工作流 功能分支工作流是為了解決開發過程中功能模塊協作問題，不在master分支上做開發，每個功能模塊基于一個專門 的分支。功能開發促成了Pull Request 工作流，每個PR讓技術負責人review代碼，檢查無誤后merge到master分支上。 ***** **原理：** 新增了很多功能分支，某個功能分支的功能開發完成后，可以合并到master然后發布上線，也可以先合并到test測試分支，然后再合并到master分支，再發布上線。  **使用攻略：** 拉取遠程倉庫，基于master創建新分支feature并同步到遠程，規定該功能分支是最小需求單元的協作分支，提測過 程是將該分支Merge request到測試分支，發布線上也是將該分支合并至master。 ***** 3. Git flow工作流（重點） Git flow工作流是圍繞項目發布的嚴格分支模型，用于管理大型項目，嚴格規范發布流程。 遠程倉庫作為開發者的交互中心，同時圍繞master、release、develop、feature（feature是統稱不止這一個）四種 分支協作，完成多環境、多任務的代碼管理。  ***** **使用攻略：** feature功能分支是基于develop進行創建，在功能分支上進行一個周期的功能開發，多個功能并行開發就需要建立多 個feature-XXXX分支。 如果一個功能預備上線，需要先合并到develop分支上，并同時在此時develop上基礎上建立一個release-XXXX分支 在此release分支上進行發布任務開發，比如bug修復，更新文檔等，投產日合并release分支代碼到master和 develop，并且在master上對這次merge記錄版本號，并打上tag。 ***** **總結：** 此工作流適合2C產品或者對發布產品進行嚴格控制的項目以及大型項目處理多需求并行開發，release分支進 行預投產測試，develop進行開發測試。 ***** 4. Github工作流 pull request 基于GitHub倉庫開發，開源項目嚴格管理PR。  >[info] Git flow工作流實操 見git文檔（二）