您的位置: 首页  >  文章  >  git分支与提交规范

git分支与提交规范

分类: 文章 • 2023-11-07 07:48:52

一、分支管理

分类

1.常设分支master和develop ，此些分支不允许有任何的代码提交，修改只能是从release，hotfix，develop的

分支进行Pull Request合并（下面简称PR）

2.临时分支 分为release发布，feature功能，hotfix热修复分支

版本分支的维护由项目后端负责人负责切换和merge整合

注意:

  • 个人分支不做限制（例：以前代码要重构或者修复bug，新功能又要开发，可以自行切分支，记得合并就好）

  • develop和master分支的PR由项目负责人负责规范(实操在gitee上)

  • git user.name 建议要求改成中文名称（命令如下 git config --global user.name “自己的中文名字”）

介绍

  • Production 分支（生产分支）

    也就是我们经常使用的master分支，这个分支是最近发布到生产环境的代码。并且master分支不允许又任何提交记录。

    仅接受来自功能分支（feature/fix）的 PR 或 热修复分支（hotfixe）的 cherry-pick（下文简称为 CP）

    每个合到master分支上的提交都要加Tag

  • Develop 分支（开发分支）

    develop 分支用于日常开发，作为功能的聚合分支，存放最新的开发版本。并且 develop 分支也不允许有任何提交

    记录。仅接受来自功能分支（feature/fix）的 PR 或 热修复分支（hotfixe）的 cherry-pick（下文简称为 CP）

    同master分支

  • Feature 分支（功能/模块/任务分支）

    feature/fix 分支是从 develop 分支中 checkout 出来的新分支，每个产品需求或测试的 BUG 对应一个 feature/fix 分

    支。一旦开发完成并且在本开发周期内要上线，将被要求向 develop 分支提交 PR，待 Review 通过后允许合入；

    （强制，已推广公司）命名为 feature-xxx/fix-xxx 关联相关产品需求或 BUG（xxx 为 Gitee 任务编号）。

git分支与提交规范
图2.1

  • Release分支（发布/预测分支）

    release 分支是每个开发周期初（如每周一）从 master 分支 checkout 出来的新分支，且 release 分支会自动构建

    测试版本，开发完成并且在本开发周期内要上线的 feature/fix 分支内的所有提交被允许 CP 到该分支就行测试；

    全部 测试通过后由项目负责人向 master 分支提交 PR 合入完成上线；（建议）命名为 release-xx 关联开发周期
    （xx 可以 为本年度第 xx 周）。

  • Hotfix分支

    hotfix 分支是从 master 分支 checkout 出来用于修复线上发现的严重 BUG；BUG 修复完成后将被要求向 master

    分支提交 PR，待 Review 通过后由项目负责人合入，并同时要求向 develop 分支 CP 本次修复的所有提交；

    （建议）命名为 hotfix-xxx 关联相关 BUG（xxx 可以为 Gitee 任务编号）。
    注意：这个分支只允许处理紧急bug，测试或者对接过程中的bug修复，应个人对应的开发拉取develop分支，

    然后再个人开发分支上进行

分支粒度

分支粒度分为两个维度：版本 、个人

分支粒度以个人为最小粒度（涵盖开发，bug修复，测试分支等）
注释:个人粒度下，每日提交需要详细到以下

  • 以一个小功能、小改进或一个 bug fix 为单位
  • 对应的 unit test 程序在同一个 commit
  • 无相关的修改不在同一个 commit
  • 语法错误的半成品程序不能 commit
  • 少量的无归属修改可以酌情合并commit（commit --amend命令）
  • 严禁一个任务分支feature-xxx开发多个功能
  • 严禁一个提交设计多个不相关功能，任务，模块等

二、提交管理（个人分支commit）

1.commit代码需将代码粒度区分至模块，接口，文档，注释，等。
粒度区分完毕再以做的事情来作为命名此次commit提交，见第2点
优点：有助于同事的code review，个人版本的回退等，规范化也使得提交赏心悦目

2.粒度区分完毕后，commit的信息规范如下（推荐插件Git Commit Template）

  • feat：新功能/模块（feature）
  • fix：修补bug
  • docs：文档（documentation）
  • style：不影响程序逻辑的代码修改(修改空白字符，格式缩进，补全缺失的分号等，没有改变代码逻辑)
  • refactor：重构代码(既没有新增功能，也没有修复 bug)
  • perf：代码性能提升（个人建议合到refactor分支，因为性能提升往往伴随着重构）
  • test：新增测试用例或是更新现有测试
  • chore：构建过程或辅助工具的变动（pom新增依赖，****等）
  • revert：回滚某个更早之前的提交

3.插件使用

commit消息包含三个部分，header（必需），body（可选）和footer（可选）见图2.2
git分支与提交规范
图2.2

作者建议写header就好，header所包含的三个子部分，就足以涵盖提交要素 见图2.3

git分支与提交规范
图2.3（红色为必写）

git分支与提交规范
图2.4：生成的commit消息

三、Pull Request和Code Review

PR发生在develop和master分支上，由项目负责人进行审核

Code Review，小伙伴们可以fetch命令下载所有远程分支的代码，或者PR的时候也可以

目的

  • 项目早期发现bug
  • 帮助初级程序员学习
  • 避免开发人员犯一些很常见，很普通的错误
  • 保证项目组人员的良好沟通
  • 项目或产品的代码更容易维护

直观改善

强制性要求开发人员代码规范，可读性，稳定性，维护性提高，流水化代码产出，提高效率。

规范

未完成
（该部分主要分为前端和后端的代码规范，PR和CR一般多注重代码规范而不是功能测试，作者是后端开发，后续跟同

事合作编写完成会跟大家分享）

四、Rebase 和Cherry-Pick

这一部分当时想写来着，不过都是简单的命令使用，还有stash等提升开发效率的命令，大家实际工作中多使用就会了

解了，这里就不赘述了，当天直播中也由实操过，希望大家能真实场景使用起来。尤其是rebase命令。

五、写在最后

规范只是一种约定，小伙伴们如果对这份文档有疑问，有意见或者建议都可以跟博主联系

[email protected] 或者 [email protected]

相关推荐