Git分支管理規范

分支種類

主分支（master）

開發分支（develop)

功能分支（feature)

修復分支（hotfix）

預發布分支（release）

 

分支描述

Master：主分支，創建 Repository 時默認會生成一個 master 分支。通常情況下 master 分支是受保護的（Protected）。master 分支保存的是穩定的已發布到線上的代碼，會使用 tag 來記錄發布的版本（tag命名為：tag + “-” + “版本號”）。master 分支是不允許提交代碼的，只能將代碼合並（merge）到 master。在藍綠部署的情況下，綠色部署環境需要部署此分支代碼。

Develop：開發分支，從 master 創建。需要注意的是，develop分支的代碼是通過feature分支合並而來的。通常情況下我們是不會在 develop 上開發的，因為你不能確定這些是否需要上線（或者說無法確定在哪次迭代上線）。

Feature：功能分支，從 develop 創建。feature 分支是用來開發新功能的，通常情況下新功能開發完畢后會合並的 develop。

Release：預發布分支 從 develop 創建。當一次迭代的功能開發並自測完成后，就可以創建發布分支。該分支通常用於測試，我們不能在該分支上完成除Bug 修復外的其他工作。測試完成后，我們需要將 release 分支合並到 master 進行發布。發布完成后在 master 打上 tag 記錄此次發布的版本。在藍綠部署的情況下，藍色部署環境需要部署此分支代碼。

Hotfix：修復分支，從 master 創建。當我們發現線上 Bug 時，會從 master 分支上對應的 tag 處創建新的 hotfix 分支，用來修復 bug。通常情況下，緊急修復的發布相對簡單，在 Bug 修復並測試完成后，可直接合並到 master 進行發布（注意：如果在藍綠部署的情況下，需要將bug修復之后的代碼重新打包，並部署到藍色環境下等待測試通過后，再將代碼合並到master上）。發布完成后在 master打上 tag 記錄此次發布的版本，並將 hotfix 合並到 develop。

 

分支命名規范

主分支（master）

開發分支（develop)

功能分支（feature)： feature-版本號

修復分支（hotfix）： hotfix-禪道bug號(當前解決了的bug號)-日期(YYYYMMDD)

預發布分支（release）：release-版本號

 

多人協作開發分支使用流程

在多人協作開發的情況下，所有分支需要全部上傳到雲倉庫。
Master分支用來部署生產環境，release分支用來部署預發布環境。
Master、develop、release分支上嚴禁提交代碼,只支持代碼合並。
當生產環境發生緊急bug時，需要通過hotfix分支進行bug修復。 bug修復后將hotfix分支打包發布到預發布環境，待測試通過后再將代碼合並到master與develop分支上。
當預發布環境產生bug時，代表當前開發的功能版本存在缺陷。 bug修復在原feature分支上修復即可。Bug修復后將代碼依次合並到develop和release分支上。
Release、feature分支至少要多保存一個版本。例如：當前feature分支在開發1.2功能需求，既當前feature分支名稱為feature-1.2，那么git倉庫中release分支和feature分支至少要留存feature-1.1和release-1.1版本的分支。

單人開發分支使用流程

在單人開發的情況下，master、develop分支需要上傳到雲倉庫，feature分支只在本地保存即可。
Master分支用來部署生產環境，develop分支用來部署預發布環境。當生產環境
Master分支上嚴禁提交代碼,只支持代碼合並。
當生產環境發生緊急bug時，需要通過feature分支進行bug修復，既創建分支：feature-bug-日期。 bug修復后將feature-bug分支打包發布到預發布環境，待測試通過后再將代碼合並到master與develop分支上，然后並刪除此bug分支。
當預發布環境產生bug時，代表當前開發的功能版本存在缺陷。 bug修復在原feature分支上修復即可。Bug修復后將代碼依次合並到develop分支上。
Develop分支允許小規模代碼提交，例如配置文件修改，參數類型修改。如有代碼邏輯修改需要創建新分支。
feature分支至少要多保存一個版本。例如：當前feature分支在開發1.2功能需求，既當前feature分支名稱為feature-1.2，那么git倉庫中feature分支至少要留存feature-1.1版本的分支

 

