Git 首次配置与跨平台文件变更

1. 安装后先设置什么#

下面的 Git 命令适用于 macOS、Linux 和 Windows；Windows 可在 Git Bash 中执行。示例姓名、邮箱和路径需要替换。本文各场景独立选用，不要从头到尾连续执行。

先确认 Git 可用，再设置提交身份：

git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

user.name 和 user.email 会写入以后创建的提交，用来标识作者和提交者；修改配置不会改写已有提交。姓名可以是你希望展示的名字，邮箱使用你希望记录在提交中的地址。如果希望托管平台把提交关联到你的账号，使用该平台认可的邮箱；不希望公开私人邮箱时，可使用平台提供的隐私邮箱。

这两个配置不是登录凭据，也不会授予 push 权限。访问远端仓库仍要按远端地址使用 SSH 密钥或 HTTPS 凭据认证。官方首次配置说明

全局设置与单个仓库设置#

例如工作仓库要使用公司邮箱，在该仓库目录中执行：

git config --local user.name "Your Name"
git config --local user.email "you@company.example"

在目标仓库中检查最终生效的值及其来源：

git config --show-origin --get user.name
git config --show-origin --get user.email

--show-origin 会显示配置来自哪个文件。以下可选项不是首次提交的必需条件，按需要设置：

# 以后 git init 新建仓库时，初始分支叫 main。
git config --global init.defaultBranch main

# 未显式配置提交身份时阻止 Git 自动猜测姓名和邮箱。
git config --global user.useConfigOnly true

init.defaultBranch 不会重命名已有分支，也不决定 clone 后检出的默认分支。开启 user.useConfigOnly 后，若未设置身份，提交会提示错误，需要补上全局或仓库配置。

Git 在填写提交信息、交互式 rebase 等场景会启动编辑器。若已安装 VS Code 且终端能运行 code，可设置：

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

--wait 让 Git 等待编辑窗口关闭后继续操作。使用其他编辑器时替换为对应命令，例如 nano；不需要额外编辑器配置时可保留默认值。pull 使用 merge 还是 rebase 应按仓库约定选择，参见 Git 常用操作。

2. Windows 拉取后，为什么没编辑也显示文件变更#

先区分两件事：pull 更新了提交，本来就可能更新磁盘上的文件；这里要排查的是 pull 完成后，git status 仍显示未提交的修改。正常 checkout 即使转换了换行符，也应该能够保持工作区干净。

你记得的“好像不是换行符”可能是可执行权限位变化。仅凭操作系统和现象不能确定，先看 diff：

git status --short
git diff --stat
git diff --summary
git diff -- path/to/file

git diff 检查尚未暂存的修改；如果已经执行过 git add，改用：

git diff --cached --summary
git diff --cached -- path/to/file

2.1 可执行权限位：100644 与 100755#

普通文件的 100644 表示 Git 记录它不可执行，100755 表示可执行。Git 不跟踪普通文件完整的 Unix 权限、所有者和用户组，但会跟踪这个可执行位。因此内容完全没变，也可能显示修改。

例如 git diff --summary 输出：

 mode change 100755 => 100644 scripts/deploy.sh

这类情况可能发生在复制仓库、使用共享磁盘，或同一目录交替用不同环境的 Git 操作之后。Git 的 init/clone 会探测文件系统是否支持可执行位，但之后环境变了，原配置可能不再适合。官方 core.fileMode 说明

先查看配置：

git config --show-origin --get core.filemode

确认是当前文件系统造成的无意义权限变化，且只需要让该仓库忽略工作区可执行位差异时，在仓库内执行：

git config --local core.filemode false
git status --short

这会忽略工作区的可执行位差异，不会修改文件内容，也不会撤销已经暂存的权限变更。不要为了消除提示就统一全局关闭，否则容易漏掉本来需要提交的脚本权限变化。

如果是有意让脚本在 Linux/macOS 上可执行，即使当前文件系统无法正确表达权限，也可以显式更新暂存区：

git update-index --chmod=+x -- scripts/deploy.sh
git diff --cached --summary

确认后正常提交即可。--chmod=-x 表示在 Git 中去掉可执行位。

2.2 换行符：LF 与 CRLF#

LF 是换行字符，Unix/macOS 文本通常使用它；CRLF 是回车加换行两个字符，Windows 文本常使用它。Git 可以让仓库中保存 LF、工作区使用 CRLF，所以“磁盘文件是 CRLF”本身不等于发生了未提交修改。

在仓库内检查文件实际换行符、属性和本机转换设置：

git ls-files --eol -- path/to/file
git check-attr text eol filter working-tree-encoding -- path/to/file
git config --show-origin --get core.autocrlf
git diff --ignore-space-at-eol -- path/to/file

git ls-files --eol 的 i/lf 表示暂存区内容是 LF，w/crlf 表示工作区是 CRLF，attr/ 后面是生效的属性。最后一条 diff 忽略行尾空白；如果差异消失，说明可能与行尾空白或换行符有关，还需结合前三条判断。配置查询没有输出，可能只是该选项未显式设置。

core.autocrlf 的常见值如下；仓库的 .gitattributes 还可以对具体文件指定规则：

不要只按操作系统照抄一个全局值。团队应优先用仓库根目录的 .gitattributes 明确文件规则，让各平台共享。例如以下是文件内容，不是终端命令：

# 自动识别文本，仓库中规范化为 LF。
* text=auto

# Shell 脚本在工作区也使用 LF。
*.sh text eol=lf

# Windows 批处理脚本在工作区使用 CRLF。
*.bat text eol=crlf
*.cmd text eol=crlf

# 二进制文件不做文本换行转换。
*.png -text
*.jpg -text

新增规则不会自动重写所有已跟踪文件。若团队决定统一历史遗留的换行格式，先确保工作区和暂存区干净，在专门分支中保存 .gitattributes，然后执行：

git add .gitattributes
git add --renormalize .
git diff --cached --stat
git diff --cached

--renormalize 会按当前规则重新处理已跟踪文件，可能产生较大差异。检查确认只有预期的规范化修改后，再提交；不要把业务代码修改混在其中。官方换行规范化说明

2.3 其他可能原因#

如果权限和换行符都排除了，继续检查这些情况：

• 编码或 BOM 改变：编辑器可能把 UTF-8 改成其他编码，或增加/移除文件开头的字节顺序标记（BOM）；这属于文件字节内容变化。
• Git 过滤器：.gitattributes 中的 filter 可以在检出和暂存时转换内容，例如 Git LFS。不同机器缺少相应工具、配置不同，或自定义过滤器不能稳定往返转换，都需要检查；上面的 git check-attr 可确认文件是否使用过滤器。
• 文件名大小写或符号链接：不同文件系统的支持情况有差异。若出现路径重名或文件类型变化，检查文件名、链接及 core.symlinks，不要仅为了隐藏现象随意修改 core.ignorecase。

单独改变文件修改时间，不会成为需要提交的内容差异。排查时保留原始 diff；不要直接用 reset --hard 清理，以免丢失真正的本地修改。