企业官网建设流程全解析

写这篇教程的起因很实际：我几乎每年都要帮团队里的新同事在 Windows 上配一次 Git，每次都会遇到环境变量没生效、换行符把整个 diff 搞得没法看、SSH 密钥认不了一类的破事。Git 官方文档写得全，但对新手不太友好，所以我想把 Windows 下从下载、安装、环境配置到 SSH 密钥设置一整套流程，用一个能直接照着做的思路捋清楚。这篇文章适合刚接触 Git 的人，也适合已经用了一段时间但一直没把环境配置弄明白的朋友。你不需要背任何命令，跟着一步步操作就行，我把为什么这么选、选错了会有什么后果也都写出来了。

1. 安装 Git 之前，需要先想清楚这三件事

1.1 Git 是什么，日常开发里它到底解决什么问题

Git 是一个分布式版本控制系统，简单点说，它负责记录你项目目录里所有文件的变化历史。你写完一版代码，提交一次，Git 就把当前状态存成一个快照；改坏了，随时可以回退到任意一次提交；多人协作时，每个人在自己本地提交，最后再合并到同一个仓库里。比起复制文件夹存版本号那种原始做法，Git 的强大之处在于它的分支模型和近乎完整的本地历史记录。

在 Windows 上谈 Git，实际指的通常是一套名叫 Git for Windows 的发行版软件。它不只是命令行工具，还捆绑了 Git Bash 终端模拟器、Git GUI 图形界面，以及一批常用的 Unix 工具，让 Windows 下的命令行体验尽量接近 Linux。很多人把 Git 和 GitHub 混为一谈，其实 GitHub、GitLab、Gitea 这些只是托管仓库的远程平台，Git 才是背后的版本管理工具本身。用 Git 不一定需要 GitHub，但要用好 GitHub、GitLab，你本地必须有一套好用的 Git 环境。

1.2 下载渠道怎么选，官方站和镜像站哪个更适合你

Git for Windows 的官方下载地址是 git-scm.com/download/win。打开后页面会自动识别 Windows 系统，通常你会看到 64 位和 32 位两个安装包，现在的电脑绝大多数都是 64 位，直接下载 64 位版本即可。官方源的优点是永远最新，和 Git 主线版本同步，没有第三方改动的风险。

但有个现实问题：从官方源下载大文件，网络不好的时候可能很慢，甚至反复中断。国内有不少开源软件镜像站会同步 Git for Windows 的安装包，比如清华大学开源软件镜像站、腾讯软件源、阿里云镜像站等。从这些镜像站下载的安装包本质上和官方一样，都是同一个二进制文件，只是分发路径不同。我建议的下载顺序是：先试官方源，慢得离谱就直接切镜像站，没必要在下载上死磕。判断安装包是否正规，主要看是否带数字签名，右键点击 exe 文件，选择属性，如果能看到“数字签名”页签且签名正常，基本可以放心使用。

1.3 Windows 自带的 OpenSSH 和 Git for Windows 的关系

Windows 10 1809 之后的系统自带 OpenSSH 客户端，这点很容易让人困惑——我已经有 ssh 了，是不是不用装 Git 了？这是两码事。系统自带的 OpenSSH 只解决了远程连接时的加密问题，它不包含 Git 本身。你仍然需要安装 Git 这个版本管理工具，否则git clone、git commit这些命令是根本不存在的。

Git for Windows 在安装时还会给你一个选择：SSH 可执行程序是用它自己自带的版本，还是用 Windows 系统自带的 OpenSSH。这关系到后面配密钥时的细节，我会在安装配置那一节具体说。现在你只需要知道，装 Git 是本，SSH 是搭配它使用的传输通道，先装好 Git，再谈密钥配置。

2. Windows 下 Git 安装全程：照着选就不会错

2.1 安装包的获取和基本双击流程

下载完安装包后，右键运行。如果你的电脑开启了 UAC 用户账户控制，会弹出确认窗口，点“是”即可。安装的第一步是选择安装路径，默认是C:\Program Files\Git，这个路径本身没问题，但我个人习惯装到D:\DevTools\Git或者C:\Git这种不带空格的目录。为什么在意空格？虽然 Git 自身已经能处理Program Files，但偶尔会碰到一些第三方工具调用 Git 时因为路径空格而出现奇怪的解析问题，尤其是老的脚本和构建工具。

