Git使用规范指南

最新推荐文章于 2024-09-07 08:32:59 发布

知识汲取者

最新推荐文章于 2024-09-07 08:32:59 发布

阅读量543

点赞数

分类专栏：工具文章标签： git

该文章版权属于知识汲取者，未经允许请勿转载

本文链接：https://blog.csdn.net/qq_66345100/article/details/134237354

版权

工具专栏收录该内容

16 篇文章 13 订阅

订阅专栏

文章目录

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_module、feature/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环境更注重系统内部的测试和验证

分支合并流程规范

业界常见的两大主分支（master、develop）、三个辅助分支（feature、release、hotfix）的生命周期：

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

例如有的团队在开发时，会有以下的规定：

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

提交信息规范

提交信息规范化的作用
- 提高可读性：使用规范化的提交信息可以使代码历史更容易理解。明确的描述可以使其他人更容易地理解代码的变更和原因；
  
  如果团队遵循相同的提交信息格式，那么所有代码库的提交历史都将具有一致性，这有助于保持代码库的整洁和一致性。
- 有利于问题追踪：清晰的提交信息可以帮助开发人员快速定位和解决问题，因为它们提供了有关代码变更的上下文和原因；
- 降低团队沟通成本：在团队协作中，规范化的提交信息有助于团队成员之间的沟通和协作。每个人都可以轻松地查看和理解代码变更，而无需依赖个人记忆或理解。

Angular提交规范

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

Angular提交格式：
```
<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），以区分不同特性的开发工作。

示例：

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忽略文件配置，让我们提交的文件更加简洁、干净

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

参考资料

团队项目的 Git 分支管理规范-腾讯云开发者社区-腾讯云 (tencent.com)
大厂都在用的Git代码管理规范 - 知乎 (zhihu.com)
Commit message 和 Change log 编写指南 - 阮一峰的网络日志 (ruanyifeng.com)
Git commit规范（Angular） - 掘金 (juejin.cn)
Git Guide (zj-git-guide.readthedocs.io)
angular/CONTRIBUTING.md(github.com)