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

一.Git提交规范

一次提交包含四个信息：

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

1.提交信息

一般包括

三部分。

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

(): 
  │       │             │
  │       │             └─⫸ 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

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

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

使用现在时或祈使句。

提交信息的更为详细的描述，与

一样也是用祈使句、现在时。描述本次 修改的动机，比如为什么引入本次改动，之前的逻辑是什么，现在的逻辑是什么，本次改动有哪些影响，等等。

最后,

是可选项，一般涉及破坏性改动、功能的弃用等说明，以及对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 来忽略某些文件的改动
• 其他一些常用命令（请在明确知道其含义后使用）
  • git reset  - 移除被添加的文件（提交之前），reset命令的其他可以查看帮助文档
  • git clean -f - 移除较多的未被追踪的中间文件
  • git checkout  - 回退对某个文件的改动（提交之前）

4 Hash & Parent

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

 二、Git使用说明

1 使用Github托管代码

1.2创建仓库

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

注意：

1. github上的仓库一般都会包含readme文件，该readme文件会在项目页面进行展示
2. .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社区的，该功能像一个真正的讨论区

2 提交issue

vscode中可点击bug report.

3 提交PR

点击New pull request即可新建pr。

一些注意点和教程原文：

注意：不是所有的PR都会被合并，所以在提交PR前请先和maintainer进行沟通，并且在开发的过程中反馈进度，一种比较好的方式就是draft PR。

draft PR表示该PR还没有开发完，项目的maintainer不需要进行reveiw和merge，只需要简单看看代码是否符合预期。

小提示：在提交PR时，尽可能关联相关Issue，并说明你的代码解决了什么问题。

4 探索Github

1.Github explore

链接Explore GitHub · GitHub 

2.快捷键

ctrl/command+k可以直接进行搜索。

完整的快捷键见文档键盘快捷键 - GitHub Docs

3.高级搜索（如何使用？）

4.内置 IDE-CodeSpace

在你的仓库界面，输入英文状态下的 .，即可进入该项目的web editor，这实质上是一个云端的vscode，方便用户查找编辑代码。很可惜现在CodeSpace还不能支持在线运行代码，一些简单的修改可以配合Action使用。

5.Copilot

还在内测阶段，是代码补全工具，暂不做详细描述。

6.用户主页

7.用数据探索GItHub-GitHub API

Github对针对开发者提供了一系列API，详情见Developers - GitHub Docs 。

8.保持清醒和正义

5 国内其他代码托管平台简介

Gitee  Gitee - 基于 Git 的代码托管和研发协作平台

在Gitee创建仓库时，点击右上角点击导入即可导入其他平台的项目。