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

参考资料

相关推荐
Smile丶凉轩3 小时前
微服务即时通讯系统的实现(服务端)----(1)
c++·git·微服务·github
和你一起去月球13 小时前
TypeScript - 函数(下)
javascript·git·typescript
我不是程序猿儿13 小时前
【GIT】TortoiseGit的变基(Rebase)操作
git
yyycqupt20 小时前
git使用(一)
git
Kkooe1 天前
GitLab|数据迁移
运维·服务器·git
Beekeeper&&P...1 天前
git bash是什么,git是什么,git中的暂存区是什么,git中的本地仓库是什么,git中工作目录指的是什么
开发语言·git·bash
Stara05111 天前
Git推送+拉去+uwsgi+Nginx服务器部署项目
git·python·mysql·nginx·gitee·github·uwsgi
lsswear1 天前
GIT 操作
git
勋勋勋勋小勋勋1 天前
git分支合并某一次提交
git