后续向导界面会依次让你确认组件选择、默认编辑器、PATH 环境变量、SSH 后端、HTTPS 传输后端、行尾转换、终端模拟器、git pull默认行为、凭据管理器等选项。初学者看到这么多英文选项容易慌，其实真正影响日常使用的只有几个，其他保持默认就行。下面我把每个选项单独拆开讲。

2.2 安装向导的关键选项拆解

选择组件：默认会勾选“Git Bash Here”和“Git GUI Here”，这两个建议保留。前者让你在任意文件夹右键直接打开 Git Bash，后者提供一个图形化操作界面，虽然我平时几乎不用 GUI，但留着不碍事。如果勾选了“Additional icons”，桌面会多出来 Git Bash 和 Git GUI 快捷方式，看个人习惯。

默认编辑器：Git 在某些操作中需要打开文本编辑器，比如git commit不带-m参数时。默认是 Vim，但 Vim 对新手极其不友好，不会退出的人能在里面卡十分钟。如果你装了 Visual Studio Code，强烈建议在下拉框里选“Use Visual Studio Code as Git's default editor”，没装的话选择“Use Notepad++”也可以。这里的选择会直接写入 Git 的全局配置，后面也可以手动改。

调整 PATH 环境变量：这是新手最需要理解的一个选项。Git 安装向导会让你选择怎么把 Git 命令暴露给命令行工具。选项一“仅从 Git Bash 使用 Git”最干净，但 VS Code 这类第三方软件的终端里没法直接使用git命令；选项二“从命令行使用 Git，并从第三方软件中使用 Git”是推荐选项，也是大多数人的选择，它会把C:\Program Files\Git\cmd加入系统 PATH，这样不管在 CMD、PowerShell 还是 VS Code 终端里，输入git都能直接识别；选项三“从命令行使用 Git 和可选的 Unix 工具”会把 Git 的整个usr/bin目录也加进 PATH，导致 Windows 自带的find、sort等命令被覆盖，新手不建议选。

SSH 可执行程序：这里有两个方向，一是“使用捆绑的 OpenSSH”，也就是 Git 自带的 ssh.exe，二是“使用 Windows 内置 OpenSSH”，走系统C:\Windows\System32\OpenSSH里的那份。我自己通常保留 Git 自带的路径，因为跟随 Git 版本更新，行为更可控。需要注意的是，如果你选择了 Windows 内置 OpenSSH，后面生成密钥时用到的可能是系统的ssh-keygen，两者生成出来的密钥格式完全兼容，只是存放位置和工具链不同，不用太纠结。

HTTPS 传输后端：默认推荐 OpenSSL，另一个选项是 Windows Secure Channel。如果你的公司有内部证书体系，且大量使用自签名证书，选 Secure Channel 会更契合 Windows 的证书存储，否则直接保持默认 OpenSSL。绝大多数个人开发场景不会触碰这个选项。

行尾转换：这个选项很关键，选错了会让人抓狂。Windows 文件换行用 CRLF，Linux 和 macOS 用 LF。Git 默认支持三种模式：检出 Windows 风格、提交 Unix 风格；照原样检出、照原样提交；检出 Unix 风格、提交 Unix 风格。多数人会选第一个，即core.autocrlf=true，这样 Git 在提交时自动把 CRLF 转成 LF，检出时再转回 CRLF。如果你所在团队全用 Windows，也可以选第二项，完全不做转换。这块后面我单独展开讲，因为它是各种诡异 diff 的头号来源。

终端模拟器：Windows 下 Git Bash 有两种外观，MinTTY 和 Windows 默认控制台窗口。MinTTY 功能更强、支持中文更好，是新版默认。如果你发现 Git Bash 窗口里复制粘贴的快捷键和 cmd 不一致，或者显示异常，再切回 Windows Console 也不迟。这一项不影响 Git 本身的功能。

git pull 默认行为：新版本会问git pull默认用 merge 还是 rebase。如果你刚开始接触 Git，选默认的 merge 就行，它最直观：拉取时把远端提交合并到本地。rebase 会让历史更线性，但理解成本更高，不适合作为新手默认。

