前段時間，我們部門由於工作流不規範導致了一系列問題，低效、線上事故、專案延期、**質量低等問題。老大決定規範一下流程，我也參與其中。
隨著工作經驗的增加，其實你會發現並沒有完美的git工作流，只有完美的團隊配合。
沒必要死板的刻意的在團隊內執行某一種功能大而全的工作流。
工作流應該在工作中慢慢演化出來的，應該根據公司的基礎設施、各部門配合方式、開發人員水平、專案組需求數等因素，選擇乙個成本和效益平衡的最優解。
develop => feature-1 從develop分支拉取功能分支，開發功能1。
feature-1 => test 開發結束後，提pr。通過則整合**進test環境（測試階段），駁回則修改後再次提交pr，直至測試通過。
feature-1 => box 測試通過後，feature-1如果需要上線則提pr申請合併到box分支，進行灰度測試。
feature-1 => develop 灰度通過後，將feature-1分支整合進develop分支，準備上線。
develop => master 上線成功後，將develop分支同步至master分支並打上tag。並刪除feature-1功能分支。
develop => feature-hotfix 線上緊急bug，從develop分支拉feature-hotfix分支，流程與普通feature一致。
pr流程：在gitlab上提pr後，郵件或釘釘通知審核人。審核人在gitlab或ide上進行review。
方案學習成本
依賴場景
備註現有方案
小git
規範流程
能滿足目前開發需求，對接自動化構建部署，成本較小容易出結果。
gitflow
大smartgit
多人開發，分支管理
經得住時間考驗的分支管理流程，能力上肯定是gitflow更強。對團隊的成長意義更大。
提pr的粒度太大，pr的實際意義可以跟eslint效果一致。
衍生問題，test和預上線環境的bug需要走pr嗎。
結論：都要走pr。所有人都可以審pr，只有當pr 的agree人數超過數量，才算通過。
例：10個人審pr，有3人點通過後，則此次pr通過。
Git工作流概述
基於master分支開發 流程 建立origin master分支 協作開發者a b把origin master 分支clone到本地 協作開發者a b在本地master分支進行開發 a開發完push到遠端master分支 b開發完push到遠端master分支 衝突處理 push時本地 與遠端ma...
Git 工作流簡介
工作流有各式各樣的用法，但也正因此使得在實際工作中如何上手使用增加了難度。這篇指南通過總覽公司團隊中最常用的幾種 git 工作流讓大家可以上手使用。如果你的開發團隊成員已經很熟悉 subversion，集中式工作流讓你無需去適應乙個全新流程就可以體驗 git 帶來的收益。這個工作流也可以作為向更 g...
git學習筆記 git工作流
1 新增檔案 git add filename.postfix 2 提交檔案 git commit m 3 修改後，重新新增 git add 未提交 返回原來版本 git reset head filename git checkout filename 讓工作區變乾淨 4 修改後，新增 git a...