————————————————
版權聲明：本文為CSDN博主「neil1314」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/u013214151/article/details/106263710/

 

 

 

代碼倉庫創建規范

1、 項目創建需符合Group規范。

2、 創建項目必須添加Project description說明。

3、 每個項目都需要README.md文件。

4、 除文檔說明類型倉庫，所有代碼倉庫都需要.gitignore。

注：有模板的項目，要以統一的模板創建項目

Groups使用規范

Group 分為 rule(技術行為規范)、lab（技術預研）、common(基礎庫)、xxxxxxd(基礎平台)、xxxxxox(產品)、customer(定制化開發項目)

目錄結構及權限介紹

• rule - Internal

• • 主要用於存放技術行為規范相關資料

• lab - Internal

• • 主要用於存放技術預研，比如shader預研、售前demo技術預研等。

• common - Internal

• • 主要用於存放公共組件庫，基礎算法庫

• xxxxxxud - Private

• • 主要用於存放底層基礎能力平台相關微服務，如PaaS層的接口、網關鑒權服務等。

• xxxxxb - Private

• • 主要存放產品相關業務代碼，如應用中心小程序等。

• customer - Private

• • 主要存放客戶制定化開發項目代碼。

權限說明：gitlab主要包括三種權限Private、Internal、Public，分別為只對組內用戶開放、注冊用戶可見和公開，公司gitlab一般不使用Public

關聯倉庫的管理

涉及內部倉庫之間的引用采用 submodule 進行版本管理，對於可開源發布的版本管理采用包管理，比如pip、npm、go get。

主項目管理形式如下：

A(主項目) --> B(common公共模塊) | |---> C(包管理) | |---> D(其他倉庫) 

將引用項目作為submodule添加到主項目中：

# 添加submodule $ git submodule add <遠程引用模塊倉庫地址> 

子項目版本管理和主項目版本管理是分發的，主項目中的子項目更新需要手動操作：

# 更新子模塊 $ git submodule update --init 

README文件規范

README文件結構如下：

<項目簡介/Introduction> <快速使用/Quick start> <文檔說明/Documentation> 

• Introduction 用於闡述項目基本情況和功能（是什么，用來做什么的）
• Quick Start 主要包括兩部分內容：簡易的安裝部署說明(Deployment)和使用案例(Example)。
• Documentation 部分是核心的文檔，對於大型項目可以使用超鏈接代替

參考：

使用 Description Template

使用 merge request template