凭据管理器：Git Credential Manager 是默认选项，它解决了 HTTPS 方式推送时反复输入密码的问题。首次 push 到 GitHub 时，会弹出一个窗口让你授权，之后凭据被安全保存，不再重复询问。这个和 SSH 密钥是两套机制，后者不依赖凭据管理器。

2.3 安装完成后的自检

安装完成，我习惯做三件事验证。第一，打开 Git Bash，输入git --version，看到git version 2.x.x.windows.x就说明 Git 本体可用；第二，打开 PowerShell，输入where.exe git，确认 Git 被正确加入 PATH，正常情况下会输出 Git 安装目录下的cmd\git.exe；第三，在任意文件夹里右键，确认能看到“Git Bash Here”，这一步说明 shell 集成生效。

很多安装后“命令找不到”的问题，都出在 PATH 选项选得过窄，或者环境变量没刷新。修改完 PATH 之后一定要重启终端程序，VS Code 如果已经打开了也要完全关闭再重开，否则它持有的还是旧环境变量。这个坑我踩过很多次，改完配置后 VS Code 里依然提示 git 不是内部或外部命令，其实环境已经好了，只是终端没有重新读取。

3. 环境配置：把 Git 调整成顺手的状态

3.1 最优先执行的三个全局配置

安装只是第一步，真正让 Git 合手的是用户级配置。安装完成后打开 Git Bash，第一组命令是设置你的身份信息：

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

user.name和user.email会写进每一次提交里，别人在查看提交记录时看到的就是这两个信息。它和托管平台的用户名不是一回事，你可以给 GitHub 的账号设置一个完全不同的 Git 提交邮箱，只要这个邮箱是有效的就行，很多开发者为了避免垃圾邮件会使用 GitHub 提供的隐私邮箱。

检查配置是否正确：

git config --global --list

这个命令会显示所有全局配置项。如果发现哪一项写错了，可以重新执行git config --global user.name "新名字"覆盖。我见过有人跳过这一步，结果提交记录里显示的是一串系统自动生成的默认名字，团队里根本认不出是谁。

3.2 换行符、中文乱码和文件大小写

换行符问题是 Windows 上配 Git 最经典的坑。当团队里有人用 Windows、有人用 macOS、有人用 Linux 时，同一份文件到了不同系统，换行符可能被编辑器悄悄改变，然后 Git 就会认为整个文件都变了，diff 里全是红色删除和绿色新增，实际只改了一行。安装向导里的core.autocrlf选项就是用来缓解这个问题的。

git config --global core.autocrlf true

这条命令对应的是“检出 Windows 风格，提交 Unix 风格”。它的逻辑是：提交到仓库里的一律存成 LF，从仓库里检出到工作目录时再变成 CRLF。这样仓库内是统一的，Windows 工作区也不会因为换行符和编辑器冲突。但它的实现依赖 Git 对文件类型的判断，如果仓库里混有.bat、.ps1这类必须用 CRLF 的文件，或.sh这类必须用 LF 的脚本，自动转换偶尔会误判。

更稳的方式是在仓库根目录放一个.gitattributes文件：

* text=auto *.sh text eol=lf *.bat text eol=crlf *.ps1 text eol=crlf *.png binary

text=auto让 Git 自动处理文本文件，eol=lf强制指定脚本文件用 LF，eol=crlf指定批处理用 CRLF，binary告诉 Git 图片等文件不要做任何转换。这个文件本身也要提交到仓库，团队所有人共用，比每个人各自配置更可靠。如果你在团队里维护公共仓库，建议尽早加入.gitattributes，越晚历史里的换行符问题越难清理。

中文配置也有两个容易踩的点。仓库里的文件名如果是中文，在git status里可能显示成"\346\226\207\344\273\266.txt"这样的八进制转义，看着像乱码。这是因为 Git 默认对非 ASCII 字符做转义，但不影响文件本身，通过下面配置可以恢复中文名显示：

git config --global core.quotepath false

另外如果遇到提交信息中文乱码，可以考虑设置字符编码相关配置，但新版 Git for Windows 默认 UTF-8，绝大多数情况下不需要额外操作。真遇到乱码，先确认终端编码是不是 UTF-8，Git Bash 一般没问题，CMD 老窗口则可能要用chcp 65001临时切换。

