★ FEATURED ARTICLE Git 代码存储位置和在不同平台的提交差异这题目看着基础但我见过太多人在它上面翻车。最常见的场景团队里一半人用 Windows一半用 Linux/macOS明明代码逻辑没动Git 却跟你说“整个文件都被修改了”或者你在 Windows 上提交了一个脚本到了 Linux 服务器上一执行提示“权限不够”。这些问题的根源一半藏在 Git 对象模型对“存储位置”的理解上另一半藏在不同平台默认配置的差异里。这篇文章我会先把 Git 在本地到底把代码存在哪、每个目录每份文件是什么意思讲透再逐个拆解 Windows、Linux、macOS 三个平台在提交行为上的隐性差异最后给出一套可以照抄的跨平台提交规范化方案。适合刚接触 Git 的新手也适合在混合平台团队里被提交差异折磨过的人。读完你会明白很多提交问题不是“手误”而是你根本没搞清楚 Git 存储的位置有什么讲究、平台的默认行为有多坑。1. 存储位置Git 在本地到底把代码放进了哪里1.1 工作区、暂存区与对象库的前世今生很多人学 Git上来就背git add、git commit、git push背得很熟但对“代码存在哪”完全没概念。实际上 Git 在本地硬盘上把这些内容分成了三个完全不同的区域工作区Working Tree、暂存区Index / Staging Area和对象库Object Database。用生活化类比解释。工作区就是你的办公桌你摊开的所有文件随时随地都能看到、能改。暂存区是一张“待办清单”你git add就是把选中的文件写上清单告诉 Git“这些东西我准备入库”。对象库则是仓库货架git commit之后文件才真正被做成了不可变的快照放到货架上永久保存。关键点是git commit保存的不是文件本身而是一整套对象之间的关联。每次提交Git 会为这次提交生成一个 commit 对象这个对象记录了提交信息、作者、时间以及一个指向目录快照的 tree 对象。tree 对象记录的是目录结构里面的每个子项又指向对应的 blob 对象文件内容或另一个 tree 对象子目录。所有对象都以内容计算出的哈希值作为文件名按类型放在objects目录里。理解了这套模型很多现象就能解释了。比如“为什么删除一个分支仓库体积没变小”因为删除分支只是删除了对某些 commit 对象的引用这些对象本身还躺在对象库里Git 不主动清理。再比如“为什么我只改了一行代码提交却那么快”因为 Git 只新增了那一个改变了的 blob 对象其他没改动的文件继续复用原对象根本不重新存储。这套基于哈希的存储模型是 Git 能在任何平台上保证相同内容产出相同对象的核心也正因为存储位置分散在.git里才衍生出后面这些平台差异。1.2 .git 目录里那些文件夹的分工与体积陷阱你在任意一个 Git 仓库根目录执行ls -a会看到一个.git目录这就是 Git 仓库全部秘密的驻扎地。千万别以为这只是个“隐藏文件夹”里面每个子目录都有自己的职责清晰到你会感叹设计者的强迫症。先看objects这是对象库所在。绝大多数情况下你进去看到的不是一堆松散文件而是以两位十六进制字符命名的子目录和几个 pack 文件。Git 会不定期把松散对象打包成.pack文件体积更小、读取更快。诊断仓库体积时我用得最多的命令是git count-objects -vH它会把松散对象数量和总大小、pack 数量一起列出来。如果 size-pack 很大而你的代码明明没多少那大概率是历史里混入过大文件——比如不小心提交了一个 jar 包或视频。遇到这种情况常规做法是重写历史比如用 filter 类工具但重写之后必须清楚一点旧对象在新历史中不再被引用可它们仍然占用磁盘。要彻底释放需要执行git reflog expire --expirenow --all然后git gc --prunenow。这里有个我踩过无数次的坑你以为git push --force之后就干净了其实旧对象只是在你本地还留着下一次合作的人拉到你历史时可能依然把旧对象带过去。再看index它就是暂存区的实体文件一个二进制文件记录了工作区里哪些文件被纳入暂存、对象的哈希是什么、文件的基本元数据。不要尝试直接编辑它所有对暂存区的操作都走git add、git reset这些命令。refs目录保存分支和标签的引用里面通常是纯文本文件内容就是一个 commit 哈希值HEAD文件则标明当前检出的分支名或一个裸哈希。logs目录是引用日志reflog记录了你本地所有 HEAD 和分支的移动历史是“误删分支后救回来”的最后一根稻草。hooks默认放着示例挂钩脚本提交前检查、提交后自动部署都可以在这里实现。这个目录结构在不同平台上的物理形态略有差别Windows 上.git同样存在只是文件树的显示方式和权限语义不同。有个细节Windows 的某些工具会同步.git目录比如网盘同步软件一旦同步了.git里面的对象文件哈希和索引可能被破坏整个仓库直接废掉。所以我的铁律是把仓库放到不参与云同步的本地目录.git更是绝对不能被同步的东西。1.3 全局配置与仓库配置的存储位置差异说到代码存储位置很多人容易把“代码文件存哪”和“配置文件存哪”混在一起。Git 的配置同样有明确的存储位置而且它们直接影响不同平台上的提交结果。Git 的配置按生效范围分三层系统级配置存放在安装目录下的etc/gitconfigWindows 通常在C:\Program Files\Git\etc\gitconfigLinux 一般在/etc/gitconfig全局配置存放在用户目录下的~/.gitconfigWindows 上通常是C:\Users\你的用户名\.gitconfig仓库级配置则存放在仓库内的.git/config文件里。优先级从高到低是仓库级 全局级 系统级也就是说同名的配置项会以仓库内的设置为准。跨平台提交差异的很大一部分就是因为这三层配置在不同机器上各不相同。最典型的就是core.autocrlfWindows 上安装 Git 时安装器往往会帮你把全局配置写为trueLinux 和 macOS 上则通常不写这一项默认按false处理。同一个人如果在两台机器上各配了一遍环境他的提交行为就可能完全不同而这些问题根本不会体现在仓库代码里因为它存在你的~/.gitconfig里不入库、不共享。因此排查任何“换台电脑就出问题”的 Git 怪事时第一步永远是git config --list --show-origin。这个命令会把每个配置项的值和它来自哪个文件一起列出来瞬间定位到是哪一层配置在捣鬼。注意还有一个环境变量GIT_CONFIG_GLOBAL能重新指定全局配置文件路径某些自动化构建环境会用到它但普通场景尽量别碰容易让排查过程变得混乱。2. 三个平台在提交行为上的隐性差异2.1 行尾处理CRLF 与 LF 引发的“幽灵改动”跨平台提交差异里最让人抓狂的一类就是行尾问题。Windows 文本文件默认用回车加换行CRLF\r\n表示一行结束Linux 和 macOS 默认只用换行LF\n。Git 底层存储的对象是按字节比较的所以同样一行代码Windows 存的是 “abc\r\n”Linux 存的是 “abc\n”这两个字节序列不一样Git 就认为这是两个不同的内容。于是出现了经典“幽灵改动”你在 Windows 上什么都没改只是打开文件另存了一下CRLF 被统一提交上去后 Linux 同事一拉下来发现整个文件被标记为修改git diff里所有行都变成删除和新增。更隐蔽的是有些编辑器会自动把文件行尾从 LF 转成 CRLF你只是打开看了一眼保存时整个文件的行尾就变了Git status 立刻报告一堆 modified 文件但git diff看内容却似乎是一样的。Git 为了处理这个差异提供了core.autocrlf配置项。它有三种取值true表示提交时把 CRLF 转为 LF 存储检出时再转为 CRLFinput表示提交时转 LF 存储检出时不转、保留仓库里的 LFfalse表示不进行任何转换存什么就是什么。Windows 上很多人被默认安装器设为trueLinux 上通常是false这意味着同样的仓库在不同平台上的行为天然不一致。但我必须说句实在话靠每个人在自己的电脑上配core.autocrlf来解决问题根本靠不住。因为这是本地配置不随仓库走换个设备就失效。真正能根治的解法是把行尾规则写进仓库内的.gitattributes文件让规则跟随仓库所有人在任何平台拉下来都会读到统一规则。后面我会专门讲全套配置。2.2 文件路径大小写Linux 放心、macOS 侥幸、Windows 翻车文件系统对文件名大小写的敏感程度是另一个被忽略但杀伤力巨大的差异。Linux 的主流文件系统ext4、xfs、btrfs严格区分大小写readme.md和README.md是两个完全不同的文件。Windows 的 NTFS 在语义上默认不区分大小写abc.txt和ABC.txt会被当成同一个文件。macOS 的 APFS 文件系统默认也不区分大小写但可以格式化为区分大小写版本。Git 本身是区分大小写的它的对象库可以同一目录下同时存在User.cs和user.cs。可当 Git 在工作区生成这两个文件时Windows 和 macOS 的文件系统可能直接拒绝创建第二个或者创建后互相覆盖。还有更常见的场景文件叫DataHelper.cs某天你重命名为datahelper.cs在 Linux 上这是正常的重命名提交到了 Windows 上Git 根本看不出你重命名了——因为文件系统层面这是同一个文件最终提交时 Git 可能什么变化都没记录或者记录成修改而不是重命名。平台默认的core.ignorecase配置也印证了这一点Windows 和 macOS 的 Git 默认把它设为trueLinux 默认false。true意味着 Git 在比较文件名时主动忽略大小写这在某种程度上“适应”了文件系统的限制但也导致真正的大小写重命名很难被正确追踪。我建议团队统一约定文件名一律小写开头、驼峰命名严禁只修改大小写来重命名文件。如果确有大小写重命名的必要最稳妥的操作是两步走先git mv 旧文件 临时名提交一次再git mv 临时名 新大小写文件名再提交一次。这样在 Windows 上执行git mv时不会出现“目标文件已存在”的报错。2.3 文件权限与可执行位为什么提交到别人电脑上就变了Git 并不会完整记录 Unix 的 rwx 权限体系它只记录两种文件模式普通文件100644和可执行文件100755。这两种模式的具体体现在 Windows 和 Linux 上有着截然不同的生态。Windows 文件系统没有 Unix 那种独立的可执行位概念Git for Windows 一般在安装时默认把core.fileMode设为false意思是 Git 不再检查工作区文件与索引中的权限位差异。但问题在于如果某个文件在仓库里被记录为 100755那么仓库在 Windows 上被克隆下来时文件系统可能根本没有可执行权限这个概念你做出的任何修改在提交时也不会去维护那个 100755。等另一位 Linux 同事拉到代码脚本找不到了、可执行权限没了只能手动chmod x再提交一次。反过来Linux 上如果core.fileMode保持默认的true那么文件权限位的任何变动——哪怕只是目录执行权限被 umask 影响而发生轻微变化——Git 都可能报告old mode 100644 new mode 100755这样的状态。很多时候你什么都没改git status却不干净原因就是某个文件的权限位在平台间被静默改变了。这里的核心矛盾是Git 用一套相对简化的 Unix 权限模型来描述文件而不同平台对这个模型的支持程度天差地别。对于一个跨平台项目最省心的做法是显式关闭权限位影响在每个仓库里设置core.fileMode false同时在提交规范里规定哪些文件必须是可执行的并在 CI 里校验而不是指望 Git 自动替你完成。3. 核心机制配置项是如何让平台差异变大的3.1 core.autocrlf、safecrlf 与 fileMode 的兼顾逻辑搞清楚三个平台的差异只是第一步真正要理解的是 Git 在“检出”和“提交”两个阶段如何叠加这些差异的。先看行尾转换的完整流程。以core.autocrlf true为例当你git add时Git 会把工作区文件的 CRLF 转换为 LF 写入暂存区意味着对象库里保存的是 LF当你git checkout时Git 又会把 LF 转换为 CRLF 写回工作区意味着你本地的文件保持 Windows 风格。这就很微妙了如果你在 Windows 上add后再git diff --cached看到的内容可能和本地文件显示的不完全一致因为 diff 是在替你做转换之后的对象上执行的。safecrlf是另一个配置项用于防止不可逆的行尾转换。举例仓库里存的是一个 LF 文件但你本地的autocrlf设置会导致提交时把本地文件重新转成 LF如果文件里本来有混合行尾Git 可能无法确定哪些该转。当safecrlf设为true时Git 发现不可逆转换会直接报错拒绝提交设为warn时只会警告但不阻止。我的经验是别把safecrlf设成true否则团队里会用各种编辑器改写行尾的人会频繁撞墙建议用.gitattributes规范规则让 Git 自己判断。fileMode的逻辑相对简单true时 Git 会比较工作区文件权限和索引中的权限并报告差异false时完全忽略。但它和autocrlf一样属于用户级配置不随仓库走因此同一份仓库在不同平台上的提交行为就会产生差异。这就解释了为什么同一批代码有人提交出来全是文件权限变化有人提交出来干干净净——不是代码问题是环境配置差异。3.2 平台默认配置的差异以及我们到底该怎么选不同平台上 Git 的默认配置值有相当大的偏差。整理一张我记忆里常见的默认情况配置项WindowsmacOSLinuxcore.autocrlftrue多数安装器falsefalsecore.fileModefalsetruetruecore.ignorecasetruetruefalse看到这张表你就明白了同一份仓库在 Windows 上提交时你可能得到一个“被转换过的干净提交”在 Linux 上提交时你可能因为权限位变动而多出大量无意义的状态。这种差异不是某个人配错了而是平台生态本身不同。那我们到底该怎么选我给团队的默认建议是仓库内放一份完整的.gitattributes文件作为唯一权威把所有文本文件的行尾规则、二进制文件标记、可执行脚本标记统统写死。把core.autocrlf设为false让 Git 不要依赖本地转换把core.fileMode设为false不关心权限位自动差异把core.ignorecase也统一关闭或统一开启我一般建议关闭后进行严格的文件名大小写检查。千万别小看这几个布尔值它们几乎决定了“换台电脑提交是不是会带一堆无关改动”这个问题的结局。只要这些配置在团队里没有统一约定提交差异就会像幽灵一样反复出现。3.3 .gitattributes一次配置全团队生效有些读者可能会问上面说的全局配置太不可控了有没有一个文件能直接写在仓库里让所有平台所有人都自动生效答案就是.gitattributes。它不是配置文件存储位置的替代品但它把文件级别的属性规则和仓库一起分发优先级高于用户级配置这是它最大的价值。.gitattributes的语法简单直接格式是“模式 属性列表”。我常用的一个最小化且够用的模板# 基础行尾规则 * textauto # 统一用 LF 的文本文件 *.sh text eollf *.py text eollf *.js text eollf *.ts text eollf *.md text eollf *.json text eollf *.yml text eollf # Windows 批处理保留 CRLF避免 cmd 语法问题 *.bat text eolcrlf *.cmd text eolcrlf # 二进制文件全部标记为不参与换行转换 *.png binary *.jpg binary *.jpeg binary *.gif binary *.ico binary *.woff text *.pdf binary *.jar binary *.class binary *.zip binary* textauto是关键它让 Git 自动判断文件是文本还是二进制并在提交时统一转换为 LF。随后你可以用更具体的规则覆盖特定扩展名。比如*.sh text eollf强制所有 shell 脚本在检出时也是 LF避免 Windows 上出现^M导致的语法错误。binary属性本质上等同于-text -diff标记后 Git 不会对它们做任何行尾推断。设置了.gitattributes之后需要一次性重新规范化整个仓库里的行尾。只需在仓库根目录执行git add .gitattributes git add --renormalize . git commit -m 规范仓库行尾这个--renormalize选项会无视autocrlf的本地设置强行按.gitattributes的规则重写暂存区中文件的字节内容。但注意它不会把仓库历史中已经存在的不规范文件改掉——如果你需要重写整个历史那要另说风险也大不少。对大多数团队来说从某个时间点开始规范比把历史翻个底朝天要稳妥得多。4. 跨平台提交标准化实操一个模拟项目X的完整流程4.1 场景描述与环境约定为了让你能直接套用我构造一个很常见的团队场景某个跨平台系统代码仓库已经跑了半年团队里有几位用 Windows 的开发、几位用 Linux 的开发还有一两个用 macOS 的。仓库里已经混入了大量行尾不统一、脚本可执行权限错乱、文件名大小写不规范的问题。目标是在这个混乱基础上建立起一个统一基线让后续提交不再被平台差异污染。环境约定要先定好统一使用 Git 2.x 以上版本不依赖各人本地的全局配置一切以仓库内的.gitattributes和明确记录的仓库配置为准所有开发机的编辑器统一配置为“写入 UTF-8 编码、LF 行尾”这一步可以通过.editorconfig文件进一步辅助editorconfig 和 gitattributes 是两套东西但目标一致。在仓库根目录放一份.editorconfig也是好习惯。4.2 从零搭建仓库并配置统一的行尾与权限策略这个“从零搭建”不是让你重新 git init而是指在当前仓库上进行一次规则重建。第一步在仓库根目录创建.gitattributes文件写入刚才那个模板并在文件里补充项目实际用到的扩展名规则。第二步统一仓库级别的配置。执行以下命令把关键配置写进.git/config这样它们会跟随克隆吗不会.git/config不被克隆所以不能完全依赖它但可以在团队文档里要求成员 clone 后执行。不过这里有个巧妙的补充方案把配置建议写进 README 或提交模板或者给一个初始化脚本让团队成员拉取后跑一遍。我的习惯是给一个scripts/git-setup.sh内容预设了所有推荐配置。git config core.autocrlf false git config core.fileMode false git config core.ignorecase false git config core.safecrlf warn git config core.quotepath false第三步对现有文件重新规范化。执行git add --renormalize .然后git status查看哪些文件被重写了。你会看到大量文件出现在修改列表里这是正常的它们将从旧行尾统一为仓库规则的标准行尾。第四步处理可执行脚本的权限。逐个检查哪些脚本需要保留可执行权限例如scripts/下的.sh文件用命令确保索引中的模式正确git update-index --chmodx scripts/deploy.sh注意git update-index修改的是索引中的权限位不是工作区文件的真实权限正好可以在 Windows 上强制执行 100755 模式。4.3 双平台提交与冲突处理实录以开发机 AWindows为例修改一个 Python 文件后执行git add、git commit。如果一切配置正确提交里不应该出现任何与行尾有关的额外改动。随后开发机 BLinux拉取这个提交执行git status看到工作区应该是干净的然后在 B 上修改同一个文件并提交A 再拉回来依然干净。这就是跨平台提交标准化后该有的样子。但现实操作中会有几种插曲。第一种B 拉取后git status不干净出现了大范围 modified。几乎可以断定是 B 的本地core.autocrlf和仓库.gitattributes打架导致的。此时检查 B 的配置把core.autocrlf改为false后再试。第二种Windows 上出现文件权限相关 diff说明core.fileMode没有设为false。第三种合并冲突。行尾问题是无法从git diff直观看出冲突根因的遇到碎片化冲突时先判断是否是因为行尾不一致导致的全局冲突。如果全文件被标记为冲突但在图形化冲突工具里看到的“差异”只有 CRLF 和 LF那就不是真正的代码冲突可以先统一行尾再合并。处理这类冲突的办法很直接在一个干净状态下确保.gitattributes已生效、git add --renormalize .已执行再重新合并目标分支。如果实在不行把冲突文件在本地统一转成仓库标准的 LF 后重新git add。4.4 提交后验证清单提交后不要直接说“完成”我习惯按下面的清单快速验证检查项命令或方法期望结果工作区是否干净git status --porcelain无额外输出是否有权限差异git diff --summary无mode change类输出关键脚本是否可执行git ls-files -s scripts/deploy.sh模式为 100755行尾是否符合约定git ls-files --eol显示正确 eol二进制文件是否被误判为文本git check-attr -a static/logo.png显示 binary把这套清单沉淀成团队提交前自检流程或者放到 CI 流程中当一步检查任务。只要过了这几项跨平台提交的坑基本就被填平了。5. 常见问题与排查技巧实录速查5.1 “我明明改了为什么提交里没有”类问题这是最容易被自己的眼睛骗到的情况。原因通常有两个第一你改的是权限位不是内容。比如某个文件只是chmod x了git status显示 modified但如果core.fileModefalseGit 完全无视它提交里自然不会包含。第二你改的是行尾但在 Git 看来内容经过转换后和之前一致。比如你在 Windows 上把 CRLF 改成 LF如果仓库里本来就存 LF你的add没触发任何变化看起来就像“提交没生效”。排查顺序先git status --short看状态再git diff --stat看是否有内容变化然后git diff --cached --stat看暂存区是否真有东西可提交最后查git config --list确认核心配置没有被本地文件覆盖。我以前就见过某个同事的全局配置把core.autocrlf设成了input本地文件已经被自动转换为 LF结果每次提交都少了那次“转换”他反复以为代码没保存。5.2 换行符导致的 Diff 异常与乱码如果你在git diff时看到每一行都被删除又新增十有八九是行尾问题。最直观的确认方式是用git diff --ignore-space-at-eol对比如果忽略行尾差异之后 diff 变成空那就是纯行尾问题。强烈建议把git diff --ignore-space-at-eol当成日常操作习惯。更彻底的检查可以用git ls-files --eol它会列出每个索引文件的存储行尾、工作区行尾和工作树是否匹配。看到i/lf w/crlf之类的输出一眼就明白状态。修复时避免手动批量替换历史文件应该先配置好.gitattributes再执行git add --renormalize .一次把所有文件规整到位。还有一类乱码不是行尾问题而是提交信息乱码。Windows 上如果终端默认编码不是 UTF-8git commit输入的提交信息可能因为编码转换出现乱码。解决方案是设置两样东西git config --global i18n.commitEncoding utf-8和git config --global i18n.logOutputEncoding utf-8同时确保终端使用 UTF-8。另外core.quotepath false也很重要它能保证中文文件名在输出时不被转义成八进制序列否则你会看到一串看不懂的\346\226\207类字符。5.3 文件大小写问题与权限丢失大小写问题在重命名时最容易爆发。假设仓库里有README.md你在 Windows 上手动改成readme.md文件系统不区分大小写你其实没真正“重命名”Git 在 commit 时也可能没有任何记录。正确的做法是使用git mv二次替换法如前面所说。如果已经搞乱了就用git mv -f 旧名 新名强制覆盖同时留意文件系统层面的冲突。权限丢失问题同样常见。脚本从 Linux 提交到 Windows 再回到 Linux可执行位可能没了。修复索引中权限位的命令是git update-index --chmodx scripts/deploy.sh git commit -m 设置 deploy 脚本为可执行注意--chmod只影响索引不会修改工作区文件的实际权限但提交后的对象模式会被记录下来下一个人克隆或拉取时就能拿到正确的 100755。5.4 编辑器与工具链的额外差异最后补充一个很多人忽略的差异来源编辑器。某些编辑器默认使用 BOM字节序标记写 UTF-8 文件Git 会把它当成内容的一部分。同样一个.md文件带 BOM 和不带 BOM 在 Git 看来是两个不同文件diff 时显示差异而且很多 Linux 工具不认 BOM会导致脚本解析第一行出错。我的建议是所有跨平台文本文件一律无 BOM UTF-8 编码这个规则写进.editorconfig。还有一个低频但真实的差异某些 Windows 编辑器保存文件时会把文件末尾追加或删除一个换行符。Git 默认会在某个文件末尾没有换行符时提示 “No newline at end of file”。为了减少噪音团队规范里可以约定“所有文本文件末尾保留一个换行”并在.editorconfig里配置insert_final_newline true。这个约定看似琐碎实际能省掉大量无意义的 diff。尾声我个人的实操体会这套方案我在多个混合平台上实践过。踩过几次坑之后最大的体会是跨平台提交差异不是靠某一个人“细心”就能规避的必须把规则落到仓库文件层面。团队里如果有人经常在 Windows 和 Linux 之间切仓库优先把.gitattributes写好把core.autocrlf、core.fileMode的默认值统一写进初始化脚本。再分享一个小技巧仓库规范化一次之后在 CI 里加一条简单的检查任务验证git status --porcelain是否为空、git ls-files --eol是否全部符合预期这样哪怕有人新装了环境带错了配置也能在合并前就被拦下来而不是等代码污染了仓库再回滚。这些动作成本不高但能让跨平台协作真正变得不闹心。
阅读完成 · 觉得有帮助？
