Git提交规范及使用说明（简略笔记）_git提交规格

作者：代码创新者 | 2024-01-30 11:56:13

踩

git提交规格

一.Git提交规范

一次提交包含四个信息：

commit message - 提交的内容相关描述
author & committer - 作者及提交者
changed files - 修改的文件
hash & parent - 提交内容的hash及在提交树上的位置

1.提交信息

一般包括<header><body><footer>三部分。

<header>是必须的，一般在50个字符之内，其结构为：（其中<scope>可以不写）


<type>(<scope>): <short summary>
  │       │             │
  │       │             └─⫸ Summary in present tense. Not capitalized. No period at the end.
  │       │
  │       └─⫸ Commit Scope: animations|bazel|benchpress|common|compiler|compiler-cli|core...
  │
  └─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test

<type>表明本次提交的类型，一般有如下几种：

build: 涉及构建相关的改动
ci: 持续集成相关的改动
docs: 文档
feat: 新功能
fix: bug修复
perf: 性能相关改动
refactor: 重构相关（非bug、非新功能）
test: 测试相关，包括新增测试或者更改已有测试

<summary>使用现在时或祈使句。

<body>提交信息的更为详细的描述，与<header>一样也是用祈使句、现在时。<body>描述本次修改的动机，比如为什么引入本次改动，之前的逻辑是什么，现在的逻辑是什么，本次改动有哪些影响，等等。

最后,<footer>是可选项，一般涉及破坏性改动、功能的弃用等说明，以及对GitHub issue或Jira ticket的引用，PR的引用等。

1.1自动化校验

通过使用Git hooks达成目的。

想使用相关的Git Hooks，可以在目录.git/hooks创建对应的文件，文件名为prepare-commit-msg 及commit-msg，并赋予可执行权限。这样在我们进行git commit操作时，对应的脚本就会执行。

Git的提交不会包含.git目录，所以对应的hooks的改动并不会被提交到仓库中。我们可以在仓库根目录创建.githooks文件夹并将我们实现的代码放到该目录中，通过更改配置或者软连接的方式进行引用：

2 Author & Committer

3 Changed files

（此处复制教程原文）

提交前使用git diff查看文件的改动，使用git add添加期望进入提交的文件，使用git status查看文件状态，最终使用git commit进行提交
单次提交仅提交相关的改动，例如修复两个不同的bug应该使用两次独立的提交
鼓励经常性的提交，这样可以更快的分享实现的功能，并且减少代码丢失的风险
在主分支或者协作的功能分支不能提交半成品，提交之前需要进过测试
编译输出，日志，中间产物等，不要引入到提交中，使用.gitignore进行相关文件的排除，不同语言或者操作系统有一些通用的排除配置，参考github/gitignore
密码、授权凭证、密钥等，不要提交。如AWS的certificate.csv文件或内容， GCP的Service Account文件等，泄露到公开仓库会导致资源被不法分子使用，造成损失。同时由于Git的特性，想从历史提交中移除这类文件会较为困难，参考GitHub官方相关文档及描述
对于配置文件（如数据库连接信息等），一般使用配置模板，个人维护本地文件，且该文件在.gitignore 中配置。或者使用git update-index --[no-]assume-unchanged <file>来忽略某些文件的改动
其他一些常用命令（请在明确知道其含义后使用）
- git reset <file> - 移除被添加的文件（提交之前），reset命令的其他可以查看帮助文档
- git clean -f - 移除较多的未被追踪的中间文件
- git checkout <file> - 回退对某个文件的改动（提交之前）

4 Hash & Parent

在一些Git工作流模型中，使用git pull --rebase对本地提交进行更新
原则上禁止对主分支等进行git push -f操作，涉及需要回退的，使用git revert <commit>
涉及多分枝代码同步，可以使用git cherry-pick命令

二、Git使用说明

1 使用Github托管代码

1.2创建仓库

在git主页右上角点击+号，跳转表单。

注意：

github上的仓库一般都会包含readme文件，该readme文件会在项目页面进行展示
.gitignore文件可以用来忽略工作区的私有文件（例如本地配置、缓存文件、node_modules等）

点击绿色code按钮可获得项目地址，本地clone后即可开发，开发后push到仓库。

1.3 仓库界面介绍

1.star表示别人对项目的认可，最好别乱刷集赞式搜集star.

2.Fork操作可建立仓库副本，方便多人协作。

3.Watch操作可向邮箱推送信息。

4.Issues:Issues在Github官方文档中被翻译为议题，作用是针对仓库的内容进行讨论（例如bug反馈/新功能推荐）

5.Pull Requests：Pull Requests，简称PR，是github中将修改过的代码分支合并到目标分支的操作。前面git的学习中，我们都知道commit是git的最小工作单元，在github的仓库中，PR是主要的工作单元。很多同学刚刚接触GitHub时，对于Pull Requests很不理解：什么是拉取请求？在gitlab中，pr的操作叫做Merge Request，实际上大家可以把PR理解为“我修改好了你的代码，现在请求你把代码拉回主仓库中”

6.Action：Github Action 是GitHub推出的自动化构建工具，感兴趣的同学可以阅读文档

7.Projects：针对某一仓库的项目板（看板）

8.Wiki：存放一些介绍性的内容

9.Security：与安全相关，这里不做介绍

10.Insight：里面包含里项目的一些数据，包括代码贡献的时间分布图，每个人的贡献量等metric

11.discussion：vscode仓库中并没有开启discussion功能，这里展示一下wagtail社区的，该功能像一个真正的讨论区