3.3 几个提升体验的顺手配置

每次git init时默认分支名在旧版本里是master，新版本允许自定义。现在代码托管平台纷纷把默认分支改成main，为了保持一致，建议显式设置：

git config --global init.defaultBranch main

默认编辑器如果安装向导那一步没有设置，也可以手动补：

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

这条配置要求系统装了 VS Code，并且code命令已经在 PATH 中。执行git commit时如果没写-m，Git 会打开 VS Code 让你输入提交信息，保存并关闭窗口后提交继续。--wait参数的意思是等待编辑器进程结束再继续，没有它 Git 会以为你已经写完了。

其他我常用的配置：

git config --global pull.rebase false git config --global fetch.prune true git config --global alias.co checkout git config --global alias.st status git config --global alias.cm commit git config --global alias.lg "log --oneline --graph --decorate --all"

pull.rebase false是让git pull默认使用 merge 而不是 rebase，对新手更友好；fetch.prune true会在拉取时自动清理远程已经删除的本地分支记录；alias 则是给常用命令起别名，减少打字量。别名的用法是，配置完成后输入git st就相当于git status，输入git lg会看到一份带分支图和提交信息的紧凑日志。这些不是必需品，但确实能让日常操作流畅很多。

3.4 终端到底用 Git Bash、CMD 还是 PowerShell

Git Bash 和 Windows 自带终端在使用体验上的差别很大。Git Bash 提供了一整套接近 Linux 的环境，路径写法可以用/c/Users/xxx，支持ls、grep、sed等命令，对跟着教程学 Git 的人来说是最友好的。CMD 的批处理语法和路径转义方式会让很多 Git 命令变得别扭。PowerShell 功能强大，但它的ls其实是Get-ChildItem的别名，输出格式和 Linux 终端差异不小。

我的建议是：日常用 Git Bash，编辑器里把终端也切成 Git Bash。以 VS Code 为例，按Ctrl+Shift+P，输入Terminal: Select Default Profile，选择Git Bash，之后打开的终端就是 Git Bash 环境。这样做的好处是你学到的命令在不同工具中保持一致，不用为 Windows 的特殊语法分心。

4. SSH 密钥配置：免密连接代码托管平台的关键

4.1 为什么要用 SSH 而不是 HTTPS 来连接远程仓库

连接远程仓库常用协议有 HTTPS 和 SSH。HTTPS 地址形如https://github.com/user/repo.git，优点是开箱即用，浏览器里输一次账号密码就能克隆；缺点是在没有配置凭据管理器的情况下，每次 push 都要输入账号和 token，而且 GitHub 早在 2021 年就停止了密码直接 push 的方式，你必须用 Personal Access Token 当密码。SSH 地址形如git@github.com:user/repo.git，它通过密钥对完成身份认证，配置好之后，push 和 pull 都不需要再输密码，安全性也更高。

如果你只偶尔用一次 GitHub，HTTPS 完全够用；如果你和我一样每天要推几十次代码，配置一次 SSH 密钥的收益远大于成本。而且 SSH 配置好之后，同一套公钥可以加到 GitHub、GitLab、Gitea 等多个平台，一劳永逸。

4.2 生成 SSH 密钥：Ed25519 比 RSA 更推荐

打开 Git Bash，先检查一下是否已经有密钥：

ls -al ~/.ssh

如果里面存在id_ed25519和id_ed25519.pub，说明之前生成过，可以直接跳到下一节。没有的话，执行：

ssh-keygen -t ed25519 -C "你的邮箱" -f ~/.ssh/id_ed25519

解释一下每个参数：-t ed25519指定密钥类型是 Ed25519，它是目前安全性和性能都很优秀的非对称加密算法，生成的密钥短、处理快，比传统的 RSA 4096 更适合日常使用；-C "你的邮箱"是注释，通常写邮箱方便自己辨认；-f指定密钥保存位置，默认是C:\Users\你的用户名\.ssh\id_ed25519，不需要改就省略-f参数。

