Git分支管理使用规范

gtxyzz linux 2023-01-26 545浏览 0

Git分支管理规范

俗话说：没有规矩，不成方圆。遵循一个好的规章制度，就像工欲善其事，必先利其器一个道理，能让你的工作事半功倍。同时也可以展现出你做事的认真的态度以及你的专业性，不会显得杂乱无章，管理困难。Git分支规范也是一样。当遵循了某种约定的Git分支，在代码提交以及多开发、多分支协同工作的时候，必须遵循这个规范操作，否则不予以提交代码、合并代码、提测、以及打包上限等操作。

Git Flow是Vincent Driessen提出的一个分支管理的策略，http://nvie.com/posts/a-successful-git-branching-model/，应用这个规范可以使得版本库的演进保持简洁，主干清晰，各个分支有不同的职责，在很大程度上减少冲突的产生。

Git Branch使用规范

分支约定

Git Flow有主分支和辅助分支两类分支。其中主分支用于组织与软件开发、部署相关的活动；辅助分支组织为了解决特定的问题而进行的各种活动
主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。主分支分为master分支和develop分支。

主分支

master分支

master分支存放的是随时可供在生产环境中部署的稳定版本代码
master分支保存官方发布版本历史，release tag标识不同的发布版本
一个项目只能有一个master分支
仅在发布新的可供部署的代码时才更新master分支上的代码
每次更新master，都需对master添加指定格式的tag，用于发布或回滚
master分支是保护分支，不可直接push到远程仓master分支
master分支代码只能被release分支或hotfix分支合并

develop分支

develop 为开发分支，一般包含正在开发的所有新特性
develop分支不能与master分支直接交互
develop分支衍生出各个feature分支
develop分支是保护分支，不可直接push到远程仓库develop分支
一个项目只能有一个develop分支

辅助分支

辅助分支是用于组织解决特定问题的各种软件活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作、以及对版本代码的测试。这些分支与主分支不同，通常只会在有限的时间范围内存在。

辅助分支包括：

用于开发新功能时所使用的feature分支
用于辅助版本发布的release分支
用于修正生产代码中的缺陷的hotfix分支

以上这些分支都有固定的使用目的和分支操作限制。从单纯技术的角度说，这些分支与Git其他分支并没有什么区别，但通过命名，我们定义了使用这些分支的方法。

feature分支

使用规范：

