Git使用规范指南

文章目录

Git使用规范指南

前言

由于最近写完代码之后,Git使用不规范被领导说了,所以最近通过阅读大量的相关博客快速学习Git使用规范,关于Git的相关基础知识,可以参考我的这篇文章:Git、Github、Gitee、GitLab学习笔记-CSDN博客

PS:参考资料在文末,至此也十分感谢互联网上哪些无私分享知识的前辈,可能文中存在纰漏或者描述不当的地方,还请各位大佬能够告知博主,博主将不胜感激

分支命名规范

分支 功能 环境 可访问
master 主分支,稳定版本 pro
develop 开发分支,最新版本 dev
feature 开发分支,实现新特性
test 测试分支,功能测试 fat
release 预上线分支,发布新版本 uat
hotfix 紧急修复分支,修复线上bug
  • 常见的各种分支

    • master:主分支,也是用于部署生产环境的分支,需要确保master分支稳定性。master 分支一般由 release 以及 hotfix 分支合并,任何时间都不能直接修改代码。

    • develop:开发分支,始终保持最新完成以及bug修复后的代码,用于前后端联调。一般开发的新功能时,feature分支都是基于develop分支创建的。

    • feature:开发新功能时,以develop为基础创建feature分支。

      分支命名时以 feature/ 开头,后面可以加上开发的功能模块, 命名示例:feature/user_modulefeature/cart_module

    • test:测试分支,外部用户无法访问,专门给测试人员使用,版本相对稳定。

    • release:预上线分支(预发布分支),UAT测试阶段使用。一般由 test 或 hotfix 分支合并,不建议直接在 release 分支上直接修改代码。

    • hotfix :线上出现紧急问题时,需要及时修复,以 master 分支为基线,创建 hotfix 分支。修复完成后,需要合并到 master 分支和 develop 分支。分支命名以hotfix/ 开头的为修复分支,它的命名规则与 feature 分支类似。

  • 常见的各种环境

    • pro(production environment):生产环境,面向外部用户的环境,正式环境,连接上互联网即可访问。
    • sit(system Integration test):系统集成测试,开发人员自己测试流程是否走通。
    • uat(user acceptance test environment):用户验收测试环境,是用户接受测试,实际使用的场景。这个环境的主要目标是将产品或系统推送到用户使用。在UAT环境下,可能要考虑到更多的实际使用因素,比如产品的操作体验、使用效果、交互感受等。
    • test(test environment):测试环境,外部用户无法访问,专门给测试人员使用的,版本相对稳定。
    • pre(pre-production environment):灰度环境,外部用户可以访问,但是服务器配置相对低,其它和生产一样,外部用户可以访问,版本发布初期,正式版本发布前。
    • dev(development environment) : 开发环境,外部用户无法访问,开发人员使用,版本变动很大。
    • fat(feature acceptance test environment):功能验收测试环境,用于软件测试者测试使用。
    • sim(simulation environment):仿真环境,模拟实际环境中的各种因素和条件,以验证系统的性能和可靠性。

知识拓展

  • uat和sim的区别:UAT环境更注重实际使用效果,而SIM环境更注重系统内部的测试和验证

分支合并流程规范

业界常见的两大主分支(masterdevelop )、三个辅助分支(featurereleasehotfix)的生命周期:

以上生命周期仅作参考,不同开发团队可能有不同的规范,可自行灵活定义。

例如有的团队在开发时,会有以下的规定:

  1. develop 分支和 hotfix 分支,必须从 master 分支检出
  2. develop 分支需合并到 test 分支
  3. test 分支功能测试无误后,合并到 release 分支
  4. UAT 测试通过后,由 release 分支合并到 master分支
  5. 对于工作量小的功能开发(工时小于1天),可以直接在 devolop 分支进行开发;否则由 develop 分支检出 feature 分支进行开发,开发完后合并到develop 分支

提交信息规范

  • 提交信息规范化的作用

    • 提高可读性:使用规范化的提交信息可以使代码历史更容易理解。明确的描述可以使其他人更容易地理解代码的变更和原因;

      如果团队遵循相同的提交信息格式,那么所有代码库的提交历史都将具有一致性,这有助于保持代码库的整洁和一致性。

    • 有利于问题追踪:清晰的提交信息可以帮助开发人员快速定位和解决问题,因为它们提供了有关代码变更的上下文和原因;

    • 降低团队沟通成本:在团队协作中,规范化的提交信息有助于团队成员之间的沟通和协作。每个人都可以轻松地查看和理解代码变更,而无需依赖个人记忆或理解。

Angular提交规范