(待補充:https://docs.gitlab.com/ee/user/project/description_templates.html)

https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/merge_request_templates/Security Release.md

版本管理規范

項目代碼release包括三類：

• 大版本(x.0.0)
• 小版本(x.x.0)
• 補丁(x.x.x)

版本管理

git 流程模式有兩種：一種是Git flow工作流，一種是Github flow工作流。

Git Flow 分支模型

步驟

• master分支不做代碼提交，master為生產環境運行代碼
• 開發主要在develop分支上進行提交
• 功能開發切換一個新的功能分支上，功能分支完成后需合並到develop分支
• 用release分支做版本發布，release用於預發布環境測試
• release分支從開發分支切出來，完成后需要合並到master分支和develop分支
• 預發布環境測試無誤后，release分支合並到master分支，發布到生產環境測試
• 生產環境測試完成后release分支可以刪除
• 生產環境運行中緊急修復采用hotfix分支，hotfix分支從mater分支切出
• hotfix分支修復后需合並會master分支和develop分支

功能開發

創建功能分支

# 從develop創建功能分支 $ git checkout -b myfeature develop 

完成功能分支，合並develop，並推送到遠程倉庫

# 切換到develop分支 $ git checkout develop # develop分支合並功能分支 $ git merge --no-ff myfeature # 刪除功能分支 $ git branch -d myfeature # 推到遠程倉庫 $ git push origin develop 

版本發布

版本發布前，創建版本分支

# 從develop分支切到版本發布分支 $ git checkout -b release-1.2 develop 

完成版本測試后，合並到master分支上

# 切換到master $ git checkout master # master合並release分支 $ git merge --no-ff release-1.2 # 給master分支打tag $ git tag -a 1.2 

生產環境測試沒有問題后，將release分支合並會develop分支，並刪除release分支

# 切換到develop分支 $ git checkout develop # develop分支合並release分支 $ git merge --no-ff release-1.2 # 刪除release分支 $ git branch -d release-1.2 

臨時補丁

生產環境上發現bug，直接通過hotfix快速修復:

# 從master切出一條分支，緊急修復問題 $ git checkout -b hotfix-1.2 master 

完成問題修復后，合並進master：

# 切到master分支 $ git checkout master # master分支合並hotfix分支 $ git merge --no-ff hotfix-1.2 # 打上新tag $ git tag -a 1.2 # 切換到develop分支 

如果當前release分支還未刪除，合並到release分支，再由release分支合並到develop分支:

$ git checkout release-1.2 # release-1.2合並hotfix分支 $ git merge --no-ff hotfix-1.2 # 刪除hotfix分支 $ git branch -d hotfix-1.2 # 切換到develop分支 $ git checkout develop # develop分支合並release分支 $ git merge --no-ff release-1.2 

如果release分支已刪除，則直接合並到develop分支：

# 切換到develop分支 $ git checkout develop # develop分支合並release分支 $ git merge --no-ff hotfix-1.2 # 刪除hotfix分支 $ git branch -d hotfix-1.2 

原則

• 開發永遠不直接提交到master分支，master保留用於發布到生產中的代碼
• 盡量一個任務，一個功能分支
• 在合並到開發分支前，對每個merge requests測試
• 新功能只添加到develop分支

優缺點

優點：

• 流程清晰，覆蓋面全，通過分支模型將工作流串通
• git flow作為最早提出的分支模型，也是最廣泛使用的分支模型，受眾廣泛
• 以master作為生產分支，面向單版本的線上產品迭代

缺點：

• 分支十分復雜，敏捷性較差
• 僅master分支上做持續集成，而大部分工具默認將master分支設為默認分支，因此經常面臨分支切換，導致很繁瑣
• 修補分支和發布分支設置繁瑣，比如每次使用修補分支都需要同時合並到master和develop分支，但開發經常犯錯誤，比如忘記合並回develop分支

Github Flow 分支模型

面對git flow的繁瑣，github flow分支模型僅具有功能分支和主分支，將所有內容合並到master分支中並進行部署，采用pull request方式進行代碼合並，強調持續集成和連續交付。

優點：

• 流程十分簡單，可以滿足敏捷交付
• 不需要頻繁切換分支，在自己的倉庫進行開發，統一合並master
• 每次提交均需要測試

缺點：

• 對自動化測試要求較高，需要大量的單元測、端到端測試和集成測試
• 模型過於簡單，對於部署、發版和集成上存在着大量問題

Gitlab Flow 分支模型

結合了git flow分支模型和github flow分支模型：

步驟

• 需要一個staging環境和pre-production環境（兩個生產環境鏡像）
• 從主倉庫 fork 到自己的倉庫
• 所有請求直接提交到master分支，每次提交都做持續集成和測試，主要是自動化測試
• 每個merge requests需要描述符合提交規范，每個人出了代碼輸出工作，需要每天抽出時間進行code review。
• 部署發布的時候，從master中摘取(cherry Pick)核心發布功能到"release-x.x.x-alpha"分支進行測試，並在其上進行修復
• 測試通過后，切換到"release-x.x.x"分支並刪除"release-x.x.x-alpha"分支，將"release-x.x.x"分支發布到生產環境中進行測試
• 生產環境測試通過后，將"release-x.x.x"合並回master

要使用好cherry-pick，每個提交要清晰簡潔

功能開發

# fork到用戶倉庫 # 拉取到本地修改 $ git clone <your repo> # 切出一個分支 $ git branch -b feature/xx # 提交 $ git commit # 上傳到自己的倉庫 $ git push origin # 向主倉庫發起merge requests請求，合並到主倉庫master # CI通過並且其他人code review后同意即可合並到主倉庫 

預發布

# 從最新的release版本切出一個新的版本分支release-x.x.x-alpha $ git checkout -b release-x.x.x-alpha # 從master分支cherry-pick所需提交記錄 $ git cherry-pick hash1 hash2 hash3 # 上傳到自己的倉庫 $ git push origin # 向主倉庫發起merge requests請求，合並到release-x.x.x-alpha # CI通過並且其他人code review后同意即可合並到主倉庫 

優缺點

優點：

• 相比git flow分支模型更簡單，減少了分支數量
• 和github flow分支模型一樣，更強調測試，對所有提交都需進行測試或code review

缺點：

• 需要自動化測試流程支撐，需要有較好的持續集成和連續交付基礎

commit規范

git commit 提交樣式規范：

<類型>: <標題> <空一行> <內容> <空一行> <結尾> 

<類型>

用於說明 commit 的類別，只允許使用下面7個標識。

• feat：新功能（feature）
• fix：修補bug
• docs：文檔（documentation）
• style： 格式（不影響代碼運行的變動）
• refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
• test：測試相關改動
• chore：構建過程(CI/CD)或輔助工具的變動

<題目>

commit 目的的簡短描述，不超過50個字符

<內容>

對本次 commit 的詳細描述，可以分成多行，可詳細說明代碼變動的動機

<結尾>

Footer 部分只用於以下兩種情況：

不兼容變動

如果當前代碼與上一個版本不兼容，則 Footer 部分以BREAKING CHANGE開頭，后面是對變動的描述、以及變動理由和遷移方法。

BREAKING CHANGE: isolate scope bindings definition has changed. To migrate the code follow the example below: Before: scope: { myAttr: 'attribute', } After: scope: { myAttr: '@', } The removed `inject` wasn't generaly useful for directives so there should be no code using it. 

關閉 Issue

如果當前 commit 針對某個issue，那么可以在 Footer 部分關閉這個 issue 。

Closes #234 

Example

feat(compiler): comments for if-else conditions #10286 In order to fix these 2 issues, I need to have access to the HTML comments before a v-else block vue-styleguidist/vue-styleguidist#430 vue-styleguidist/vue-styleguidist#322 To give you an example, here is a format that does not work with the current parser. Since we cannot have the comments as normal nodes, I thought we could have the missing comment beside the ifCondition. closes #10288 

Revert

還有一種特殊情況，如果當前 commit 用於撤銷以前的 commit，則必須以revert:開頭，后面跟着被撤銷 Commit 的 Header。

revert: feat(pencil): add 'graphiteWidth' option This reverts commit 667ecc1654a317a13331b17617d973392f415f02. 

Body部分的格式是固定的，必須寫成This reverts commit <hash>.，其中的hash是被撤銷 commit 的 SHA 標識符。

如果當前 commit 與被撤銷的 commit，在同一個發布（release）里面，那么它們都不會出現在 Change log 里面。如果兩者在不同的發布，那么當前 commit，會出現在 Change log 的Reverts小標題下面。

Commitizen

可以使用典型的git工作流程或通過使用CLI向導Commitizen來添加提交消息格式。

安裝

npm install -g commitizen 

然后，在項目目錄里，運行下面的命令，使其支持 Angular 的 Commit message 格式。

commitizen init cz-conventional-changelog --save --save-exact 

以后，凡是用到git commit命令，一律改為使用git cz。這時，就會出現選項，用來生成符合格式的 Commit message。

生成 Change log

如果你的所有 Commit 都符合 Angular 格式，那么發布新版本時， Change log 就可以用腳本自動生成。生成的文檔包括以下三個部分：

• New features
• Bug fixes
• Breaking changes.

每個部分都會羅列相關的 commit ，並且有指向這些 commit 的鏈接。當然，生成的文檔允許手動修改，所以發布前，你還可以添加其他內容。

conventional-changelog 就是生成 Change log 的工具，運行下面的命令即可。

$ npm install -g conventional-changelog $ cd my-project $ conventional-changelog -p angular -i CHANGELOG.md -w

轉載地址：https://www.cnblogs.com/zisefeizhu/p/13621797.html