命名规则：feature/*
develop分支的功能分支
feature分支使用develop分支作为它们的父类分支
以功能为单位从develop拉一个feature分支
每个feature分支颗粒要尽量小，以利于快速迭代和避免冲突
当其中一个feature分支完成后，它会合并回develop分支
当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃，不影响develop分支
feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里
feature分支只与develop分支交互，不能与master分支直接交互

如有几个同事同时开发，需要分割成几个小功能，每个人都需要从develop中拉出一个feature分支，但是每个feature颗粒要尽量小，因为它需要我们能尽早merge回develop分支，否则冲突解决起来就没完没了。同时，当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃，不影响develop分支。

release分支

使用规范：

命名规则：release/，“”以本次发布的版本号为标识
release分支主要用来为发布新版的测试、修复做准备
当需要为发布新版做准备时，从develop衍生出一个release分支
release分支可以从develop分支上指定commit派生出
release分支测试通过后，合并到master分支并且给master标记一个版本号
release分支一旦建立就将独立，不可再从其他分支pull代码
必须合并回develop分支和master分支

release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。

当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）。

成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。

hotfix分支

使用规范：

命名规则：hotfix/*
hotfix分支用来快速给已发布产品修复bug或微调功能
只能从master分支指定tag版本衍生出来
一旦完成修复bug，必须合并回master分支和develop分支
master被合并后，应该被标记一个新的版本号
hotfix分支一旦建立就将独立，不可再从其他分支pull代码

除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。

当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。

这样做的显而易见的好处是不会打断正在进行的develop分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。

bugfix分支

修补分支：软件发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补
修补bug分支是从master或release分支上面分出来的。修补结束以后，再合并进master和develop以及release对应版本分支。它的命名，可以采用 fixbug- * （日期）的形式。

分支责任分工

分支	职责描述
master	开发经理：统一创建、维护，运维人员：部署
develop	开发经理：统一创建，开发人员：维护，部署
release	开发经理：统一创建、维护，运维人员：部署
feature	开发人员：各模块自行创建、维护
bugfix	开发经理：统一创建、部署、维护。开发人员：修复bug，协助解决自动merge中发生的冲突

分支对应的环境

分支	环境
master/hotfix/bugfix	线上环境(release)
develop	开发环境(alpha)
release	测试(beta)和预发布(RC)环境

我公司的规范

结合了Gitflow和workflow两者，根据公司情况稍作改变。

分支	环境
master	pre(作为预发布环境，只允许从dev分支合并到该分支)
dev	perf环境(作为测试环境，只允许从feature分支合并到该分支)
feature	sit环境(作为开发环境，允许开发直接从本地提交代码到该分支)

代码合并规范

Master：

在初始化仓库时创建
只接受来自dev和hotfix分支的MR(Merge Request)
作为长期分支存在

Dev：

从master分支checkout
只接受来自feature、bugfix、hotfix分支的合并
生命周期跟随Springt周期

Feature：

从dev分支checkout
只允许开发人员push代码，不接受任何分支的MR
生命周期跟随上游dev分支(等同于jira任务)。即合并到dev分支后删除该分支(也可以不删除)。

Bugfix：

从dev分支checkout
不接受任何分支的MR
生命周期跟随上游dev分支(等同于jira任务)

Hotfix：

从master分支checkout
不接受任何分支的MR
每次合并都需要合并到master分支和当前所有的dev分支

master分支发布服务会首先渲染成一个Chart包，然后推送到harbor中。
生产环境则是由python3+django开发的一个平台，拿到harbor的chart包然后进行在web上修改，修改完成后发布到生产环境。

分支命名规则：

master
dev/v1.0.0或者dev/week01
feature/JID-1/allenjol

其中JID-1表示jira的id号，allenjol表示开发者英文名。强制设置分支格式的正则表达式如下.gitlab-ci.yml的workflow中进行控制。GitLab CICD服务发布通过.gitlab-ci.yml实现。

workflow规则如下：

variables:
  DOCKER_REGISTRY_URL: registry.sit.bunian.cn
  HELM_REPO_URL: "https://registry.sit.bunian.cn"
  GIT_STRATEGY: clone

workflow:
  rules:
    - if: '$CI_PROJECT_NAMESPACE == "paas"'
      when: bunian
    - if: '$CI_PIPELINE_SOURCE =~ "(web|webide)" && $CI_COMMIT_BRANCH =~ /^(?:master|(?:feature|bugfix|hotfix)\/[A-Z]{1}[A-Z0-9]{1,9}-[0-9]+\/\w{1,10}|dev\/(?:(?:v(?:10|\d)\.[0-9]{1,2}\.[0-9]{1,2})|week[0-9]{1,2}))$/'
      when: bunian
    - if: '$CI_PIPELINE_SOURCE =~ "merge_request_event" && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ /^master$/ && $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^(?:hotfix\/[A-Z]{1}[A-Z0-9]{1,9}-[0-9]+\/\w{1,10}|dev\/(?:(?:v(?:10|\d)\.[0-9]{1,2}\.[0-9]{1,2})|week[0-9]{1,2}))$/'
      when: bunian
    - if: '$CI_PIPELINE_SOURCE =~ "merge_request_event" && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ /^dev\/(?:(?:v(?:10|\d)\.[0-9]{1,2}\.[0-9]{1,2})|week[0-9]{1,2})$/ && $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^(?:feature|hotfix|bugfix)\/[A-Z]{1}[A-Z0-9]{1,9}-[0-9]+\/\w{1,10}$/'
      when: bunian
    - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH =~ /^(?:master|(?:feature|bugfix|hotfix)\/[A-Z]{1}[A-Z0-9]{1,9}-[0-9]+\/\w{1,10}|dev\/(?:(?:v(?:10|\d)\.[0-9]{1,2}\.[0-9]{1,2})|week[0-9]{1,2}))$/'
      when: bunian
    - when: never
...

tag使用规范

版本号(tag)命名规则：主版本号.次版本号.修订号，如2.1.13。(遵循GitHub语义化版本命名规范)
版本号仅标记于master分支，用于标识某个可发布/回滚的版本代码
对master标记tag意味着该tag能发布到生产环境
对master分支代码的每一次更新(合并)必须标记版本号
仅项目管理员有权限对master进行合并和标记版本号

代码提交规范

基本要求

所有commit必须有注释，内容必须简洁明了的描述本次commit涵盖了哪些内容。严禁注释内容过于简单或不能明确表达提交内容的！
合理控制提交内容的颗粒度，一次commit含一个独立功能点。严禁一次提交涵盖多个功能项。
正确为每个项目设置Git提交用到的user.name和user.email信息，以公司邮箱为准，不可随意设置以影响无法正确识别。

git commit 日志规范

根据 angular 规范提交 commit，这样 history 看起来更加清晰，还可以自动生成 changelog。

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

type

提交 commit 的类型，包括以下几种

feat: 新功能

fix: 修复问题

docs: 仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等

style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑

refactor: 代码重构，没有加新功能或者修复bug

perf: 优化相关，比如提升性能、体验

test: 测试用例，包括单元测试、集成测试等

chore: 改变构建流程、或者增加依赖库、工具等

revert: 回滚到上一个版本

scope

修改文件的范围（包括但不限于 doc, middleware, core, config, plugin）

subject

用一句话清楚的描述这次提交做了什么
body

补充 subject，适当增加原因、目的等相关因素，也可不写。
footer

当有非兼容修改(Breaking Change)时必须在这里描述清楚

关联相关 issue，如 Closes #1, Closes #2, #3

如果功能点有新增或修改的，还需要关联文档 doc 和 egg-init 的 PR，如 eggjs/egg-bin#123

示例：

fix($compile): [BREAKING_CHANGE] couple of unit tests for IE9
Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.
Document change on eggjs/egg#123
Closes #392
BREAKING CHANGE:
  Breaks foo.bar api, foo.baz should be used instead