个性化你的工作流

我们已经了解了 Git 的基本操作，就像学会了如何使用一套功能强大的工具。但真正的大师不仅会使用工具，还会改造工具，让它们用起来更顺手。 这一部分，我们就来探索如何将 Git 调教成最适合你、你的团队、你的项目的样子。

装修你的 Git “工作室”

把 Git 想象成你的数字工作室。刚入驻时，它是“毛坯房”，你需要做的第一件事就是进行基础装修，让它变得舒适又高效。这一切都离不开 git config 这个命令。 还记得吗？我们最开始就用它设置了你的名字和邮箱，这相当于在工作室门口挂上了你的名牌。

|
git config --global user.name "你的大名"
git config --global user.email "你的邮箱"

但它的能耐远不止于此。假设一家大公司颁布了全公司范围的规定，这就是系统配置（system），它对这台电脑上的所有用户和所有项目都生效。 接着，你作为一名开发者，有自己的工作习惯，你为自己设定了一些个人偏好，这就是全局配置（global），它只影响你自己的所有项目。 最后，当你参与一个特定项目时，这个项目本身可能有一些特殊要求，比如代码风格，这些写在项目内部的规定就是本地配置（local）。

这三个层次的优先级就像是：项目的特殊要求 > 你的个人习惯 > 公司的通用规定。离你越近的配置，权力越大。

除了设置身份，你还可以定义许多细节。比如，你习惯用 VS Code 而不是默认的 Vim 来写提交信息，可以告诉 Git：

|
git config --global core.editor "code --wait"

你甚至可以为团队设定一个标准的提交信息模板，比如要求每个提交都关联一个任务编号。只需创建一个模板文件，然后告诉 Git 它的位置，之后每次提交，Git 都会为你预填好格式，再也不怕忘记团队规范了。

|
git config --global commit.template ~/.gitmessage.txt

如果你觉得 Git 自动帮你分页显示长长的日志（git log）很烦人，想一口气看完所有内容，也可以关掉它。

|
git config --global core.pager ''

教会 Git 处理“特殊材料”

在任何一个项目中，文件都形形色色，就像工匠手里的材料，有木头、有金属、还有一些从没见过的合成材料。默认情况下，Git 只擅长处理纯文本这种“木头”， 对于像 Word 文档、图片、编译好的程序这类“特殊材料”，它往往束手无策。这时，我们就需要 .gitattributes 文件，它像一本“特殊材料处理手册”，你可以把这本手册放在项目里，告诉 Git 如何聪明地应对这些文件。

一个常见的问题是，如何处理不同操作系统带来的“换行符”差异？Windows 用 CRLF（回车+换行）作为一行的结束，而 macOS 和 Linux 则用 LF（换行）。这就像团队里有人说方言，有人说普通话，若不统一，沟通就会出问题， 导致文件内容明明没变，Git 却认为整个文件都被修改了。

通过 core.autocrlf 配置，我们可以立下一个规矩。如果你在 Windows 上工作，可以设置为 true，Git 会在你签出代码时，贴心地把 LF 转换成 CRLF；在你提交代码时，又把它转换回 LF 存入仓库。这保证了仓库里的“官方语言”永远是统一的 LF。

|
git config --global core.autocrlf true

如果你在 macOS 或 Linux 上，可以设置为 input，这样 Git 会在你提交时，将意外混入的 CRLF “纠正”为 LF，但签出时则保持原样。

另一个更强大的功能是，让 Git 拥有“火眼金睛”，能够“看透”二进制文件的内容。比如，你想知道一个 Word 文档（.docx）两个版本之间到底改了什么，或者一张图片（.png）的尺寸有没有变化。 正常情况下，git diff 只会告诉你“这两个二进制文件不一様”，这简直是废话。但通过 .gitattributes 和自定义的转换器，我们可以赋予 Git 超能力。

首先，在 .gitattributes 文件里写上一行：

|
*.docx diff=word

这行代码的意思是：所有 .docx 文件在做比较（diff）时，请使用名叫 word 的“滤镜”。 然后，你需要定义这个 word 滤镜是什么。我们可以配置 Git，让它在比较前，先用一个像 docx2txt 这样的小工具把 Word 文档转换成纯文本。这样一来，git diff 就能清晰地告诉你，是哪句话、哪个词被修改了。

同样的方法也适用于图片，我们可以让 Git 去比较图片的 EXIF 元数据（比如尺寸、创建日期等），而不是比较像素本身。

打造你的自动化“小助手”

当你的工作流越来越成熟，你会发现有些事总是重复在做：提交前运行测试、检查代码风格、推送后通知团队成员……这时，就该 Git Hooks 出场了。

Git Hooks 是一些“魔法脚本”，它们潜伏在你的 .git/hooks 目录里，在特定的事件发生时（比如 commit、push），它们就会被自动触发。你可以用任何你喜欢的语言来编写这些脚本。

这些钩子分为两大类，一类是客户端钩子（Client-Side Hooks），例如：

• pre-commit（提交前）：这是最常用的钩子之一。在你输入提交信息之前，它会运行。你可以让它检查代码风格是否符合规范，或者有没有忘记加注释。如果脚本检查不通过，它就会阻止这次提交，就像一个贴心的助理在你犯错前拉住你。
• commit-msg（提交信息时）：这个钩子用来检查你写的提交信息是否符合团队规范。比如，前面提到的“必须包含任务编号”，就可以用这个钩子来强制执行。
• post-commit（提交后）：在你完成一次提交后触发。通常用来做一些通知类的工作，比如自动更新文档的版本号。

另一类是服务器端钩子（Server-Side Hooks），例如：

• pre-receive（推送前）：当有人向服务器推送代码时，这个钩子最先被触发。它会检查所有被推送的提交。你可以用它来执行最核心的策略，比如“提交信息必须符合格式”、“只有特定的人才能修改特定目录”。如果规则不通过，整个推送都会被拒绝。
• post-receive（推送后）：在一次成功的推送完成后触发。它可以用来通知持续集成（CI）系统开始构建和测试，或者给团队的聊天群里发一条消息，告诉大家“某某某更新了代码”。

通过组合使用这些钩子，你可以建立一个强大、自动化的工作流。客户端钩子帮助开发者在本地就发现问题，避免了提交被服务器拒绝的挫败感。服务器端钩子则作为最后一道防线，确保仓库里的代码永远整洁、合规。 这套机制让每个人都能在规则的守护下，自由且安心地创作。