Git中的特殊文件

对于经常使用Git来进行版本控制的用户来说，接触最多的可能就是那几个核心的命令了。不过这篇文章的主要目的并不是研究命令，而是了解一些可能比较冷门的知识。

特殊文件

在Git中，有一些特殊的文件可以提交到仓库，这些文件对于项目的管理和开发非常有用。以下是一些主要的Git特殊文件:

.gitignore 文件：用于指定哪些文件和目录应该被Git忽略，不进行版本控制。通常在这个文件中列出一些临时文件、日志文件、编译产生的文件、敏感信息文件等，避免将它们包含到代码仓库中。
.gitattributes 文件：用于配置Git的文件属性，根据不同的文件类型，指定不同的行为。这些属性可以决定文件的换行符、文件编码，以及是否进行二进制合并等。这在处理跨平台开发时的换行符问题非常有用。不过如果项目团队是在同一个操作系统下开发，那么这个文件可能就没有什么必要。
.gitmodules 文件：用于管理Git仓库中的子模块。子模块是指一个独立的Git仓库，可以作为父项目的一部分。
.gitkeep 文件：用于保持Git的目录结构，即使目录中没有实际文件也可以提交到仓库中。在创建一个空的文件夹时，如果想要保持这个文件夹在Git中存在，可以添加一个名为.gitkeep的空文件。
.gitmessage 文件：用于自定义Git提交时的默认信息。当使用git commit命令进行提交时，如果没有提供自定义的提交信息，Git就会使用.gitmessage文件中的内容作为默认提交信息。

以上这些特殊文件其实在特定的应用场景下使用得会很频繁，只是大部分普通用户只需要一些基本的核心命令即可满足日常需求。这些特殊文件在项目的管理和开发中起到了重要的作用，尤其可以让团队更好的组织和管理项目。

提交规范

Git提交规范对于代码的可维护性和版本管理非常重要。常见的提交规范如下：

提交信息格式：
每个Git提交信息都应该包含一个清晰简洁的标题和一个更详细的描述。推荐的提交信息格式如下：
1
2
3
4
5
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
其中，<type>代表提交的类型，<scope>代表影响范围，<subject>是提交信息的简短描述，<body>是详细描述，<footer>是一些元数据，比如关联的issue、PR等。
提交类型：
每个类型值都表示了不同的含义，类型值必须是以下的其中一个：
- feat：提交新功能
- fix：修复了bug
- docs：只修改了文档
- style：调整代码格式，未修改代码逻辑（比如修改空格、格式化等不影响代码的正常运行）
- refactor：代码重构，不修复bug也不增加新功能
- perf：性能优化，提高性能而不影响正常功能的代码修改
- test：增加或修改代码测试功能
- chore：对构建流程或辅助工具和依赖库（如文档生成）的更改
代码回滚：
代码回滚比较特殊，若本次提交是为了恢复到之前的某个提交，那么提交信息必须是以revert:开头，后面跟上那个提交的完整标题。然后在信息正文中写上This reverts commit <hash>，其中的<hash>是要还原的那个提交的SHA值。
影响范围：
范围不是固定值，它可以是你提交代码实际影响到的任何内容。唯一需要注意的是它必须足够简短。当影响范围较大时也可以使用*来表示。
标题：
标题是对变更的简明描述，使用祈使句，现在时态，首字母不要大写，结尾不要加句号。
正文：
正文是对标题的补充，但它不是必须的。和标题一样，它也要求使用祈使句和现在时态。正文应该包含更详细的信息，如代码修改的目的，与修改前的代码对比等。
页脚：
任何Breaking Changes(破坏性变更，不向下兼容)都应该在页脚中进行说明，它经常也用来引用本次提交解决的Github Issue。Breaking Changes应该以BREAKING CHANGE:开头，然后紧跟一个空格或两个换行符。

以下给出一份提交信息的具体示例：

git commit -m "feat(login): add login functionality

This commit adds a new login functionality to the login module.Now, users can login to the application using their email and password.

Related issues: #123 #456"

看上去是这样，但实际上在终端这种特殊环境里，回车换行会导致命令直接被执行。实际写法可能是用$'...\n\n...'或者在每行结尾加上一个反斜杠\来实现换行和空行以满足固定的格式要求，那么后面就介绍直接使用git commit命令配合.gitmessage文件来规范提交。

使用.gitmessage规范提交模板

前面提到.gitmessage可以用于自定义Git提交时的默认信息，在使用git commit命令提交如果没有提供自定义的提交信息，Git就会使用.gitmessge文件中的内容作为默认提交信息。那么下面说明如何设置提交模板：

在项目目录中创建一个名为.gitmessage的文件

在.gitmessage文件中写入以下参考的提交模板

类型(必填): feat、fix、docs、style、refactor、perf、test、chore
影响范围(可选)：尽量简短
标题(必填): 尽量简短
正文：详细说明修改
页脚：关联的Issue号

特别注意
代码回滚请以revert:开头，并在正文指定回滚提交的SHA值
Breaking Changes请务必在页脚注明

保存文件并退出

设置.gitmessage文件为默认的提交模板，在父目录中执行以下命令

# 局部设置，影响单个仓库的所有分支
git config commit.template .gitmessage
# 全局设置，影响全部仓库
git config --global commit.template .gitmessage

之后，每次直接使用git commit命令将会自动显示该文件中的内容用于规范提交信息。效果如下

如果要撤销模板设置可以使用以下命令

# 撤销局部设置
git config --unset commit.template
# 撤销全局设置
git config --global --unset commit.template

.gitmessage相比直接在命令行里写提交信息主要有以下区别：

.gitmessage文件可以帮助你定义一个统一的提交信息模板，从而保证每次提交时的信息格式的一致性。这对于多人协作开发的项目来说非常有用，它可以帮助团队成员更好地理解每次提交的信息。
直接在命令行中写提交信息更加灵活，但是可能会导致提交信息的格式不一致，在多人协作项目中不利于提交信息的理解和共享。

总结

在广大的用户群体中，这些特殊文件和提交规范可能都不是特别关注的对象，实际上很多用户本身都不是团队开发成员，可能仅仅只是使用过Git的一个命令就不再去深入了解其他的内容。但是在一些特殊的应用场景中，对于Git深度用户来说这可能是很基础的内容。不过在很多时候，还是有人可能并不会严格根据规范来执行，毕竟规范的目的都是为了更好的理解，而规范本身的设计也并不一定完全合理。总之，选择一种最妥善的表达方式，提交规范可以提供一个不错的参考。

参考资料

Git 可以提交到仓库的所有特殊文件 | 极客笔记

Git提交规范 | 知乎

树下集熵

Git中的特殊文件

特殊文件

提交规范

使用.gitmessage规范提交模板

总结

参考资料