Datawhale学习笔记：faster git丨202401 task04

Datawhale学习笔记：faster git丨202401 task04

第七章 Git提交规范

Git 中的每一次提交（commit）都包含了丰富的信息，这些信息对于代码的版本控制和协作开发都非常重要。一次commit包括以下信息：

1. Commit Message（提交信息）:

2. Author & Committer（作者及提交者）:

3. Changed Files（修改的文件）:

4. Hash & Parent（提交内容的 Hash 及在提交树上的位置）:

7.1 Commit Message

• 这是关于此次提交内容的简短描述，用于快速了解此次变更的目的或解决了什么问题。
• 一个好的提交信息应该清晰、简洁，并能提供足够的信息来理解变更的内容和原因。

Commit Message描述的是当前提交内容的相关信息，一般包括header，body，footer。

7.1.1 Angular格式

Angular建议格式如下：

<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

• Commit Type（提交类型）：这是提交信息的第一个部分，用来说明提交的性质。常见的类型包括：

  • build: 涉及构建相关的改动
  • feat: 新功能（feature）
  • fix: 修补bug
  • docs: 文档更新
  • style: 代码风格（不影响代码逻辑的变动，如空格、格式化、分号等）
  • refactor: 重构（即不是新增功能，也不是修改bug的代码变动）
  • perf: 性能优化
  • test: 增加测试
  • chore: 构建过程或辅助工具的变动
  • ci: 持续集成配置文件的改动

• Commit Scope（提交范围）：可选的部分，用来指定提交影响的范围，通常是项目中的一个模块、子系统或组件。例如，在Angular项目中，这可能是common、compiler、core等。

• Short Summary（简短摘要）：这是提交信息的主体部分，应该是一个简短的、现在时态的句子，描述所做的更改。首字母不应该大写，结尾不加句号。

• body：是提交信息的更为详细的描述，与header一样也是用祈使句、现在时。

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

7.1.2示例

遵循Angular格式的提交信息示例：

feat(core): add new component for handling user preferences

• 在示例中，feat表示这是一个新功能，core表示这个功能影响的是项目的核心部分，而add new component for handling user preferences则是对这个功能的简短描述。*

完整的提交信息还可以包括一个更长的描述，在短摘要下方，进一步解释提交的背景、实现细节或测试情况等。这些信息通常放在提交信息的正文部分，位于短摘要之后，并缩进以区分标题和正文。例如：

feat(core): add new component for handling user preferences

This commit introduces a new component called UserPreferenceComponent. This
component is responsible for managing and updating user preferences in the
application. It provides an API for other components to interact with and
includes unit tests to verify its functionality.

7.1.3自动化效验commit message

为确保开发者遵守提交信息的规范，可以使用Git提供的Git Hooks对提交的信息进行校验。新初始化的git项目中，.git/hooks文件夹中有Git提供的官方样例。涉及提交相关的有：pre-commit、prepare-commit-msg、commit-msg、post-commit。

按官方文档的说法：所有示例都是作为 shell 脚本编写的，并加入了一些 Perl，但任何正确命名的可执行脚本都可以正常工作——你可以用 Ruby 或 Python 或任何你熟悉的语言编写它们。要启用挂钩脚本，请将一个文件放在目录的子目录中，该文件的名称正确（不带任何扩展名）并且是可执行的。

注意事项：

1. 编写程序，脚本第一行需要指定正确的解释器路径，如：使用python编写脚本，则第一行需要写#!/usr/bin/env python。
2. 正确命名文件（参照git提供的示例）。
3. 删除文件后缀（将.py、.sh、.sample等等后缀名全部删除）。
4. 给文件提供可执行权限，如：Linux系统中使用chmod +x指令。（windows系统中没有这一步貌似也行）

实践

• 按照教程，成功使用hooks完成提交格式规范，Git输出结果如下所示：