执行后会提示你设置 passphrase，也就是私钥口令。这个口令不是必须的，直接回车可以跳过，但我强烈建议至少给自己常用的工作电脑设置。为什么要设？因为私钥一旦泄露，没有口令的人仍然可以用它冒充你连接所有添加过对应公钥的平台；设置了口令，即使私钥文件被偷走，攻击者也无法直接用。代价是每次使用 SSH 时可能需要输一次口令，配合 ssh-agent 可以只在开机后输一次，后面就不用了。关于 ssh-agent 我这里先不展开，后面会提到。

生成完成后，查看公钥内容：

cat ~/.ssh/id_ed25519.pub

屏幕上会显示一行以ssh-ed25519开头、结尾是你邮箱的字符串，这就是需要添加到托管平台的公钥。注意id_ed25519.pub是公钥，可以公开；id_ed25519是私钥，除了你自己，谁都不能给。

4.3 把公钥添加到 GitHub 和 GitLab

以 GitHub 为例。登录后点击右上角头像，进入 Settings，在左侧菜单找到 SSH and GPG keys，点击 New SSH key。Title 字段填一个能提醒你这台设备用途的名字，比如my-windows-pc，Key type 选 Authentication Key，把刚才cat出来的公钥整段粘贴到 Key 框中，最后点 Add SSH key。GitLab 的入口在 Preferences 或用户设置里的 SSH Keys，本质上一样。

这里我有个习惯性建议：不要把整台机器的所有平台共用同一个密钥，但也不用每个平台单独生成一个。常见的做法是个人电脑生成一个密钥，添加到你所有个人常用的平台；公司电脑单独生成一个，只添加公司 GitLab 或 GitHub 企业账号。万一某个密钥泄露，影响面是可控的，撤销也很方便。

添加完成后，检查一下密钥是否被正确识别，直接测试连接：

ssh -T git@github.com

如果是第一次连接，会出现一句提示，问你是否确认信任某台主机，输入yes回车即可。GitHub 会返回：

Hi 你的用户名! You've successfully authenticated, but GitHub does not provide shell access.

看到这句话代表 SSH 配置成功。GitLab 的测试命令是ssh -T git@gitlab.com，返回的信息会说明你是哪个账号。如果返回的是Permission denied (publickey)，对照后面的常见问题排查。

4.4 ssh-agent 到底是干什么的

ssh-agent 是一个常驻后台的程序，负责保存已经解锁的私钥，让你在使用 SSH 时不用一遍遍输 passphrase。Git Bash 中启动并添加私钥的命令是：

eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519

第一条命令会启动 agent 并设置好环境变量，第二条命令把私钥加入 agent 内存缓存。执行第二条时需要输入一次 passphrase，之后当前终端会话内再使用 SSH 都不会询问。问题在于，重启电脑或重新打开一个终端后，agent 环境变量会丢失，又得重新添加。Git Bash 里可以在~/.bashrc末尾加上：

eval "$(ssh-agent -s)" >/dev/null 2>&1 ssh-add ~/.ssh/id_ed25519 2>/dev/null

这样每次打开 Git Bash 会自动启动 agent 并加载密钥。不过以我的经验，如果你没有给私钥设置 passphrase，或者能接受每次 SSH 操作输一次 passphrase，可以不用 agent，少一层配置也少一个变量。它更适合用同一台电脑频繁推送、又特别在意私钥保护的人群。

4.5 多账号场景：不同平台用不同密钥

实际开发中经常遇到一个场景：公司用 GitLab，个人用 GitHub，你想把两个平台的密钥分开管理。操作方法是为每个平台生成独立的密钥：

ssh-keygen -t ed25519 -C "邮箱A" -f ~/.ssh/id_ed25519_github ssh-keygen -t ed25519 -C "邮箱B" -f ~/.ssh/id_ed25519_gitlab

然后编辑~/.ssh/config文件，没有就新建一个：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github IdentitiesOnly yes Host gitlab.com HostName gitlab.com User git IdentityFile ~/.ssh/id_ed25519_gitlab IdentitiesOnly yes

IdentitiesOnly yes很重要，它让 SSH 只使用配置指定的私钥，而不是把所有 agent 里的密钥都尝试一遍。太多密钥同时存在时，不设置这一项可能会导致服务端拒绝认证。如果你还需要同时管理两个 GitHub 账号，可以给 Host 设置别名：

Host github-work HostName github.com User git IdentityFile ~/.ssh/id_ed25519_work IdentitiesOnly yes