目前最受开发人员肯定的规范是前端框架Angular提出的Angular提交信息规范,Angular 的 Git Commit 准则可以遵循一些基本的规则和最佳实践,以确保代码的整洁和可读性。

  • Angular提交格式

    shell 复制代码
    <type>(<scope>): <subject>
    <BLANK LINE>
    <body>
    <BLANK LINE>
    <footer>
    • type:提交类型,表示本次提交属于哪一种类型,常见的提交类型如下所示

      • build:对构建系统或者外部依赖项进行了修改
      • ci:对CI配置文件或脚本进行了修改
      • docs:对文档进行了修改
      • feat:增加新的特征
      • fix:修复 bug
      • pref:提高性能的代码更改
      • refactor:既不是修复 bug 也不是添加特征的代码重构
      • style:不影响代码含义的修改,比如空格、格式化、缺失的分号等
      • test:增加确实的测试或者矫正已存在的测试
      • delete:删除功能或文件
      • modify:修改功能
      • chore:对构建过程或辅助工具和库(如文档)的更改
      • revert:回滚到上一个版本
    • scope(可选项):作用域,表示更改的范围,例如全局、部分功能、数据层、控制层、视图层等等,视项目不同而不同等

    • subject:主题,是一个简短的描述,用于概括此次提交的主要更改内容。通常应该包含关键词和主要变化点

      有以下准则:

      • 使用命令式,现在时态:"改变"不是"已改变"也不是"改变了"
      • 不要大写首字母
      • 不在末尾添加句号
    • body:主体,是详细的描述部分,也就是提交的正文描述信息,提供了对所提交更改的更详细的信息,包括更改的原因、具体步骤、结果等

      有以下准则:

      • 使用命令式、现在时态

      • 应该包含修改的动机以及和之前行为的对比

    • BLANK LINE:空行,用于进行分隔主体内容

    • footer(可选项):页脚,通常包含有关此次提交的其他信息,如提交人、提交时间、相关issue或PR号等

      常用取值如下:

      • BREAKING CHANGE:表示本次提交是不兼容修改,不兼容修改指的是本次提交修改了不兼容之前版本的 API 或者环境变量
      • Closes:表示本次提交目的是修改 issue,一般后面跟上 issue 的编号,表示成功解决了这个编号的 issue
      • revert:表示本次提交中包含了回滚内容
  • Angular Git Commit 准则的建议

    • 每个提交应该只包含一个相关的更改。
    • 使用有意义的 commit 描述,清晰地描述更改的内容和原因。
    • 使用英文编写 commit 描述,以提高可读性和理解度。
    • 使用主次信息格式,包括类型(feat、fix、docs、style、refactor、perf、test)、描述性标题和详细信息。
    • 使用短行,每行不超过 72 个字符。
    • 避免使用代词 "it",使用名词或动词来描述代码更改。
    • 在 commit 描述中包含 issue 或 PR 号,以便于追踪和合并更改。
    • 在 commit 消息中标记特性分支(feature),以区分不同特性的开发工作。

示例

shell 复制代码
feat(user): 添加用户登录功能

新增了用户登录功能,包括用户认证和权限控制。

BREAKING CHANGE: 修改了用户认证接口的返回格式

Closes #123

在这个示例中,提交类型为 feat(新功能),作用域为 user,描述了添加用户登录功能的修改。同时,还包含了详细的描述、BREAKING CHANGE (破坏性变更的说明)和 Closes #123都是 footer

注意事项

  • 提交注意事项

    • 提交问题必须为同一类别

    • 提交问题不要超过3个

      • 提交的commit发现不符合规范,①git commit --amend -m "新的提交信息"或② git reset --hard HEAD 重新提交一次

        ①讲暂存区中的提交合并到当前提交

        ②丢弃暂存区中的提交并切换到最新提交

        注意:②这个命令会永久性地删除暂存区的(也就是执行了add但是没有执行commit的内容)修改,所以在使用时要非常小心

  • 分支注意事项

    • master 分支的每一次更新,都建议打 tag 添加标签,通常为对应版本号,便于管理
    • feature分支、hotfix分支在合并后可以删除,避免分支过多管理混乱
  • 拉取注意事项

    • 每次编码前都先 pull 一下,有效防止远程库与本地库冲突导致无法提交,因为远程库代码可能发生了更新,但是我们本地库没有更新
    • 每次 pull 代码前,提交本地代码到本地库中,否则可能回出现合并代码出错,导致代码丢失

通用Git忽略文件配置

下面是一份通用的Git忽略文件配置,让我们提交的文件更加简洁、干净

properties 复制代码
HELP.md
target/
!.mvn/wrapper/maven-wrapper.jar
!**/src/main/**/target/
!**/src/test/**/target/

### STS ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache

### IntelliJ IDEA ###
.idea
*.iws
*.iml
*.ipr

### NetBeans ###
/nbproject/private/
/nbbuild/
/dist/
/nbdist/
/.nb-gradle/
build/
!**/src/main/**/build/
!**/src/test/**/build/

### VS Code ###
.vscode/

# Log file
*.log
/logs*

# BlueJ files
*.ctxt

# Mobile Tools for Java (J2ME)
.mtj.tmp/

# Package Files #
*.jar
*.war
*.ear
*.zip
*.tar.gz
*.rar
*.cmd

参考资料

相关推荐
喵喵先森15 分钟前
Git 的基本概念和使用方式
git·源代码管理
xianwu5432 小时前
反向代理模块
linux·开发语言·网络·git
binishuaio4 小时前
Java 第11天 (git版本控制器基础用法)
java·开发语言·git
会发光的猪。5 小时前
如何在vscode中安装git详细新手教程
前端·ide·git·vscode
stewie66 小时前
在IDEA中使用Git
java·git
晓理紫15 小时前
使用git lfs向huggingface提交较大的数据或者权重
git
我不是程序猿儿16 小时前
【GIT】sourceTree的“当前分支“,“合并分支“与“检出分支的区别
git
_OLi_1 天前
IDEA中新建与切换Git分支
java·spring boot·git
PyAIGCMaster1 天前
ubuntu下安装 git 及部署cosyvoice(1)
git
维__kxs76671 天前
小程序 + AI 自动直播:一部手机开启抖音挂载小程序流量主变现之旅
git·eclipse