git branch commit 规范

深藏阁楼爱情的钟 2023-10-04 23:06 40阅读 0赞

## 分支种类 ##

主分支（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版本的分支

#### 代码仓库创建规范 ####

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` 部分是核心的文档，对于大型项目可以使用超链接代替

参考：

![4094b85e3843cedd8807a52e372d2340.png][]

#### 使用 Description Template ####

使用 merge request template

(待补充:[Description templates | GitLab][Description templates _ GitLab])

[Files · master · GitLab.org / GitLab · GitLab][Files _ master _ GitLab.org _ GitLab _ GitLab] Release.md

### 版本管理规范 ###

项目代码release包括三类：

*  大版本(x.0.0)
 *  小版本(x.x.0)
 *  补丁(x.x.x)

### 版本管理 ###

git 流程模式有两种：一种是`Git flow`工作流，一种是`Github flow`工作流。

#### Git Flow 分支模型![d8cd3f9f387c496eafa11ce6a693b27d.png][] ####

步骤

*  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分支模型：![0b671ccbfb1942a3a94333cd91e33656.png][]

步骤

*  需要一个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

[4094b85e3843cedd8807a52e372d2340.png]: https://img-blog.csdnimg.cn/img_convert/4094b85e3843cedd8807a52e372d2340.png
[Description templates _ GitLab]: https://docs.gitlab.com/ee/user/project/description_templates.html
[Files _ master _ GitLab.org _ GitLab _ GitLab]: https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/merge_request_templates/Security
[d8cd3f9f387c496eafa11ce6a693b27d.png]: https://img-blog.csdnimg.cn/d8cd3f9f387c496eafa11ce6a693b27d.png
[0b671ccbfb1942a3a94333cd91e33656.png]: https://img-blog.csdnimg.cn/0b671ccbfb1942a3a94333cd91e33656.png
[Commitizen]: https://link.jianshu.com/?t=https%3A%2F%2Fgithub.com%2Fcommitizen%2Fcz-cli
[conventional-changelog]: https://link.jianshu.com/?t=https%3A%2F%2Fgithub.com%2Fajoslin%2Fconventional-changelog