Git分支管理

簡介

git分支只要有 主分支 和 其他分支。

主分支：主分支是所有開發活動的核心分支。所有的開發活動產生的輸出物最終都會反映到主分支的程式碼中。

其他分支：其他開發活動建立的分支，如hotfix分支（緊急修復），release（釋出新版本）等分支

master分支

作用： master分支上存放的應該是隨時可供在生產環境中部署的程式碼（Production Ready state），是當前系統的穩定版本。當開發活動告一段落，產生了一份新的可供部署的程式碼時，master分支上的程式碼會被更新。同時，每一次更新，都有對應的版本號標籤（TAG）。

develop分支

作用：develop分支是儲存當前最新開發成果的分支。也就是我們開發環境執行，測試環境部署的程式碼。通常這個分支上的程式碼也是可進行隨時釋出部署的程式碼（Nightly build）。因此這個分支有時也可以被稱作“integration branch”。

合併：develop分支上的程式碼已實現了當前版本中所有的迭代開發的功能，通過了所有的測試後，並且程式碼已經足夠穩定時，就可以將所有的開發成果合併回master分支了。對於master分支上的新提交的程式碼建議都打上一個新的版本號標籤（TAG），供後續程式碼跟蹤使用。

release分支

建立： 當develop分支上的程式碼已經開發完成，包含了所有即將釋出的版本中所計劃包含的軟體功能，並且已通過所有測試時，我們就可以考慮準備建立release分支了。注意：而所有在當前即將釋出的版本之外的業務需求一定要確保不能混到release分支之內（避免由此引入一些不可控的系統缺陷）。

作用： release分支是為釋出新的產品版本而設計的。在這個分支上的程式碼允許做小的缺陷修正、準備釋出版本所需的各項說明資訊（版本號、釋出時間、編譯時間等等）。通過在release分支上進行這些工作可以讓develop分支空閒出來以接受新的feature分支上的程式碼提交，進入新的軟體開發迭代週期。

使用: 從develop分支派生，必須合併回develop分支和master分支

hotfix分支

建立：正式生產環境軟體遇到了異常情況或者發現了嚴重到必須立即修復的軟體缺陷，對軟體進行緊急修復工作。從master分支上指定的TAG版本派生hotfix分支

作用：hotfix分支用來進行軟體程式碼的緊急修復工作。hotfix分支與release分支十分相似，都可以產生一個新的可供在生產環境部署的軟體版本。

使用: 從master分支派生，必須合併回develop分支和master分支

feature分支 （不常用）

feature分支（有時也可以被叫做“topic分支”）通常是在開發一項新的軟體功能的時候使用，這個分支上的程式碼變更最終合併回develop分支或者乾脆被拋棄掉（例如實驗性且效果不好的程式碼變更）。

一般而言，feature分支程式碼可以儲存在開發者自己的程式碼庫中而不強制提交到主程式碼庫裡。

其他介紹：

主分支 master 主分支，所有提供給使用者使用的正式版本，都在這個主分支上釋出
開發分支 dev 多人合作的開發分支①每個人開發完成內容合併到此分支，供同事拉取②聯調此分支上③聯調完畢推到test分支
功能分支 feature/20220708_login 個人功能分支，某個功能點正在開發階段(開發完成合併到dev分支)
測試分支 release/test 測試分支沒有問題 合併到master分支
修復分支 hotfix/20220708_login_captcha_error 修復線上程式碼的bug
釋出版本 將測試完成的功能打tag號 供上線使用 例如TAG-2022-08-01_21-03-22

一、命名目的

規範開發，保持程式碼提交記錄，容易維護，方便事後算賬，不背鍋。
git分支結構清晰， 好上線，一旦出問題，版本可回退

二、 git 分支命名規範

git 分支分為整合分支、功能分支和修復分支，分別命名為 develop、feature 和 hotfix，均為單數。不可使用 features、future、hotfixes、hotfixs 等錯誤名稱。

• master（主分支，永遠是可用的穩定版本，不能直接在該分支上開發）
• develop（開發主分支，所有新功能以這個分支來建立自己的開發分支，該分支只做只合並操作，不能直接在該分支上開發）
• feature-xxx（功能開發分支，在develop上建立分支，以自己開發功能模組命名，功能測試正常後合併到develop分支）
• feature-xxx-fix(功能bug修復分支，feature分支合併之後發現bug，在develop上建立分支修復，之後合併回develop分支。
  • PS:feature分支在申請合併之後，未合併之前還是可以提交程式碼的，所以feature在合併之前還可以在原分支上繼續修復bug)
• hotfix-xxx（緊急bug修改分支，在master分支上建立，修復完成後合併到 master）

注意事項：

• 一個分支儘量開發一個功能模組，不要多個功能模組在一個分支上開發。
• feature 分支在申請合併之前，最好是先 pull 一下 develop 主分支下來，看一下有沒有衝突，如果有就先解決衝突後再申請合併

本人命名規範

• 示例一 ``
  例如： feature/20200305_screen 大屏功能
  例如： fixbug/20200424_screen_data_error 修復大屏日期錯誤
  例如： release/test 測試分支

2. git 提交記錄規範

每個 git commit 記錄都需要按照固定格式，具體格式為：
第一行：作者: 功能模組名稱（或 功能模組ID）
第二行：提交描述，中英文皆可
　　+ ：增加程式碼
　　* ：修改程式碼
　　- ：刪除程式碼

master 主分支 對應線上，版本上線，開發人員將對應上線tag版本合併至master分支
release. 主分支 同 master 分支，預發環境通過之後，上線之前，合併 release 分支
dev-* 輔助分支 從 master 拉取，用於新需求(版本)開發 *號為版本號+期次號
bugfix-* 輔助分支 從 master 拉取，用於快速修復線上Bug *號為bug英文簡稱+期次號
release-* 輔助分支 從 master 拉取，用於確保當前版本是基於線上最新版本迭代，可處理與線上程式碼存在的衝突,任務輔助分支在測試環境通過之後，上預發環境之前，務必拉取一個release-* 分支 *號為對應的 dev-* 或 bugfix-* 的*

三、分支管理

需求（版本）開發 從 master 拉取 dev 分支

分支命名規則 ：型別 - 版本號 
Tag命名規則： 型別 - 版本號 - 期次號

例子：

• 分支：

 dev-v2.0.1
 release-v2.0.1

• Tag

 dev-v2.0.1-102401
 release-v2.0.1-102401

線上問題處理 從 master 拉取 bugfix 分支

分支命名規則：型別 - bug英文簡稱
Tag命名規則： 型別 - bug英文簡稱 - 期次號

• 例子：

 分支：
 bugtfix-dateError
 release-dateError
 Tag:
 bugfix-dateError-102401
 release-dateError-102401

https://blog.csdn.net/a6864657/article/details/107236221

https://www.ngui.cc/51cto/show-775690.html?action=onClick