摘要：一文講述git分支管理策略，
本文分享自華為云社區《如何做好分支管理，保證高效CICD？》，作者：華為云PaaS服務小智，
引言
CI/CD是DevOps 的基礎核心，做好CI/CD是保證能夠頻繁向客戶交付應用的基礎，其中CI指的是持續集成，即頻繁地（一天多次）將代碼集成到主干，CD指的是持續交付，旨在以更高的速度和頻率構建、測驗和發布軟體，CI要有效率，但是，現階段軟體規模越來越龐大，成百上千的開發人員在同一代碼庫上協作提交代碼，通常會出現代碼越多質量越差的情況，如何保證持續穩定的發布版本，不讓代碼提交成為專案瓶頸？今天我們來聊一聊為了做好CI，如何進行代碼的分支管理？
軟體開發經過多年的發展，開發模式經過不斷的演進，同時代碼管理工具也在不斷的更新換代，眼下最流行的代碼版本管理系統，非Git莫屬了，相比同類軟體，Git的一個很顯著的優點，就是具有優秀的分支模型 , 創建/合并分支非常的方便，它能支持多人協同開發同時，保證版本清晰的演進，
Git分支管理策略（GitFlow）
1.1常設分支
常設分支指的是指日常開發作業中始終存在的分支，包括master分支和develop分支，
1.1.1master-主干分支：
每個代碼倉庫有且只有一個master分支，master分支是用于發布到生產環境的分支，代碼時刻處于生產就緒狀態，為保證產品版本穩定，必須進行嚴格的管理控制，比如不允許在master分支上直接修改代碼，只允許從其他分支合入；在發布準備期，只接受修復bug，不接受新功能代碼合入等等，
1.1.2 Develop-開發分支：
由于master分支只發布重大版本，不允許直接修改代碼，日常開發都在develop分支上完成，如果想正式發布，就需要在Master分支上，對Develop分支進行"合并"（merge），
1.2 臨時分支
前面講了master和develop兩個常設分支，其實這兩條已經可以滿足一般開發場景的需求了，但是，為了應對一些特定目的的版本開發，還需要一些臨時性分支，臨時性分支在開發完合入到其他分支后一般都會洗掉掉，需要的時候再臨時創建，
1.2.1 feature-功能分支：
如果團隊規模比較大，數十上百個開發人員都不斷的向develop分支提交代碼，難免會引入諸多問題，所以在需要開發一個新的功能特性時，會從develop上拉取一個feature分支，在這個分支上進行功能特性的開發，開發完成經過驗證沒有問題，再合入develop分支，
1.2.2 release-預發布分支：
在發布正式版本之前，我們需要對即將發布的版本進行測驗，bug修復，這時可以從develop分支上拉取一個release分支，在這個分支上進行測驗和bug修復，預發布結束后必須將這個分支合并進develop和master分支，
1.2.3 hotfix-修補bug分支：
版本正式發布后，難免會出現bug，這時需要在master分支上拉取一個hotfixes分支，在此分支上進行bug修復后，再合入master和develop分支上，
寫在最后的話
以上介紹了git分支管理策略，做好CI跟很多因素有關，工具可以一定程度上幫助團隊解決一些問題，但是工具不是萬能的，還需要依賴具體的人、流程、規范、開發模式等等因素，團隊在開發運作中與工具、流程不斷磨合找到最適合自己團隊的方式才是最重要的，
點擊關注，第一時間了解華為云新鮮技術~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/502461.html
標籤：其他