我们已经了解了 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 只擅长处理纯文本这种“木头”,
对于像 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)系统开始构建和测试,或者给团队的聊天群里发一条消息,告诉大家“某某某更新了代码”。通过组合使用这些钩子,你可以建立一个强大、自动化的工作流。客户端钩子帮助开发者在本地就发现问题,避免了提交被服务器拒绝的挫败感。服务器端钩子则作为最后一道防线,确保仓库里的代码永远整洁、合规。 这套机制让每个人都能在规则的守护下,自由且安心地创作。