1. Git 代码存储位置先看清三个区域和 .git 的内容1.1 工作区、暂存区、版本库Git 的三层结构不少刚接触 Git 的人会把“代码存在哪”理解成一个很朴素的问题代码要么在我电脑上要么在远程服务器上。真到了排查问题的时候这套认知完全不够用。先说个最典型的场景你在编辑器里改了一行代码git status能看到变化但电脑突然断电这个改动可能就没了可如果你执行过git add哪怕没git commit改动也已经被 Git“接住”了。同样是没提交区别就在“暂存区”这一层。我把 Git 的存储模型拆成三层理解起来会清楚很多工作区Working Directory就是你打开文件夹看到的那一堆文件IDE 里改的就是这里。暂存区Staging Area / Index可以理解成“待提交清单”位于.git/index文件里记录了下一次提交要包含哪些文件的快照信息。版本库Repository.git目录本身commit 之后的对象都存在这里。用个生活化的类比工作区是你办公桌上的文件暂存区是装进快递盒并贴好面单的那批货版本库是已经扫码入库、存进货架的档案。桌面乱了没关系入了库才算是“正式记录”。git add干的事就是“拍照快照 放进待提交区”git commit才是“正式封箱归档”。这里有个非常关键但对新手很不友好的点git add并不只是“标记一下这个文件要提交”而是把当前工作区里的文件内容压缩后生成了一个 Git 内部对象并写入.git/objects里去了。所以哪怕你 add 之后又把文件改了暂存区里保存的仍然是 add 那一刻的内容。这也是为什么git add之后文件丢失不算彻底丢而没 add 过的文件一旦工作区损坏就真的找不回来。1.2 .git 目录里到底存了什么我见过不少开发者用了两三年 Git打开.git目录看一眼就发怵然后又默默关掉。其实里面东西没那么多核心就几个部分。.git顶层一般有这些objects/Git 的“数据库”所有提交内容最终都变成对象存在这里。对象分四种commit提交、tree目录树、blob文件内容、tag标签。refs/引用目录heads/存本地分支tags/存标签remotes/存远程分支引用。HEAD一个指针文件内容通常是一行ref: refs/heads/main表示当前处于哪个分支。index暂存区文件本身二进制格式里面记录了暂存的文件路径、对象哈希、权限位等信息。config仓库级配置文件和全局的~/.gitconfig分开生效。hooks/Git 钩子脚本目录。logs/HEAD 和分支的变更历史reflog这是用来“后悔”的关键数据。COMMIT_EDITMSG最近一次提交的说明信息暂存文件。绝大多数人第一次想搞清楚代码在哪都会被objects/里的内容搞懵里面全是两位十六进制命名的子目录子目录里的文件名又是 38 位十六进制字符。合起来就是一个 40 位 SHA-1 哈希值这也是 Git 中对象的名字。理解这层结构会有个好处你会知道 Git 本质是个“内容寻址文件系统”而不是一个简单的“版本记录本”。哈希按内容计算内容相同则哈希相同因此同一文件的多个版本可以复用同一个 blob 对象不会因为每次提交都复制一份文件导致仓库无限膨胀。1.3 一次 commit 的对象链结构为了真正理解“提交”在 Git 里是什么我建议用git cat-file把对象链剖开看。比如执行git log --oneline拿到最新提交的哈希再执行git cat-file -p 哈希会看到一个 commit 对象的内容大致长这样tree 8f7a10f2d3f1b7e3e4f12ab3c34cd45e67f890ab parent 3c4d557f9f0d1c2d3e4f5a6b7c8d9e0f1a2b3c4d author Zhang San zhangsanexample.com 1700000000 0800 committer Zhang San zhangsanexample.com 1700000000 0800 fix: correct checkout path for Windowstree字段指向这个提交的根目录树对象再顺着 tree 对象的哈希继续git cat-file -p能看到一层目录里有哪些文件和子目录、对应的 blob 哈希和权限位。blob 对象里存的是文件内容的真正字节。这链条其实揭示了一个很重要的概念commit 对象本身不直接持有文件内容而是持有“指向一棵树的指针”每次提交相当于给整个项目目录拍了一张“结构快照”但内部对象因为内容寻址可以大量复用旧有的 blob。这种设计让 Git 的“每次提交都是完整快照”和“存储却很省空间”得以同时成立。同时注意author和committer两个字段常规提交时两者相同但在 cherry-pick、rebase、amend 等操作后会不一样。如果你需要在跨平台协作时排查“某行代码到底是谁引入的”这两个字段都会派上用场。2. 不同平台的存储差异文件系统比你想的更有个性2.1 三大平台的“存储脾气”各不相同Git 是跨平台的但操作系统不是。代码一旦落到本地文件系统就会被不同平台各自的规则“加工”一遍。这不是 Git 的问题而是文件系统层面的差异Git 只能尽量去适配。我整理了三个最常见平台的实时特点Windows 的 NTFS 对大小写不敏感默认配置下Foo.js和foo.js会被视作同一个文件没有 Unix 那种“执行权限位”的概念路径分隔符用反斜杠\macOS 的 APFS 默认对大小写不敏感虽然它支持区分大小写的格式但绝大多数人出厂没开有执行权限位路径分隔符用的是正斜杠/Linux 的 ext4、xfs 等文件系统对大小写敏感有完整的执行权限位路径分隔符是正斜杠/。这就引出了两个非常容易踩的坑一个是文件名大小写另一个是文件权限。两个坑都需要单独展开说。除此之外还有个小细节是路径分隔符。Git 内部统一用/存储路径Windows 上的\是给本地 API 用的。团队如果有成员在脚本或代码里硬编码了C:\Users\...这种路径拿到 Linux 上必然跑不起来。这类问题不算 Git 的职责但跨平台协作时几乎天天见值得在提交前检查一下。2.2 大小写敏感性本地没问题一到 Linux 就翻车大小写问题是最难排查的一类问题。原因很简单你在 Windows 或 macOS 的默认文件系统上根本“感觉不到”它的存在直到某个环节换到 Linux 上才突然爆出来。比如团队里有人不小心在仓库里同时提交了一个Readme.md和README.md在 macOS 本地上git status干干净净因为文件系统把它俩当成同一个文件——后写入的覆盖了先写入的。可一旦 CI 机器或生产服务器是 Linuxgit checkout时 Git 会把这两个文件都真实地创建出来这时候构建脚本只认README.md而某些代码里引用的是Readme.md轻则报错重则打包产物缺文件。Git 由于自身内部记录路径时是严格区分大小写的为了兼容 Windows/macOS 这种“不敏感”的文件系统就引入了core.ignorecase配置项。当 Git 探测到当前仓库所在文件系统不区分大小写时会自动把这个配置置为true。它干的事是让 Git 在状态比对、分支切换时尽量把“仅大小写不同”的文件当作同一个文件处理免得误判成“新增/删除”造成混乱。但这只是妥协并不解决问题。如果你在 mac 或 Windows 上发现仓库里可能存在“仅大小写不同”的文件可以用这条命令把整个提交树里的小写文件名列出来比对git ls-tree -r HEAD | awk {print $4} | sort -f | uniq -di如果输出里有重复项说明仓库里已经存在大小写冲突的文件了。修复思路是删掉其中一个把引用处统一后重新提交。只修改文件名大小写的标准做法是git mv -f Readme.md README.md如果这条命令因为文件系统“看不见目标文件”而失败可以分两步走先改成临时名再改最终名或者直接从工作区手动改名后git add -A重新暂存。反正思路只有一个让 Git 的暂存区记录到文件名变化而不是依赖文件系统替你判断。2.3 文件权限位Windows 提交脚本时的隐形炸弹在 Linux 和 macOS 上一个文件是否“可执行”由权限位决定常见的就是100644普通文件读写权限和100755可执行文件。Git 在存储 tree 对象时会把每个 blob 对应的模式记录进去。但在 Windows 的 NTFS 文件系统上压根没有 Unix 权限位的概念所以你没法对一个文件执行chmod x。后果在团队协作里非常明显某同学 Windows 上写了一个deploy.sh提交后 push 到远端Linux 服务器上git pull下来执行时直接报Permission denied。因为这个文件在仓库里的模式是100644不是100755Linux 不会把它当作可执行文件。这个坑在容器化、CI/CD 普及之后尤其常见。因为脚本一般不在本地 Windows 环境跑而是在 Linux 构建机或服务器上跑。等你发现跑不起来再去排查至少浪费一轮“提交→推送→拉取→执行”的时间。Git 本身对权限是敏感的在 Linux/macOS 上如果文件权限发生变化git status会提示 modified。比如mode change 100644 100755 deploy.sh如果你确认权限变化是刻意为之提交即可。如果你根本不想让 Git 跟踪权限变化可以把core.filemode设为falsegit config core.filemode falseWindows 上因为文件系统没有权限位Git 一般会自动把这个值设为false。但要注意如果仓库里的脚本本身就缺执行权限光改本地配置没用你得在仓库里把权限修正过来。正确做法是在能运行chmod的平台Linux/macOS上执行chmod x deploy.sh git add deploy.sh或者在不方便起 shell 的情况下用git update-index --chmodx deploy.sh git commit -m fix: mark deploy.sh as executable提交前我还习惯用git ls-files -s看一下当前暂存区里的文件模式确保脚本类文件是100755。这个习惯在 Windows 环境下特别值钱因为你本地根本看不到权限位全凭这一步检查兜底。3. 提交差异的核心CRLF、LF 与文本规范化3.1 行尾符号的历史原因聊跨平台提交差异绕不开行尾符号。先明确两个名词CR\r是“回车”把光标移回行首LF\n是“换行”把光标移到下一行。历史原因是教科书级别的早期电传打字机Teletype时代换行需要“回车”和“换行”两个动作配合。后来 Unix 开发者简化标准只保留了 LF 一种字符而 DOS/Windows 沿用了 CP/M 时代的习惯用 CRLF 表示一行结束再后来 macOS 从经典 Mac OS 转向基于 Unix 的 Darwin 内核后也回归了 LF。于是到今天三大平台在“换行怎么表示”这个问题上始终没统一。看起来这只是“多了一个隐藏字符”的小事但放进 Git 的 diff 和合并不分家的工作流里就成了最伤人的问题。最典型的症状是你的编辑器“看起来”没改任何东西但git diff显示整个文件每一行都被删了又加了。原因就是行尾符号全变了Git 把 CRLF 和 LF 当成不同的字符来比较。3.2 Git 的行尾转换机制autocrlf 与 safecrlfGit 为了解决跨平台行尾问题提供了行尾自动转换的机制核心配置项是core.autocrlf。它有三种取值truecheckout 时把仓库里的 LF 转成 CRLF 输出到工作区commit 时把工作区里的 CRLF 转回 LF 再入库。这是 Windows 环境的经典建议。inputcommit 时仍然把 CRLF 转成 LF 入库但 checkout 时不转换。工作区保持文件原本的行尾。false完全不转换仓库里存什么工作区就长什么样。我再说得直白一点不管你在 Windows 上把 autocrlf 设成哪种值只要不是falseGit 在把文件收进 objects 之前都会尝试把行尾统一成 LF。这正是跨平台协作时保证“仓库内统一”的关键。如果配置得当Windows 用户本地编辑文件看到的是 CRLF提交到仓库后变成 LFLinux 用户拉下来看到的是 LF提交后还是 LF。git diff自然就不会因为行尾差异而把整份文件标红。core.safecrlf则是安全开关。开启后Git 会在转换前先模拟一次“转换后再转回来比较”如果发现内容不一致常见于二进制文件中刚好出现 CRLF 字节序列会拒绝该次 add 或给出警告。在 Windows 上我建议设置成git config --global core.safecrlf true能让很多“文件被莫名改坏”的问题在提交前就爆出来。但 autocrlf 有个致命局限它是环境级配置不随仓库走。新成员加入团队后如果没配行尾照样会乱。这个问题必须靠.gitattributes来解决。3.3 用 .gitattributes 做仓库级统一.gitattributes是放在仓库根目录的文本文件作用是把“文本规范化”策略绑定到仓库本身而非某个开发者的机器。凡是提交到仓库的文件Git 会优先参考这个文件里的规则。先给一份我常用的模板# 默认对所有文本文件启用自动行尾规范化 * textauto # 明确要求某些文件固定用 LF *.sh text eollf *.ps1 text eolcrlf *.bat text eolcrlf *.cmd text eolcrlf Makefile text eollf Dockerfile text eollf # 明确标记二进制文件禁止做任何行尾转换和文本 diff *.png binary *.jpg binary *.jpeg binary *.gif binary *.ico binary *.pdf binary *.zip binary *.tar.gz binary *.exe binary *.dll binary *.so binary解释一下几行关键指令textauto让 Git 自动判断文件是否为文本。文本文件入库时统一转 LF检出时按平台习惯转回本地行尾。text eollf强制该类型文件在仓库和工作区都使用 LF。脚本文件必须这样配因为 Linux 上 CRLF 可能导致#!/bin/bash这种 shebang 解析失败。text eolcrlf强制使用 CRLF。批处理类文件保留这个选项主要是为了兼容老的 cmd 工具链。binary等价于-text -diff明确告诉 Git 别动它。关键点来了.gitattributes的优先级高于core.autocrlf。哪怕你在 Windows 上设了autocrlftrue只要仓库里定义了某个文件的eollfGit 就会按.gitattributes的指令走。但是很多人加了.gitattributes就以为完事了其实不对。文件的规范化在“下一次入库”时才生效仓库里已经存在的历史文件并不会自动改变。所以要补一步强制重新规范化git add --renormalize . git commit -m chore: normalize line endings via gitattributes执行完这一步后可以用git ls-files --eol查看每个文件的三种行尾状态工作区、暂存区、仓库确认仓库里存的是不是lf。这里有个容易翻车的细节如果仓库原本是“大杂烩”执行git add --renormalize .之后 diff 会非常壮观几乎每个文件都被判为修改。这是正常的因为文件的 blob 哈希变了。这个提交必须作为一次独立 chore 提交并且要快速通知团队拉取后本地工作区可能出现大面积“看起来被修改”的文件重新 checkout 一次即可git checkout .4. 跨平台提交的完整实操配置4.1 Windows 环境下的推荐配置如果你以 Windows 为主要开发环境并且参与的是跨平台仓库我的建议是不要裸用默认配置。至少做三件事第一设置core.autocrlf为true。这样在你git add时会把工作区 CRLF 转成 LF 入库git checkout时再把 LF 转回 CRLF 到工作区本地编辑器看到的还是 Windows 习惯的换行仓库里存的却是统一的行尾。第二如果仓库里已经有.gitattributes建议把core.autocrlf显式设为一个值别让安装向导替你随便选。通常有.gitattributes的仓库设成true也没问题因为 attributes 规则优先但如果你的仓库非常老、没有 attributes又希望完全不要本地转换可以设false。这个选择完全取决于项目是否已经做了仓库级规范化。第三把默认提交信息格式统一一下。Windows 的 CMD 对引号处理很原始PowerShell 对单双引号又有自己的一套逻辑。如果你习惯用git commit -m fix: something建议强制自己用双引号如果提交信息里有中文注意终端编码要切到 UTF-8。命令汇总git config --global core.autocrlf true git config --global core.safecrlf true git config --global core.filemode false git config --global core.ignorecase true另外 Windows 上我基本都推荐用 Git Bash 或者 Windows Terminal WSL 来跑 Git 操作而不是去 CMD 里折腾。原因不是 CMD 不能用而是引号转义、路径分隔符、换行规则都和 Linux 差异太大会徒增跨平台心智负担。4.2 macOS 与 Linux 环境下的推荐配置macOS 和 Linux 本质都是 Unix 系配置逻辑很接近。仓库内统一用 LF工作区也没必要转 CRLF所以core.autocrlf设成input或false都行。区别在于input会在提交时把工作区意外出现的 CRLF 转成 LF多一层保护false则是完全不处理。推荐配置git config --global core.autocrlf input git config --global core.safecrlf true git config --global core.filemode truecore.filemode这里设为true是因为 Unix 平台有权限位需要跟踪。但要注意一个特例如果你的项目仓库放在 Windows 共享目录、SMB 挂载盘或者某些网盘同步目录里文件系统不支持权限位Git 会误报大量 mode change。这种情况下不要全局硬改而是在对应仓库里临时设git config core.filemode falsemacOS 还有一个特殊点默认 APFS 对大小写不敏感所以core.ignorecase大概率会被自动探测为true。如果你想要更接近 Linux 的敏感行为可以考虑把仓库单独放在一个“区分大小写”的磁盘镜像或卷宗里但这个操作对绝大多数团队来说过于激进。日常工作中只要做到“文件名规范统一、成员自觉遵守”依靠 CI 在 Linux 上跑一遍检查就够了。4.3 新仓库的第一笔提交标准化配置我在多个团队里面发现一个现象很多仓库的.gitattributes是在出问题之后才补的补的时候仓库已经有几百个文件要重新规范化还得发公告、让大家重新 checkout相当折腾。更稳的做法是新仓库初始化后第一笔提交就带上这些规则。步骤我一般这么走git init之后先创建.gitattributes、.editorconfig、.gitignore。创建初始文件比如 README、LICENSE并用合适的分行符保存。执行git add --renormalize .其实新仓库没历史文件直接git add .就行但习惯先执行这步能帮你在第一步就验证规则有没有写错。git commit -m chore: init repository with gitattributes and editorconfig。.editorconfig是配合项它管的是“编辑器怎么处理文件”比如强制 UTF-8、末尾插空行、去掉行尾空白。虽然它不参与 Git 的存储逻辑但有了它团队里成员的 IDE 默认行为才和 Git 的存储策略对齐。一份常用的.editorconfigroot true [*] charset utf-8 end_of_line lf insert_final_newline true trim_trailing_whitespace true [*.{bat,cmd,ps1}] end_of_line crlf编辑器会在你打开和保存文件时按这里的规则工作。和.gitattributes一个管“编辑行为”一个管“Git 存储行为”配合起来跨平台提交差异能消灭一多半。4.4 团队提交的动作规范光有配置文件还不够团队里还得约定一些基本动作否则再好的规则也会被绕过去。我建议的提交流程是改代码前先确认当前分支和远端同步git pull --rebase。改完后先用git diff --check检查空白符错误比如行尾空格、末尾缺换行。git add后立即看一眼暂存区内容git diff --cached --stat。提交信息遵循统一规范比如fix: / feat: / chore: / docs:。推送前再git pull --rebase一次保证本地提交不产生多余的 merge commit。其中第二步很多人会略过但它其实是踩坑大户。git diff --check能看到error: trailing whitespace at EOF error: trailing whitespace in 1 line这类问题在跨平台协作里特别容易混进行尾转换的提交里混进去之后后续git blame定位代码来源时就会非常痛苦。另外如果团队用 CI建议在流水线里加一步“行尾和可执行权限检查”比如列出仓库里模式为100644的.sh文件并直接判失败倒逼提交者修正。5. 常见问题与排查技巧实录5.1 文件里的 ^M 到底怎么来的很多人在 Linux 或 macOS 上打开仓库里的文件发现每行结尾多了一个^M或者用cat看时行尾变成\r。这个问题的直接原因是文件里的行尾原本是 CRLF而你当前环境没有做转换。排查分三步走file src/index.js输出里带CRLF line terminators就说明文件是 CRLF 行尾。再进一步确认cat -A src/index.js你会看到行尾以^M$形式出现。最后看 Git 眼里这个文件的行尾状态git ls-files --eol src/index.js它会告诉你工作区w、暂存区i、仓库r三个位置分别是什么行尾。如果仓库r已经是lf工作区还是crlf说明只是本地 checkout 转换的问题如果仓库r就是crlf说明当初提交时没做转换需要重新规范化。解决办法分两种。仓库还没做统一规范化时先修正当前文件dos2unix src/index.js git add src/index.js git commit -m fix: convert line endings to LF如果仓库里存在大量此类文件那就回到上一节的方法加.gitattributesgit add --renormalize .一次性解决。5.2 diff 显示整个文件都被改动的真相这是跨平台协作里最常见的“灵异事件”明明只改了一行代码git diff却显示每一行都被删除又重新添加。遇到这种事先别急着怀疑人生九成九是行尾变化。这时可以立即执行一个忽略空白差异的比较命令git diff -w如果-w之后改动只剩真正的那一行基本能断定是行尾或者空白字符问题。接下来用git diff --stat看波及文件数量如果是大面积文件全部被改那往往是仓库级 autocrlf 配置变了或者有人在没有.gitattributes的情况下用另一种行尾提交了文件。处理建议不要试图人肉去把每个文件改回原样那样只会让仓库更乱。先补好.gitattributes和.editorconfig。执行git add --renormalize .再做一次独立提交。提交之后你可能会发现历史提交里的 diff 仍然显示得很难看那是历史不影响后续开发不用纠结。真正重要的是从这次提交开始仓库里的行尾是干净的。5.3 跨平台提交问题速查表现象主要原因快速排查命令解决方案打开文件出现^M仓库里存的或工作区里用的是 CRLFfile 文件、cat -A 文件dos2unix转换后重新提交或整体git add --renormalizegit diff整份文件标红行尾符号从 LF 变成 CRLF 或反之git diff -w验证统一.gitattributes EditorConfig重新规范化提示LF will be replaced by CRLFautocrlf 正在按配置转换git config core.autocrlf确认项目规范化策略后再决定是否保留当前配置脚本拉到服务器后无法执行文件在仓库中的模式是100644git ls-files -s 脚本git update-index --chmodx 脚本后提交出现mode change 100644 100755Unix 平台权限位变化被 Git 记录git diff查看确认是预期变化后提交不需要则git config core.filemode false仓库存在foo.js和Foo.js本地只能看到其中一个文件系统大小写不敏感Git 层有冲突文件git ls-tree -r HEAD | sort -f | uniq -di删除/重命名其中一个并统一引用提交信息乱码或换行不对终端编码或 shell 的引号规则差异git log -1 --format%BWindows 下建议用 Git Bash提交信息统一双引号仓库使用 UTF-8拉取后工作区大面积显示 modifiedcheckout 转换规则变了或历史行尾很乱git status、file 文件git checkout .重新检出必要时git add --renormalize一次5.4 几个值得养成的小习惯先说第一个习惯在 Windows 上提交任何.sh、.py等“将来可能在 Linux 上执行”的脚本前一定先跑一句git ls-files -s看看模式是不是100755。如果不是不要试图在 Windows 上把文件“设为可执行”直接git update-index --chmodx修正并提交。第二个习惯任何新仓库第一笔提交就放.gitattributes和.editorconfig哪怕当时还没写业务代码也要先把“仓库规则”固定下来。补配置比加功能要麻烦得多因为历史文件不会自动跟着新规则走。第三个习惯团队里如果有 Windows 和 Unix 混用的成员.gitattributes里把*.sh、*.ps1、*.bat这类脚本文件的行尾都写好。Windows 的bat脚本在 CRLF 下通常更稳Linux 的 shell 脚本在 LF 下才不会出怪问题。第四个习惯也是我踩坑之后总结出来的跨平台改动比较大的提交不要夹带其他功能调整。比如你在“统一行尾”的提交里顺手改了个逻辑发生问题回溯时很难定位因为git blame会把那一行算在“行尾规范化”头上。最后再说个小技巧。如果你在 macOS 或 Linux 上怀疑某个文件的权限或行尾状态与其反复git status观察不如直接把 Git 的状态输出调到“说人话”模式git status --short git diff --summary--summary会直接把 mode change、文件创建/删除的概要说出来省得靠肉眼在长 diff 里找。配合前面提到的git ls-files --eol和git ls-files -s绝大多数跨平台提交差异都能在提交前被识破。
1. Git 代码存储位置先看清三个区域和 .git 的内容1.1 工作区、暂存区、版本库Git 的三层结构不少刚接触 Git 的人会把“代码存在哪”理解成一个很朴素的问题代码要么在我电脑上要么在远程服务器上。真到了排查问题的时候这套认知完全不够用。先说个最典型的场景你在编辑器里改了一行代码git status能看到变化但电脑突然断电这个改动可能就没了可如果你执行过git add哪怕没git commit改动也已经被 Git“接住”了。同样是没提交区别就在“暂存区”这一层。我把 Git 的存储模型拆成三层理解起来会清楚很多工作区Working Directory就是你打开文件夹看到的那一堆文件IDE 里改的就是这里。暂存区Staging Area / Index可以理解成“待提交清单”位于.git/index文件里记录了下一次提交要包含哪些文件的快照信息。版本库Repository.git目录本身commit 之后的对象都存在这里。用个生活化的类比工作区是你办公桌上的文件暂存区是装进快递盒并贴好面单的那批货版本库是已经扫码入库、存进货架的档案。桌面乱了没关系入了库才算是“正式记录”。git add干的事就是“拍照快照 放进待提交区”git commit才是“正式封箱归档”。这里有个非常关键但对新手很不友好的点git add并不只是“标记一下这个文件要提交”而是把当前工作区里的文件内容压缩后生成了一个 Git 内部对象并写入.git/objects里去了。所以哪怕你 add 之后又把文件改了暂存区里保存的仍然是 add 那一刻的内容。这也是为什么git add之后文件丢失不算彻底丢而没 add 过的文件一旦工作区损坏就真的找不回来。1.2 .git 目录里到底存了什么我见过不少开发者用了两三年 Git打开.git目录看一眼就发怵然后又默默关掉。其实里面东西没那么多核心就几个部分。.git顶层一般有这些objects/Git 的“数据库”所有提交内容最终都变成对象存在这里。对象分四种commit提交、tree目录树、blob文件内容、tag标签。refs/引用目录heads/存本地分支tags/存标签remotes/存远程分支引用。HEAD一个指针文件内容通常是一行ref: refs/heads/main表示当前处于哪个分支。index暂存区文件本身二进制格式里面记录了暂存的文件路径、对象哈希、权限位等信息。config仓库级配置文件和全局的~/.gitconfig分开生效。hooks/Git 钩子脚本目录。logs/HEAD 和分支的变更历史reflog这是用来“后悔”的关键数据。COMMIT_EDITMSG最近一次提交的说明信息暂存文件。绝大多数人第一次想搞清楚代码在哪都会被objects/里的内容搞懵里面全是两位十六进制命名的子目录子目录里的文件名又是 38 位十六进制字符。合起来就是一个 40 位 SHA-1 哈希值这也是 Git 中对象的名字。理解这层结构会有个好处你会知道 Git 本质是个“内容寻址文件系统”而不是一个简单的“版本记录本”。哈希按内容计算内容相同则哈希相同因此同一文件的多个版本可以复用同一个 blob 对象不会因为每次提交都复制一份文件导致仓库无限膨胀。1.3 一次 commit 的对象链结构为了真正理解“提交”在 Git 里是什么我建议用git cat-file把对象链剖开看。比如执行git log --oneline拿到最新提交的哈希再执行git cat-file -p 哈希会看到一个 commit 对象的内容大致长这样tree 8f7a10f2d3f1b7e3e4f12ab3c34cd45e67f890ab parent 3c4d557f9f0d1c2d3e4f5a6b7c8d9e0f1a2b3c4d author Zhang San zhangsanexample.com 1700000000 0800 committer Zhang San zhangsanexample.com 1700000000 0800 fix: correct checkout path for Windowstree字段指向这个提交的根目录树对象再顺着 tree 对象的哈希继续git cat-file -p能看到一层目录里有哪些文件和子目录、对应的 blob 哈希和权限位。blob 对象里存的是文件内容的真正字节。这链条其实揭示了一个很重要的概念commit 对象本身不直接持有文件内容而是持有“指向一棵树的指针”每次提交相当于给整个项目目录拍了一张“结构快照”但内部对象因为内容寻址可以大量复用旧有的 blob。这种设计让 Git 的“每次提交都是完整快照”和“存储却很省空间”得以同时成立。同时注意author和committer两个字段常规提交时两者相同但在 cherry-pick、rebase、amend 等操作后会不一样。如果你需要在跨平台协作时排查“某行代码到底是谁引入的”这两个字段都会派上用场。2. 不同平台的存储差异文件系统比你想的更有个性2.1 三大平台的“存储脾气”各不相同Git 是跨平台的但操作系统不是。代码一旦落到本地文件系统就会被不同平台各自的规则“加工”一遍。这不是 Git 的问题而是文件系统层面的差异Git 只能尽量去适配。我整理了三个最常见平台的实时特点Windows 的 NTFS 对大小写不敏感默认配置下Foo.js和foo.js会被视作同一个文件没有 Unix 那种“执行权限位”的概念路径分隔符用反斜杠\macOS 的 APFS 默认对大小写不敏感虽然它支持区分大小写的格式但绝大多数人出厂没开有执行权限位路径分隔符用的是正斜杠/Linux 的 ext4、xfs 等文件系统对大小写敏感有完整的执行权限位路径分隔符是正斜杠/。这就引出了两个非常容易踩的坑一个是文件名大小写另一个是文件权限。两个坑都需要单独展开说。除此之外还有个小细节是路径分隔符。Git 内部统一用/存储路径Windows 上的\是给本地 API 用的。团队如果有成员在脚本或代码里硬编码了C:\Users\...这种路径拿到 Linux 上必然跑不起来。这类问题不算 Git 的职责但跨平台协作时几乎天天见值得在提交前检查一下。2.2 大小写敏感性本地没问题一到 Linux 就翻车大小写问题是最难排查的一类问题。原因很简单你在 Windows 或 macOS 的默认文件系统上根本“感觉不到”它的存在直到某个环节换到 Linux 上才突然爆出来。比如团队里有人不小心在仓库里同时提交了一个Readme.md和README.md在 macOS 本地上git status干干净净因为文件系统把它俩当成同一个文件——后写入的覆盖了先写入的。可一旦 CI 机器或生产服务器是 Linuxgit checkout时 Git 会把这两个文件都真实地创建出来这时候构建脚本只认README.md而某些代码里引用的是Readme.md轻则报错重则打包产物缺文件。Git 由于自身内部记录路径时是严格区分大小写的为了兼容 Windows/macOS 这种“不敏感”的文件系统就引入了core.ignorecase配置项。当 Git 探测到当前仓库所在文件系统不区分大小写时会自动把这个配置置为true。它干的事是让 Git 在状态比对、分支切换时尽量把“仅大小写不同”的文件当作同一个文件处理免得误判成“新增/删除”造成混乱。但这只是妥协并不解决问题。如果你在 mac 或 Windows 上发现仓库里可能存在“仅大小写不同”的文件可以用这条命令把整个提交树里的小写文件名列出来比对git ls-tree -r HEAD | awk {print $4} | sort -f | uniq -di如果输出里有重复项说明仓库里已经存在大小写冲突的文件了。修复思路是删掉其中一个把引用处统一后重新提交。只修改文件名大小写的标准做法是git mv -f Readme.md README.md如果这条命令因为文件系统“看不见目标文件”而失败可以分两步走先改成临时名再改最终名或者直接从工作区手动改名后git add -A重新暂存。反正思路只有一个让 Git 的暂存区记录到文件名变化而不是依赖文件系统替你判断。2.3 文件权限位Windows 提交脚本时的隐形炸弹在 Linux 和 macOS 上一个文件是否“可执行”由权限位决定常见的就是100644普通文件读写权限和100755可执行文件。Git 在存储 tree 对象时会把每个 blob 对应的模式记录进去。但在 Windows 的 NTFS 文件系统上压根没有 Unix 权限位的概念所以你没法对一个文件执行chmod x。后果在团队协作里非常明显某同学 Windows 上写了一个deploy.sh提交后 push 到远端Linux 服务器上git pull下来执行时直接报Permission denied。因为这个文件在仓库里的模式是100644不是100755Linux 不会把它当作可执行文件。这个坑在容器化、CI/CD 普及之后尤其常见。因为脚本一般不在本地 Windows 环境跑而是在 Linux 构建机或服务器上跑。等你发现跑不起来再去排查至少浪费一轮“提交→推送→拉取→执行”的时间。Git 本身对权限是敏感的在 Linux/macOS 上如果文件权限发生变化git status会提示 modified。比如mode change 100644 100755 deploy.sh如果你确认权限变化是刻意为之提交即可。如果你根本不想让 Git 跟踪权限变化可以把core.filemode设为falsegit config core.filemode falseWindows 上因为文件系统没有权限位Git 一般会自动把这个值设为false。但要注意如果仓库里的脚本本身就缺执行权限光改本地配置没用你得在仓库里把权限修正过来。正确做法是在能运行chmod的平台Linux/macOS上执行chmod x deploy.sh git add deploy.sh或者在不方便起 shell 的情况下用git update-index --chmodx deploy.sh git commit -m fix: mark deploy.sh as executable提交前我还习惯用git ls-files -s看一下当前暂存区里的文件模式确保脚本类文件是100755。这个习惯在 Windows 环境下特别值钱因为你本地根本看不到权限位全凭这一步检查兜底。3. 提交差异的核心CRLF、LF 与文本规范化3.1 行尾符号的历史原因聊跨平台提交差异绕不开行尾符号。先明确两个名词CR\r是“回车”把光标移回行首LF\n是“换行”把光标移到下一行。历史原因是教科书级别的早期电传打字机Teletype时代换行需要“回车”和“换行”两个动作配合。后来 Unix 开发者简化标准只保留了 LF 一种字符而 DOS/Windows 沿用了 CP/M 时代的习惯用 CRLF 表示一行结束再后来 macOS 从经典 Mac OS 转向基于 Unix 的 Darwin 内核后也回归了 LF。于是到今天三大平台在“换行怎么表示”这个问题上始终没统一。看起来这只是“多了一个隐藏字符”的小事但放进 Git 的 diff 和合并不分家的工作流里就成了最伤人的问题。最典型的症状是你的编辑器“看起来”没改任何东西但git diff显示整个文件每一行都被删了又加了。原因就是行尾符号全变了Git 把 CRLF 和 LF 当成不同的字符来比较。3.2 Git 的行尾转换机制autocrlf 与 safecrlfGit 为了解决跨平台行尾问题提供了行尾自动转换的机制核心配置项是core.autocrlf。它有三种取值truecheckout 时把仓库里的 LF 转成 CRLF 输出到工作区commit 时把工作区里的 CRLF 转回 LF 再入库。这是 Windows 环境的经典建议。inputcommit 时仍然把 CRLF 转成 LF 入库但 checkout 时不转换。工作区保持文件原本的行尾。false完全不转换仓库里存什么工作区就长什么样。我再说得直白一点不管你在 Windows 上把 autocrlf 设成哪种值只要不是falseGit 在把文件收进 objects 之前都会尝试把行尾统一成 LF。这正是跨平台协作时保证“仓库内统一”的关键。如果配置得当Windows 用户本地编辑文件看到的是 CRLF提交到仓库后变成 LFLinux 用户拉下来看到的是 LF提交后还是 LF。git diff自然就不会因为行尾差异而把整份文件标红。core.safecrlf则是安全开关。开启后Git 会在转换前先模拟一次“转换后再转回来比较”如果发现内容不一致常见于二进制文件中刚好出现 CRLF 字节序列会拒绝该次 add 或给出警告。在 Windows 上我建议设置成git config --global core.safecrlf true能让很多“文件被莫名改坏”的问题在提交前就爆出来。但 autocrlf 有个致命局限它是环境级配置不随仓库走。新成员加入团队后如果没配行尾照样会乱。这个问题必须靠.gitattributes来解决。3.3 用 .gitattributes 做仓库级统一.gitattributes是放在仓库根目录的文本文件作用是把“文本规范化”策略绑定到仓库本身而非某个开发者的机器。凡是提交到仓库的文件Git 会优先参考这个文件里的规则。先给一份我常用的模板# 默认对所有文本文件启用自动行尾规范化 * textauto # 明确要求某些文件固定用 LF *.sh text eollf *.ps1 text eolcrlf *.bat text eolcrlf *.cmd text eolcrlf Makefile text eollf Dockerfile text eollf # 明确标记二进制文件禁止做任何行尾转换和文本 diff *.png binary *.jpg binary *.jpeg binary *.gif binary *.ico binary *.pdf binary *.zip binary *.tar.gz binary *.exe binary *.dll binary *.so binary解释一下几行关键指令textauto让 Git 自动判断文件是否为文本。文本文件入库时统一转 LF检出时按平台习惯转回本地行尾。text eollf强制该类型文件在仓库和工作区都使用 LF。脚本文件必须这样配因为 Linux 上 CRLF 可能导致#!/bin/bash这种 shebang 解析失败。text eolcrlf强制使用 CRLF。批处理类文件保留这个选项主要是为了兼容老的 cmd 工具链。binary等价于-text -diff明确告诉 Git 别动它。关键点来了.gitattributes的优先级高于core.autocrlf。哪怕你在 Windows 上设了autocrlftrue只要仓库里定义了某个文件的eollfGit 就会按.gitattributes的指令走。但是很多人加了.gitattributes就以为完事了其实不对。文件的规范化在“下一次入库”时才生效仓库里已经存在的历史文件并不会自动改变。所以要补一步强制重新规范化git add --renormalize . git commit -m chore: normalize line endings via gitattributes执行完这一步后可以用git ls-files --eol查看每个文件的三种行尾状态工作区、暂存区、仓库确认仓库里存的是不是lf。这里有个容易翻车的细节如果仓库原本是“大杂烩”执行git add --renormalize .之后 diff 会非常壮观几乎每个文件都被判为修改。这是正常的因为文件的 blob 哈希变了。这个提交必须作为一次独立 chore 提交并且要快速通知团队拉取后本地工作区可能出现大面积“看起来被修改”的文件重新 checkout 一次即可git checkout .4. 跨平台提交的完整实操配置4.1 Windows 环境下的推荐配置如果你以 Windows 为主要开发环境并且参与的是跨平台仓库我的建议是不要裸用默认配置。至少做三件事第一设置core.autocrlf为true。这样在你git add时会把工作区 CRLF 转成 LF 入库git checkout时再把 LF 转回 CRLF 到工作区本地编辑器看到的还是 Windows 习惯的换行仓库里存的却是统一的行尾。第二如果仓库里已经有.gitattributes建议把core.autocrlf显式设为一个值别让安装向导替你随便选。通常有.gitattributes的仓库设成true也没问题因为 attributes 规则优先但如果你的仓库非常老、没有 attributes又希望完全不要本地转换可以设false。这个选择完全取决于项目是否已经做了仓库级规范化。第三把默认提交信息格式统一一下。Windows 的 CMD 对引号处理很原始PowerShell 对单双引号又有自己的一套逻辑。如果你习惯用git commit -m fix: something建议强制自己用双引号如果提交信息里有中文注意终端编码要切到 UTF-8。命令汇总git config --global core.autocrlf true git config --global core.safecrlf true git config --global core.filemode false git config --global core.ignorecase true另外 Windows 上我基本都推荐用 Git Bash 或者 Windows Terminal WSL 来跑 Git 操作而不是去 CMD 里折腾。原因不是 CMD 不能用而是引号转义、路径分隔符、换行规则都和 Linux 差异太大会徒增跨平台心智负担。4.2 macOS 与 Linux 环境下的推荐配置macOS 和 Linux 本质都是 Unix 系配置逻辑很接近。仓库内统一用 LF工作区也没必要转 CRLF所以core.autocrlf设成input或false都行。区别在于input会在提交时把工作区意外出现的 CRLF 转成 LF多一层保护false则是完全不处理。推荐配置git config --global core.autocrlf input git config --global core.safecrlf true git config --global core.filemode truecore.filemode这里设为true是因为 Unix 平台有权限位需要跟踪。但要注意一个特例如果你的项目仓库放在 Windows 共享目录、SMB 挂载盘或者某些网盘同步目录里文件系统不支持权限位Git 会误报大量 mode change。这种情况下不要全局硬改而是在对应仓库里临时设git config core.filemode falsemacOS 还有一个特殊点默认 APFS 对大小写不敏感所以core.ignorecase大概率会被自动探测为true。如果你想要更接近 Linux 的敏感行为可以考虑把仓库单独放在一个“区分大小写”的磁盘镜像或卷宗里但这个操作对绝大多数团队来说过于激进。日常工作中只要做到“文件名规范统一、成员自觉遵守”依靠 CI 在 Linux 上跑一遍检查就够了。4.3 新仓库的第一笔提交标准化配置我在多个团队里面发现一个现象很多仓库的.gitattributes是在出问题之后才补的补的时候仓库已经有几百个文件要重新规范化还得发公告、让大家重新 checkout相当折腾。更稳的做法是新仓库初始化后第一笔提交就带上这些规则。步骤我一般这么走git init之后先创建.gitattributes、.editorconfig、.gitignore。创建初始文件比如 README、LICENSE并用合适的分行符保存。执行git add --renormalize .其实新仓库没历史文件直接git add .就行但习惯先执行这步能帮你在第一步就验证规则有没有写错。git commit -m chore: init repository with gitattributes and editorconfig。.editorconfig是配合项它管的是“编辑器怎么处理文件”比如强制 UTF-8、末尾插空行、去掉行尾空白。虽然它不参与 Git 的存储逻辑但有了它团队里成员的 IDE 默认行为才和 Git 的存储策略对齐。一份常用的.editorconfigroot true [*] charset utf-8 end_of_line lf insert_final_newline true trim_trailing_whitespace true [*.{bat,cmd,ps1}] end_of_line crlf编辑器会在你打开和保存文件时按这里的规则工作。和.gitattributes一个管“编辑行为”一个管“Git 存储行为”配合起来跨平台提交差异能消灭一多半。4.4 团队提交的动作规范光有配置文件还不够团队里还得约定一些基本动作否则再好的规则也会被绕过去。我建议的提交流程是改代码前先确认当前分支和远端同步git pull --rebase。改完后先用git diff --check检查空白符错误比如行尾空格、末尾缺换行。git add后立即看一眼暂存区内容git diff --cached --stat。提交信息遵循统一规范比如fix: / feat: / chore: / docs:。推送前再git pull --rebase一次保证本地提交不产生多余的 merge commit。其中第二步很多人会略过但它其实是踩坑大户。git diff --check能看到error: trailing whitespace at EOF error: trailing whitespace in 1 line这类问题在跨平台协作里特别容易混进行尾转换的提交里混进去之后后续git blame定位代码来源时就会非常痛苦。另外如果团队用 CI建议在流水线里加一步“行尾和可执行权限检查”比如列出仓库里模式为100644的.sh文件并直接判失败倒逼提交者修正。5. 常见问题与排查技巧实录5.1 文件里的 ^M 到底怎么来的很多人在 Linux 或 macOS 上打开仓库里的文件发现每行结尾多了一个^M或者用cat看时行尾变成\r。这个问题的直接原因是文件里的行尾原本是 CRLF而你当前环境没有做转换。排查分三步走file src/index.js输出里带CRLF line terminators就说明文件是 CRLF 行尾。再进一步确认cat -A src/index.js你会看到行尾以^M$形式出现。最后看 Git 眼里这个文件的行尾状态git ls-files --eol src/index.js它会告诉你工作区w、暂存区i、仓库r三个位置分别是什么行尾。如果仓库r已经是lf工作区还是crlf说明只是本地 checkout 转换的问题如果仓库r就是crlf说明当初提交时没做转换需要重新规范化。解决办法分两种。仓库还没做统一规范化时先修正当前文件dos2unix src/index.js git add src/index.js git commit -m fix: convert line endings to LF如果仓库里存在大量此类文件那就回到上一节的方法加.gitattributesgit add --renormalize .一次性解决。5.2 diff 显示整个文件都被改动的真相这是跨平台协作里最常见的“灵异事件”明明只改了一行代码git diff却显示每一行都被删除又重新添加。遇到这种事先别急着怀疑人生九成九是行尾变化。这时可以立即执行一个忽略空白差异的比较命令git diff -w如果-w之后改动只剩真正的那一行基本能断定是行尾或者空白字符问题。接下来用git diff --stat看波及文件数量如果是大面积文件全部被改那往往是仓库级 autocrlf 配置变了或者有人在没有.gitattributes的情况下用另一种行尾提交了文件。处理建议不要试图人肉去把每个文件改回原样那样只会让仓库更乱。先补好.gitattributes和.editorconfig。执行git add --renormalize .再做一次独立提交。提交之后你可能会发现历史提交里的 diff 仍然显示得很难看那是历史不影响后续开发不用纠结。真正重要的是从这次提交开始仓库里的行尾是干净的。5.3 跨平台提交问题速查表现象主要原因快速排查命令解决方案打开文件出现^M仓库里存的或工作区里用的是 CRLFfile 文件、cat -A 文件dos2unix转换后重新提交或整体git add --renormalizegit diff整份文件标红行尾符号从 LF 变成 CRLF 或反之git diff -w验证统一.gitattributes EditorConfig重新规范化提示LF will be replaced by CRLFautocrlf 正在按配置转换git config core.autocrlf确认项目规范化策略后再决定是否保留当前配置脚本拉到服务器后无法执行文件在仓库中的模式是100644git ls-files -s 脚本git update-index --chmodx 脚本后提交出现mode change 100644 100755Unix 平台权限位变化被 Git 记录git diff查看确认是预期变化后提交不需要则git config core.filemode false仓库存在foo.js和Foo.js本地只能看到其中一个文件系统大小写不敏感Git 层有冲突文件git ls-tree -r HEAD | sort -f | uniq -di删除/重命名其中一个并统一引用提交信息乱码或换行不对终端编码或 shell 的引号规则差异git log -1 --format%BWindows 下建议用 Git Bash提交信息统一双引号仓库使用 UTF-8拉取后工作区大面积显示 modifiedcheckout 转换规则变了或历史行尾很乱git status、file 文件git checkout .重新检出必要时git add --renormalize一次5.4 几个值得养成的小习惯先说第一个习惯在 Windows 上提交任何.sh、.py等“将来可能在 Linux 上执行”的脚本前一定先跑一句git ls-files -s看看模式是不是100755。如果不是不要试图在 Windows 上把文件“设为可执行”直接git update-index --chmodx修正并提交。第二个习惯任何新仓库第一笔提交就放.gitattributes和.editorconfig哪怕当时还没写业务代码也要先把“仓库规则”固定下来。补配置比加功能要麻烦得多因为历史文件不会自动跟着新规则走。第三个习惯团队里如果有 Windows 和 Unix 混用的成员.gitattributes里把*.sh、*.ps1、*.bat这类脚本文件的行尾都写好。Windows 的bat脚本在 CRLF 下通常更稳Linux 的 shell 脚本在 LF 下才不会出怪问题。第四个习惯也是我踩坑之后总结出来的跨平台改动比较大的提交不要夹带其他功能调整。比如你在“统一行尾”的提交里顺手改了个逻辑发生问题回溯时很难定位因为git blame会把那一行算在“行尾规范化”头上。最后再说个小技巧。如果你在 macOS 或 Linux 上怀疑某个文件的权限或行尾状态与其反复git status观察不如直接把 Git 的状态输出调到“说人话”模式git status --short git diff --summary--summary会直接把 mode change、文件创建/删除的概要说出来省得靠肉眼在长 diff 里找。配合前面提到的git ls-files --eol和git ls-files -s绝大多数跨平台提交差异都能在提交前被识破。
