Git 提供了豐富的分支策略和工作流方式，我們在深入學習業界 Git 工作流時，每種工作流都設計的非常好，似乎都能運用到團隊實踐。但在引入 Git 工作流規範開發時要留意：Git 工作流僅僅是整個研發流程中的一環。上游項目管理/缺陷追蹤系統虎視眈眈，下游 CD (Continuous Delivery) 嗷嗷待哺，還得考慮團隊規模、產品形態、發版方式等等因素。因此，在團隊中落地 Git 工作流規範並不是一件能輕鬆決定的事。
字節跳動 Git 倉庫有效的 CR (Code Review) 覆蓋率 70%，仍有提升空間，通過調研，團隊中又以 GitHub Flow 模式居多。隨着字節研發效能建設愈發完善，GitHub Flow 已無法充分利用研發設施進行提效並保障工程質量，很多團隊均意識到這點並着手建設流程規範。
本文通過介紹業界 Git 工作流和公司研發設施現狀，力求從倉庫形態、部署流程等多角度進行分析，給出一些制定工作流規範的建議。
業界 Git 工作流介紹
Git Flow
初級 Git 開發者，面對這滿圖的分支和 merge 指向，簡直想手撕作者。高級 Git 開發者要將這個流程運用實踐也大感頭疼。
Git Flow 有不少優點：
- 分支各司其職，覆蓋大部分開發場景。
- 預期 master 分支中任何 commit 都是可部署的。
- 嚴格按照流程執行，出現重大事故的情形會大大降低。
原文鏈接:【https://www.infoq.cn/article/9DoTSVlWSczNBxJpxfqE】。未經作者許可，禁止轉載。