注意此时克隆或设置远程地址时，要写成git@github-work:用户名/仓库.git，而不是git@github.com。否则 SSH 会优先匹配 Host 为github.com的配置块，别名就起不到区分作用了。Git 本身不会因为你改了 Host 名而影响推送，它只是把github-work当成一个连接别名。

5. 常见问题与排查实录

5.1 SSH 连接时报 Permission denied (publickey)

这是配置 SSH 后最常见的问题。先别急着怀疑人品，按顺序排查。第一步确认公钥是否真的添加到了托管平台，去网页端检查~/.ssh/id_ed25519.pub的内容和平台上的记录是否完全一致，注意粘贴时不要多出空格或换行。第二步用详细模式测试连接：

ssh -vT git@github.com

日志会显示 SSH 用了哪个私钥、服务端接不接受。重点看最后几行有没有Trying private key: ...和你私钥的路径。如果提示No such file or directory，说明-f生成时指定的路径和你现在查的不一致，或者~在当前终端里没展开。

还有一类情况是 Git for Windows 安装时选择了 Windows 内置 OpenSSH，而你在 Git Bash 里执行的ssh-keygen是系统路径的，密钥生成位置可能没问题，但私钥文件默认权限如果不对，Git 会直接拒绝使用。Windows 下可以通过右键私钥文件，属性，安全，确认只有你的用户有完全控制权限，多余用户全部移除。这个权限问题在把.ssh文件夹从其他电脑拷贝过来时尤其常见。

5.2 每次 push 都要输入用户名和密码

如果你已经配好 SSH 密钥，但git push仍然弹窗要求 GitHub 用户名和密码，首先要检查远程仓库地址是不是 HTTPS 开头的：

git remote -v

如果输出是https://github.com/...，那说明你根本没用 SSH 协议，密钥自然不参与认证。两种解决办法：一是改成 SSH 地址，git remote set-url origin git@github.com:用户名/仓库.git；二是继续用 HTTPS，但配置好 Git Credential Manager。如果你用的是新版 Git for Windows，默认已经安装了凭据管理器，推送时第一次弹窗授权，之后不会再问。如果你用的是 token 当密码，授权时用户名可以随便填，密码必须填 token，不能填账号密码，这是很多人在 HTTPS 方式下反复认证失败的原因。

如果是 SSH 地址但每次都提示输入 passphrase，说明私钥设置了口令而 ssh-agent 没有运行，用上一节的方式启动 agent 并添加私钥即可。

5.3 中文文件名显示成八进制乱码

git status里出现"\346\226\207..."而不是正常中文，这个问题的根源是 Git 默认对非 ASCII 字符进行转义，防止某些系统上文件名乱码。修复方法很简单：

git config --global core.quotepath false

配置后重新执行git status，中文文件名就能正常显示。如果 Git Bash 显示正常但 Windows 自带 CMD 乱码，大概率是 CMD 的代码页问题，执行chcp 65001切到 UTF-8 代码页，然后重新打开窗口。Git for Windows 默认安装的 MinTTY 终端通常不会遇到这个显示问题。

5.4 git 命令在 PowerShell 或 CMD 里提示不是内部或外部命令

这个问题绝大多数是 PATH 环境变量没配好。如果你在安装时选择了“仅从 Git Bash 使用 Git”，那么 Git Bash 里能用git，PowerShell 和 CMD 里不能用，这是预期行为，不是故障。如果你想要全局使用，需要手动把C:\Program Files\Git\cmd（以你的实际安装路径为准）添加到系统 PATH 环境变量。添加之后一定要重新打开终端。Windows 的环境变量设置界面里，点击“编辑”，新建一行，粘贴 Git 的cmd目录，确认保存。

还有一种少见情况是，系统 PATH 被某个软件改坏了，导致 Git 命令即使存在也不被找到。在 PowerShell 里执行$env:Path -split ';'看当前终端实际读取的 PATH，再对照系统设置界面里的值，大致能定位是哪一段出了问题。

5.5 换行符差异导致 diff 全红

克隆一个仓库后，只改了一行，但git diff显示整个文件都被修改了，这种问题我之前在不同系统间切换开发环境时遇到很多次。原因基本是换行符在 checkout 时被转换了，仓库里存的是 LF，工作区文件却因为某种原因变成了 CRLF，或者反过来。