awa@cbye MINGW64 /f/myproject/newtest/gitstudy (master)
$ git commit
prepare-commit-msg: File: .git/COMMIT_EDITMSG
Type:
Hash:
commit-msg: File: .git/COMMIT_EDITMSG
<header>: docs(common):git hooks test
commit message does not meet spec

awa@cbye MINGW64 /f/myproject/newtest/gitstudy (master)
$ git commit
prepare-commit-msg: File: .git/COMMIT_EDITMSG
Type:
Hash:
commit-msg: File: .git/COMMIT_EDITMSG
<header>: docs(common): test hooks
[master bb528ca] docs(common): test hooks
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 hooks_test.txt

• gitee仓库中内容如下：
  

7.2 Author & Committer

• Author 是指编写代码并进行提交的人。
• Committer 是指将代码提交到仓库的人，有时可能与 Author 是同一人，但在某些情况下（如使用 Git Patch 或 Cherry-pick）可能是不同的人。
• 这两个信息在多人协作的项目中尤其重要，可以帮助追踪代码的修改历史和责任人。

配置邮箱以及用户名方法：

# 全局默认配置
git config --global user.email "<github email>"
git config --global user.name "<github username>"
# 局部仓库设置
git config user.email "<enterprise email>"
git config user.name "<real name>"

7.3 Changed files

• 提交时，Git 会记录此次变更涉及到的所有文件，包括新增、修改、删除等。
• 通过查看修改的文件，可以快速了解此次提交影响的范围和具体内容。

7.4 Hash & Parent

• 每一个 Git 提交都会生成一个唯一的 Hash 值，用于标识这次提交。
• 这个 Hash 值是基于提交内容（包括提交信息、作者信息、修改的文件等）计算出来的，任何微小的变化都会导致生成不同的 Hash 值。
• Parent 是指当前提交之前的上一次提交，通过 Parent 可以追踪提交的线性历史。在分支合并时，可能会出现多个 Parent，形成提交图的结构。

1. 使用 git rebase -i <commit> 整理提交：

   • 在开发过程中，经常会产生多个小提交。在将这些提交合并到主分支之前，可能希望整理这些提交，使提交历史更加清晰。
   • git rebase -i <commit> 允许交互式地重放提交。可以合并多个提交、修改提交信息、或者完全删除某些提交。
   • 如果已经将这些提交推送到远程仓库，使用 git push -f（强制推送）可以覆盖远程仓库的历史。但强制推送是一种危险的操作，因为它会改变远程仓库的历史。通常，这只应该在个人开发分支上执行，并且需要确保没有其他人正在该分支上工作。

2. 使用 git pull --rebase 更新本地提交：

   • 当你在本地进行开发时，其他人可能已经向远程仓库推送了新的提交。为了将这些新提交合并到你的本地分支，并保持提交历史的线性，你可以使用 git pull --rebase。
   • 这个命令会先获取远程仓库的最新提交，然后取消你的本地提交，将它们重新应用到最新提交之上。

3. 使用 git revert <commit> 回退提交：

   • 如果不小心提交了一些不应该提交的内容，或者某个提交引入了错误，可能想要回退这个提交。
   • git revert <commit> 会创建一个新的提交，这个提交的内容与指定提交的内容相反，从而有效地撤销了该提交所做的更改。
   • 与 git reset 不同，git revert 不会改变提交历史，而是添加了一个新的提交来撤销更改。

4. 使用 git cherry-pick 同步多分支代码：

   • 当想要从一个分支获取某个特定的提交，并将其应用到另一个分支时，可以使用 git cherry-pick。
   • 这个命令会创建一个新的提交，内容与指定提交相同，但提交哈希值和父提交信息会有所不同。

第八章 Github与Gitee

GitHub和Gitee都是代码托管平台，虽然在地域性、开放性以及用户群体方面有所不同，但都值得尝试。这两个平台在细节上存在差异，但功能大体上区别不大。使用时，主要围绕仓库创建、提交issue、提交pr等方面。此外，还有Explore 、GitHunt 等网站值得探索……