先看当前仓库的 autocrlf 设置：

git config core.autocrlf

如果输出true，而仓库里声明了某些文件必须是 LF，两侧就会打架。最可靠的解法是补一个.gitattributes文件，把文件的换行符规则明确写死，提交后通知团队其他成员拉取。对已经出现全红 diff 的仓库，可以在确认没有未提交改动的前提下执行：

git add --renormalize . git commit -m "normalize line endings"

--renormalize会按照.gitattributes的规则重新处理文件的行尾，把仓库内文件统一成标准状态。这是一个相对高阶的操作，动手前一定要确保当前工作区没有未保存的修改。

5.6 克隆大仓库时反复中断

Git 克隆一个包含大量历史提交或大文件的大型仓库时，网络稍有波动就可能中断。如果仓库本身很大，可以考虑只克隆最近一次提交：

git clone --depth 1 git@github.com:user/repo.git

这叫浅克隆，它只拉取最新快照，不包含历史，适用于只需要最新代码、不需要看提交历史的场景。缺点是后续想查看历史提交时会缺失信息，需要额外git fetch --unshallow补全。还有一个临时性的做法是调整 Git 的 http 缓冲区大小和相关超时参数，但这属于在网络环境很不稳定时才用的兜底方案。如果你发现某个远程仓库总是卡在同一个进度点，优先怀疑网络对特定文件服务器节点不稳定，也可以试试通过镜像站或改用 HTTPS 地址连接。

5.7 安全软件拦截 Git 相关操作

Windows Defender 或第三方杀毒软件偶尔会拦截 Git 生成的可执行文件执行，尤其是当你从非官方渠道下载安装包，或者使用了一些自编译的 Git 工具时。如果你确定安装包来自官方，可以把 Git 安装目录加入杀毒软件的信任列表。另一个容易被忽略的是 SSH 私钥文件被安全软件扫描时行为异常，表现为 SSH 连接突然无法认证。遇到这类情况先撤销并重新生成密钥，同时检查最近安装的安全软件是否更新过策略。总的原则是只从可信渠道下载工具链，减少这类干扰。

6. 我实际配置 Git 环境时保留的一些习惯

6.1 新机器上手流程

我现在拿到一台新的 Windows 电脑，配置 Git 的流程基本固定。先装 Git for Windows，安装向导里 PATH 选第二项、SSH 用捆绑 OpenSSH、行尾选自动转换、默认编辑器选 VS Code，其他选项保持默认。装完打开 Git Bash 设置 user.name、user.email、init.defaultBranch、core.autocrlf、core.quotepath。然后生成一个 Ed25519 密钥，把公钥加到常用的托管平台。测试连接通过后，再安装和使用 VS Code，把默认终端切到 Git Bash。

这套流程看起来步骤多，实际上十五分钟以内就能走完。真正值得花时间的是理解每一步为什么这么做，而不是机械地敲命令。比如行尾转换和 SSH 密钥，前者决定了团队协作中 diff 是否干净，后者决定了你每天的推送是否顺畅。

6.2 一个容易忽略的备份习惯

密钥配置好之后，我建议你把~/.ssh目录里的公钥和私钥备份到一个安全的地方，可以是离线 U 盘或密码管理器。私钥设置了 passphrase 的情况下，备份私钥文件是相对安全的，因为外人拿到也没有口令。重装系统或换电脑时，你不需要重新生成一对新密钥并更新所有托管平台，直接把备份的私钥放回.ssh目录、修改权限、重新记录 known_hosts，就能恢复。我早期没有这个习惯，换电脑后被迫把所有公钥全部重新添加一遍，几个平台的入口位置还不一样，折腾了大半天。现在我把密钥文件位置、指纹、添加过哪些平台都记在一个文档里，方便以后快速恢复。

另外，每次升级 Git 版本后，最好在 Git Bash 里跑一下git --version和ssh -T git@github.com做快速验证。绝大多数升级不会影响现有配置，但如果你用了自定义终端主题或额外的脚本，升级后偶发不兼容也见过。保持一个“升级必验证”的习惯，比等到推送时才发现坏了再排查要省心得多。