企业官网建设流程全解析

前段时间帮一个刚接触技术协作的朋友配置 Windows 开发环境，他卡在 Git 安装之后的一连串问题上：环境变量不生效、提交时中文乱码、SSH 连不上远程仓库。整个过程踩下来，我发现网上很多教程要么只讲安装不配置，要么 SSH 部分一笔带过，真正从零到一、把每一步原理讲清楚的 Windows 教程其实不多。所以这篇我结合自己的实操经验，把 Git 在 Windows 上下载、安装、环境配置、SSH 密钥配完整写一遍，每一步都告诉你为什么这么做，以及我在实际环境里踩过哪些坑。

这篇内容适合刚接触 Git 的新手，也适合已经装了 Git 但对 SSH 密钥和命令行不太熟的开发者。无论你之后要往 GitHub、GitLab 还是 Gitee 推代码，这套流程都能直接复用。我会尽量写得像坐在旁边手把手带你的老同事一样，尽量不跳过任何一个可能卡的细节。

1. Windows 版 Git 的整体设计与选型思路

1.1 为什么 Windows 上装 Git 比看起来更讲究

很多人在 Windows 上第一次用 Git 时，会以为它只是一个“安装完就能用”的命令行工具。我刚开始也是这么想的，结果装完之后就遇到了第一个困惑：在 CMD 里敲git提示找不到命令，但 Git Bash 里又能用。后来才明白，Windows 下的 Git 和 Linux/macOS 下的 Git 有本质差别——它不是一个单独的可执行文件，而是“一个运行环境 + 一堆配套工具 + 系统集成”的组合体。

Windows 系统本身没有原生的类 Unix 环境，Git 又重度依赖 Shell、SSH 客户端、文本处理工具（比如grep、sed）。所以 Git for Windows 从设计之初就做了一个关键决定：打包一个完整的模拟环境，让你在 Windows 上能用接近 Linux 的方式操作 Git。这个模拟环境就是 Git Bash，它的核心是 MSYS2 提供的运行时，底层的 shell 是 Bash，所有工具链都编译成 Windows 原生程序。

理解了这一点，你就知道为什么官方安装包里有那么多看起来“莫名其妙”的选项。这些选项本质上是在问：你希望 Git 的 Unix 环境和 Windows 原生系统以什么方式共存。选择不同，直接影响你以后在 CMD、PowerShell、VS Code 等场景下使用 Git 的顺畅程度。

1.2 Git for Windows、MinGW 与 MSYS2 的区别

如果你去 Git 官网下载，会发现安装包名称里有MinGW64字样。很多新手会困惑：我到底在装 Git，还是在装编译器套件？这里我用自己的理解解释一下：

• Git for Windows 是一个“发行版”，它的目的是让你在 Windows 上运行 Git，因此它把 Git 本体、Bash、常用 Unix 工具都打包在一起。
• MinGW 是“Minimalist GNU for Windows”，提供了一组在 Windows 上运行 GNU 工具链的库和编译器。Git for Windows 里很多原生程序是用 MinGW 编译的，这样执行效率比通过模拟层更高。
• MSYS2 是提供一个 POSIX 兼容层，让需要 Unix 行为的程序能在 Windows 上跑。Git Bash 中的/usr/bin下那些命令，就是通过 MSYS2 环境提供的。

简单类比就是：你装的是 Git，但它附带了一个“翻译层”和一批“外援工具”，让你在 Windows 上也能像在 Linux 终端里一样写ls、pwd、grep，命令行体验比 CMD 舒服得多。

1.3 为什么现代 Windows 开发更推荐用 Git Bash 而非纯 CMD

我之前有段时间习惯用 PowerShell 操作 Git，后来切回 Git Bash，体验差别很明显。Git Bash 自带命令补全、颜色高亮、历史搜索，而且很多开源项目的脚本（比如.sh脚本、自动部署脚本）默认假设你在类 Unix 环境运行，Git Bash 能直接执行，CMD 则经常因为编码和语法问题报错。

更关键的是 SSH 相关操作。生成密钥、添加密钥、测试连接这一套流程，Git Bash 里的ssh-keygen、ssh-agent、ssh -T不仅可用，而且和服务器端交互的兼容性最好。你用 CMD 里的ssh也不是不行，但一旦遇到密钥格式、权限之类的老问题，排查起来更麻烦。所以我用了这么久 Windows 开发环境，原则就一条：和 Git 相关的命令，一律在 Git Bash 里运行。

2. Git 下载与安装：一步步避开默认陷阱

2.1 下载安装包时怎么确认拿到的版本

Git 官方下载页面会自动识别你的系统，一般会给你推荐 64 位 Windows 的安装包。我通常建议下载最新稳定版，因为 Git 团队不仅修 bug，还会持续调整底层 OpenSSL、cURL 这些安全组件，旧版本在连接 GitHub 或者公司自建的 GitLab 时，有时会因为 TLS 协议版本过低而失败。

需要注意一点：国内直接连官网下载偶尔会慢，如果遇到这种情况，可以去国内的开源软件镜像站下载。下载后先核对文件名里的版本号和位数，例如Git-2.46.0-64-bit.exe这样格式的文件名就是官方标准命名。不要下载名字里带portable的绿色版，除非你明确知道自己需要便携安装，否则标准安装包在后续配置系统集成时省心很多。

2.2 安装向导中每个关键选项该怎么选

安装过程基本都是 Next，但中间有 4 个界面值得你停下来认真看一眼。我逐个说明：

选择安装路径

第一条就是选择安装路径。我的建议是保持默认的C:\Program Files\Git，不要为了省 C 盘空间装在带中文的路径里，比如D:\软件\Git。Git 内部大量脚本对路径有硬编码假设，中文路径或者带空格的路径在某些边缘场景下会触发诡异的问题。如果你确实要换盘，也请用全英文路径，比如D:\DevTools\Git。

选择组件（Select Components）

默认选项里有一项Additional icons（在桌面创建图标），这项对我来说没有用，我会取消。真正需要注意的选项是Git Bash Here和Git GUI Here，这两个是右键菜单集成，建议保留。右键菜单虽然不能直接提高 Git 的使用效率，但有时候你打开资源管理器，想快速在当前目录开终端，这个入口非常方便。还有个选项Scalar，这是微软贡献的大规模仓库管理工具，如果你不参与超大型 monorepo 项目，可以不开，它对普通开发没有明显影响。

选择默认编辑器

安装向导会让你选 Git 默认使用的文本编辑器。如果你装了 VS Code，我极推荐选Use Visual Studio Code as Git's default editor，因为 Git 在提交代码时如果遇到冲突或者需要写多行提交信息，会调用默认编辑器。VS Code 对中文支持、对冲突标记的高亮都做得很好，比默认的 Vim 对新手友好太多。如果你现在还没装 VS Code，可以先选Use Notepad++，之后可以在配置里随时改。

调整 PATH 环境变量

这是整个安装过程中最重要的一步，没有之一。向导会给你三个选项：

• Use Git from Git Bash only：只在 Git Bash 里使用 Git。
• Git from the command line and also from 3rd-party software：将 Git 添加到系统 PATH，CMD 和 PowerShell 里都能直接用。
• Use Git and optional Unix tools from the Command Prompt：不仅把 Git 加进 PATH，还把一堆 Unix 工具也加进去。

我强烈建议选第二个。选第一个的话，你在 VS Code 的终端里如果默认 shell 是 PowerShell，敲git有可能提示找不到；选第三个又太激进，find、sort这些 Unix 命令会覆盖 Windows 同名命令，可能会影响其他软件的运行。选第二个是“Git 可用，系统不受干扰”的最优解。

2.3 换行符转换与凭据管理器的选择

安装过程中还有一个容易被忽略的界面，就是Configuring the line ending conversions，也就是换行符转换方式。Windows 的文本行尾是 CRLF（回车+换行），Linux/macOS 是 LF（仅换行）。如果不同系统之间提交代码不处理这个差异，Git 会在 diff 里显示整个文件都被修改了，特别闹心。

三个选项的含义分别是：

• Checkout Windows-style, commit Unix-style line endings：检出时转 CRLF，提交时转 LF。这是推荐选项，适合绝大多数跨平台开发场景。
• Checkout as-is, commit Unix-style line endings：检出时保持原样，提交时统一为 LF。
• Checkout as-is, commit as-is：完全不转换。

如果你是一个人开发，项目也只跑在 Windows 上，选第三项也不是不行。但只要你有任何把代码部署到 Linux 服务器、或者和用 macOS 的同事协作的可能，就选第一项。这个设置在安装之后也能改，但安装时选对能少踩很多坑。

然后是凭据管理器（Credential Manager）的选项。默认的Git Credential Manager会接管你的 HTTP/HTTPS 身份验证，在你推送到 GitHub 或 GitLab 时弹出一个登录窗口，帮你保存令牌，下次就不用重新输。这个功能默认开启是好事，但我要提醒一点：它会缓存凭据，如果你在命令行输入过密码，之后换账号推代码可能会被缓存的旧凭据挡一下。遇到这种情况，去 Windows 凭据管理器里删掉对应条目即可。

2.4 安装完成后的验证与环境变量检查

安装完成后，打开一个全新的 CMD 或 PowerShell（注意：必须新开，因为环境变量只在新的终端进程里才会刷新），输入：

git --version

如果输出类似git version 2.46.0.windows.1，说明 Git 已经正确安装。如果提示找不到命令，先别慌，按 Win 键搜索“编辑系统环境变量”，打开“环境变量”窗口，在“系统变量”的 Path 里确认是否有C:\Program Files\Git\cmd这一条。没有的话手动添加。这里多说一句，环境变量改完后，所有已经打开的终端窗口都不会自动刷新，必须全部关掉重新开，这是我之前反复踩的坑。

另外一个验证角度是检查右键菜单。在任意文件夹里按住 Shift 点击右键，如果能看到Open Git Bash here，说明 shell 集成也正常工作。

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

3.1 用户信息配置：提交记录的“身份证”

Git 安装完成的瞬间，它并不知道你是谁。你每次提交代码，Git 会把用户姓名和邮箱写入提交记录里，这个信息会成为代码历史的一部分，将来在 Git 记录、代码评审工具里都会显示。

配置方法是打开 Git Bash，依次执行：

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

这里有两个容易踩的坑。第一，--global是“全局生效”，对当前 Windows 用户的所有仓库有效；如果你在某一个仓库里需要不同的身份，可以在那个仓库目录下执行不带--global的同样命令，实现仓库级覆盖。第二，邮箱尽量用你注册代码托管平台时使用的邮箱，否则你的提交不会被平台关联到你的账号上。如果你在乎 GitHub 的贡献图（那个绿色小方块），就一定要保证邮箱和 GitHub 账号里验证过的邮箱一致。

3.2 换行符与编码问题的进阶配置

安装向导已经帮你设好了换行符策略，但有一个编码问题它管不了，那就是 Windows 中文环境下的文件名编码问题。你在 Windows 上创建的文件名是 GBK 编码，而 Git 默认按 UTF-8 处理，于是在git status里你会看到中文文件名的路径被转义成一堆八进制数字，像"\345\274\200..."这样的东西。

解决方案是设置：

git config --global core.quotepath false

这个配置让 Git 在显示中文路径时直接输出原始字符，而不是转义后的八进制序列。这个方法对 Git Bash 里的显示和命令行输出都有效，设置完之后看git status的体验会立刻改善。

3.3 默认分支名：从 master 到 main

过去新建 Git 仓库默认分支叫master，近几年业界主流的代码托管平台都转向main。Git 在 2.28 版本之后允许你自定义默认分支名。如果不想每次创建仓库后再手动git branch -M main，可以执行：

git config --global init.defaultBranch main

这个配置对新建仓库生效。我建议刚接触 Git 的朋友直接设置成main，因为 GitHub 上新建远程仓库时默认分支就是main，本地和远程保持一致，能少很多困惑。

3.4 别名配置：高频命令缩短输入

Git 命令虽然不算长，但像git checkout、git commit --amend这种高频组合，敲起来还是有点累。我平时会配置几个别名：

git config --global alias.st status git config --global alias.co checkout git config --global alias.ci commit git config --global alias.br branch git config --global alias.lg "log --oneline --graph --all --decorate"

配置完之后，git st就能查看状态，git lg能输出一张清晰的提交历史图。这个配置纯属提升效率，不配也没关系，但配了之后确实回不去。

3.5 配置文件的存放位置与管理思路

上面所有git config --global的配置，最终都写在一个文件里：C:\Users\你的用户名\.gitconfig。你可以直接用文本编辑器打开它，它的内容大概长这样：

[user] name = 你的名字 email = your@email.com [core] quotepath = false [init] defaultBranch = main [alias] st = status

了解这个文件的位置之后，你就能理解“Git 配置没那么神秘”，本质上就是文本文件。如果你想快速迁移到新电脑，把这个文件备份过去，再装好 Git，你的所有全局配置就都带过去了。

4. SSH 密钥生成与远程仓库连接

4.1 为什么你大概率需要 SSH 方式

Git 连接远程仓库有两种主流方式：HTTPS 和 SSH。

HTTPS 方式配置简单，克隆仓库时直接填地址就行，但每次推送代码都要验证身份。虽然 Git Credential Manager 会帮你记住凭据，但对一些不喜欢弹窗、或者希望在纯命令行环境里操作的人来说，还不够优雅。

SSH 方式的核心思路是：你生成一对密钥（公钥和私钥），把公钥放到 GitHub/GitLab/Gitee 上，之后每次连接时，服务器通过密钥配对来识别你的身份，不再需要输密码。这个过程对用户是透明的，推送代码时体验和本地操作几乎没有区别。

对我来说，SSH 还有一层好处：公司内网的 GitLab 通常只开放 SSH 端口访问，很多服务器拉代码也只接受 SSH 协议。所以早点把 SSH 配好，后面很多场景都能直接复用。

4.2 生成密钥前需要确认的环境条件

生成密钥用的是ssh-keygen命令。这个命令在 Git Bash 里自带，不需要额外安装。可以先用这个命令确认可用：

ssh-keygen -v

如果有版本号输出，就直接用。另外，先检查一下自己是否已经生成过密钥，避免覆盖旧密钥：

ls -la ~/.ssh/

如果这个目录下已经有id_ed25519和id_ed25519.pub之类的文件，说明之前配置过密钥。此时如果你想复用旧密钥，就跳过生成步骤；如果想换新密钥，继续操作即可，但要注意旧密钥关联的远程仓库会有影响。

4.3 生成 SSH 密钥：算法与参数选择的经验

执行生成命令：

ssh-keygen -t ed25519 -C "your_email@example.com"

其中：

• -t ed25519指定用 Ed25519 算法。这是目前我推荐的算法，密钥短、安全性高、生成速度快，GitHub 和主流 GitLab 都支持。如果有些老旧的 GitLab 版本不支持，再退回-t rsa -b 4096生成 RSA 密钥。
• -C后面通常填你的邮箱，它只是给密钥加一个备注，方便你在服务器上辨认哪把钥匙是谁生成的，不影响功能。

回车后，终端会问你保存路径。默认是C:\Users\你的用户名\.ssh\id_ed25519，直接回车确认即可。接着会让你输入一个 passphrase（口令短语）。这个不是必填项，留空的话以后每次连接都不用输入，但私钥如果有人拿到，就能直接冒用你的身份。我的建议是：个人电脑上留空或设置一个简单的 passphrase 都可以，但如果这是公司的开发机，强烈建议设置 passphrase，而且用系统自带的 ssh-agent 帮你记住，避免每次都要输。

4.4 把公钥添加到托管平台

生成密钥后，需要把公钥内容复制出来。公钥文件的路径是~/.ssh/id_ed25519.pub，注意是.pub后缀。你可以用下面的命令直接输出内容：

cat ~/.ssh/id_ed25519.pub

输出的内容是一段以ssh-ed25519开头、以你的邮箱结尾的字符串，这就是公钥。复制这段完整内容，然后：

• GitHub：右上角头像 → Settings → SSH and GPG keys → New SSH key → 粘贴 → Add SSH key。
• GitLab：头像 → Preferences → SSH Keys → 粘贴 → Add key。
• Gitee：头像 → 设置 → SSH 公钥 → 粘贴 → 确定。

这里我提醒一句：公钥可以公开，但私钥（就是没有.pub后缀的那个文件）绝对不要发给任何人，也不要粘贴到网上的任何地方。如果你怀疑私钥泄露，立即重新生成一对并把旧公钥从平台移除。

4.5 配置 ssh-agent 免去重复输入口令

如果你在生成密钥时设置了 passphrase，会发现每次推送代码都被要求输入一次。Windows 上让 ssh-agent 记住密钥的方法是：

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

执行ssh-add时会让你输入一次 passphrase，输入后这个会话里就不再需要了。不过 Git Bash 每次关闭后，agent 会话会消失，下次又要重新执行。想要一劳永逸，可以执行：

ssh-add -K ~/.ssh/id_ed25519

这个命令在 Windows 的 Git Bash 里会尝试把 passphrase 写入系统的凭据管理器，让 Windows 自己管理，重启后也能生效。不同版本的 Git Bash 对这个参数的支持略有差异，如果提示找不到-K，就用上一条命令配合手动启动 agent 的方式。

4.6 测试 SSH 连接：确认密钥是否生效

配置好之后，用下面的命令测试是否能连上 GitHub：

ssh -T git@github.com

如果你用的是 GitLab，把域名换成你的 GitLab 地址：ssh -T git@gitlab.com。第一次连接时，终端会提示你确认远程主机的指纹（fingerprint），输入yes回车。这个提示是在确认你连的服务器不是伪造的，正常情况下一定要输yes，之后这个地址会被写入~/.ssh/known_hosts，下次就不会再问了。

如果配置成功，GitHub 会返回类似这样的内容：

Hi your-username! You've successfully authenticated, but GitHub does not provide shell access.

看到这句话说明 SSH 链路已经通了。接下来你在克隆仓库时，使用 SSH 格式的地址：

git clone git@github.com:你的用户名/仓库名.git

之后推送代码就不会再要求输入密码了。

4.7 多平台多账号的 SSH 配置方法

如果你同时使用 GitHub 和 GitLab，或者在公司 GitLab 使用一个账号、个人 GitHub 使用另一个账号，就不能让所有请求都走同一个密钥。此时需要在~/.ssh/目录下创建config文件（注意没有扩展名），内容范例如下：

# GitHub 个人账号 Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github # 公司 GitLab Host gitlab.company.com HostName gitlab.company.com User git IdentityFile ~/.ssh/id_ed25519_company

然后生成密钥时，要在文件名上区分开：

ssh-keygen -t ed25519 -C "personal@email.com" -f ~/.ssh/id_ed25519_github ssh-keygen -t ed25519 -C "company@email.com" -f ~/.ssh/id_ed25519_company

这个Host配置实际上是 SSH 客户端的标准能力，和 Git 本身无关。Git Bash 里的 SSH 会读取~/.ssh/config，Git 发起 SSH 连接时也会自动遵循。这个配置改完后，无需重启任何服务，新连接立即生效。

5. 常见问题与排查技巧实录

5.1 SSH 连接提示 Permission denied (publickey)

这是 SSH 配置时碰到最多的错误。终端提示git@github.com: Permission denied (publickey)，先不要急着重新生成密钥，按照下面的顺序排查：

1. 确认公钥是否已经添加到平台：在 GitHub 上检查Settings → SSH and GPG keys是否能看到你的公钥。
2. 确认你连的就是刚才添加公钥的那个账号：用ssh -T git@github.com测试，看返回的用户名是不是你预期的人。
3. 确认 ssh-agent 中加载了正确的密钥：执行ssh-add -l，如果列表是空的，执行ssh-add ~/.ssh/id_ed25519。
4. 检查~/.ssh/config中IdentityFile的路径是否正确：路径写错是最隐蔽的问题，配置文件里多一个空格或者路径写错一个字母，都会导致认证失败。

我之前遇到最奇怪的一次是，明明公钥、私钥、平台配置都正常，但ssh -T就是失败，最后发现是因为 Windows 的HOME环境变量被改到别的目录了，SSH 根本读不到我的密钥文件。在 Windows 上，SSH 寻找密钥的路径取决于HOME或USERPROFILE环境变量，如果两者不一致，就会出问题。排查方法很简单：

echo $HOME echo $USERPROFILE

正常情况下两者应该指向同一个目录，比如C:\Users\你的用户名。如果不一致，把HOME手动修正为C:\Users\你的用户名，再重开 Git Bash 测试。

5.2 连接时提示 Host key verification failed

这个提示出现在你重新安装系统、或者远程服务器的密钥指纹发生变化时。之前保存的 known_hosts 信息和当前服务器的不匹配，SSH 出于安全考虑会拒绝连接。

解决办法是删除 known_hosts 中对应服务器的旧指纹记录。Git Bash 里执行：

ssh-keygen -R github.com

这个命令会移除 github.com 的旧记录。删除后重新ssh -T git@github.com，会再次提示确认指纹，输入yes即可。注意-R的R是大写，小写-r是其他含义，别搞混。

5.3 密钥格式错误或换行导致认证失败

从 Windows 上复制公钥内容时，有时会把换行符也复制进去。在网页上添加公钥时，粘贴内容中如果包含了额外的换行、或者多了一个空格，平台会把它当成一个格式非法的密钥来存储。你测试连接时就会直接报 key 错误。

我的习惯是复制公钥时用这条命令直接输出，不要在资源管理器里用记事本打开公钥文件再全选复制，因为记事本默认编码和换行可能在复制时引入不可见字符：

cat ~/.ssh/id_ed25519.pub | clip

| clip是 Windows 特有的管道命令，把前一个命令的输出直接复制到剪贴板。这样复制出来的公钥内容最干净，不会夹杂换行和多余字符。

5.4 Windows 凭据管理器里的旧凭据干扰登录

使用 HTTPS 方式推送代码，如果换过账号，可能会遇到 Git Credential Manager 一直弹旧账号的登录窗口，或者明明输入了新密码还是认证失败。这是因为凭据管理器里缓存了旧凭据，优先级比新输入的还高。

解决方法是打开 Windows 的“控制面板” → “凭据管理器” → “Windows 凭据”，在列表里找到git:https://github.com这样的条目，展开并点击“删除”。删除后再次推送代码，Git 会重新弹出登录窗口，这时输入新账号的凭据即可。

5.5 安装后 Git 命令在 VS Code 终端里找不到

这种情况通常是安装时选择了Use Git from Git Bash only，也就是没有把 Git 加入 PATH。VS Code 的集成终端默认使用 PowerShell，而 PowerShell 不会自动加载 Git Bash 的路径。

解决办法有两个：要么在系统环境变量里手动添加C:\Program Files\Git\cmd（推荐，一劳永逸）；要么在 VS Code 的设置里把默认终端改为 Git Bash。前者的好处是不止 VS Code，所有 Windows 程序都能调用git命令。修改完环境变量后记得完全重启 VS Code，不是重新加载窗口，而是彻底退出再打开。

5.6 中文文件名显示为八进制转义

这个问题前面提到过，对应解决办法是设置core.quotepath false。但如果你设置了之后依然看到"\345\274\200"，有两个可能：一是你设置的不是全局配置，当前仓库有自己的本地配置覆盖了它；二是你在 CMD 里执行，而 CMD 对 UTF-8 的显示支持不好。解决方案是统一在 Git Bash 里配置和查看，并且确认：

git config --global --get core.quotepath

输出应该是false。如果这个命令没有输出，说明配置没写进去，重新执行一次git config --global core.quotepath false。

5.7 Git Bash 运行命令时较慢或卡死

有时候 Git Bash 里的命令执行会出现卡顿，比如 Tab 补全要等好几秒。很大概率是 Windows Defender 实时扫描导致的。Git Bash 每次执行命令都会调用大量临时文件，杀毒软件逐个扫描就会变慢。

如果你确认自己的开发机环境可靠，可以考虑把 Git 的安装目录（比如C:\Program Files\Git）加入 Windows Defender 的排除列表，或者至少把%USERPROFILE%\.ssh和常用代码目录排除掉。这一步纯粹看个人安全取舍，我在公司电脑上这样做过，确实能明显感觉到命令响应变快。

6. 在 Windows 上使用 Git 的几条实操心得

6.1 工作目录尽量避开 OneDrive 云同步目录

现在很多 Windows 电脑默认开启了 OneDrive，并且把“桌面”、“文档”这些文件夹同步到云端。如果你把 Git 仓库建在这些目录下，Git 每次读写文件时，OneDrive 都会同步一次，轻则产生大量无效 IO，重则导致 Git 的锁文件（.git/index.lock、.git/shallow.lock）被同步软件干扰，出现莫名奇妙的“Unable to create ... .lock”报错。

我的建议是，开发代码统一放在一个非同步的盘符下，比如D:\Projects或C:\Code。如果你的代码已经在 OneDrive 目录里，最好在动手开发前先移出来。这个坑一旦踩上，排查起来非常费时间，因为报错内容完全看不出来和云同步有什么关系。

6.2 升级 Git 版本前先看看 release notes

Git 版本升级通常很平滑，但偶尔会有不兼容的变化。比如某些旧版本的git flow扩展在高版本上需要重新安装，某些 CI 脚本依赖的git log输出格式在高版本可能调整。如果你在公司环境工作，升级前先看看项目的 CI 脚本是否依赖 Git 的具体行为，再决定是否要跨多个大版本升级。

我个人习惯是保持 Git 在较新的版本，但从不追“当天发布当天升级”。等一周左右，如果社区没有大面积反馈问题，再升级也不迟。

6.3 用git config --list检查配置生效情况

遇到任何“行为和预期不一致”的情况，第一步就是检查当前配置。在仓库目录下执行：

git config --list --show-origin

输出会带出每条配置的来源文件路径（比如全局.gitconfig、系统级配置、仓库内.git/config），一眼就能看出是哪一层的配置在生效。这个命令我几乎每天在用，尤其是排查用户信息不对、换行符策略失效这类问题，非常管用。

6.4 养成提交前先git status的习惯

不管配置多完善，都不要凭感觉提交代码。每次提交前，执行git status看看工作区里有哪些改动，有没有误改的文件。如果有不想提交的文件，提前用.gitignore排除，别把node_modules、target、__pycache__这类目录提交到仓库里。.gitignore的规则不复杂：每行一个匹配模式，*表示任意字符，/开头表示相对目录。可以参考各平台维护的通用.gitignore模板，但最终要以自己的项目实际为准。

6.5 Windows 与 WSL 环境下的重复配置问题

如果你和我一样，电脑上同时装了 WSL（Windows Subsystem for Linux），可能已经发现 Git 的配置在 Windows 和 WSL 里是分开的。Windows 侧的 Git 读取C:\Users\你的用户名\.gitconfig，WSL 里的 Git 读取 Linux 文件系统下的~/.gitconfig。两边不互通，但如果都要用，就得分别配置一遍。

一个省事的做法是：在 WSL 里执行 Git 命令时，通过 WSLENV 把 Windows 侧的用户信息传过去，或者直接在 WSL 的配置文件里写同样的内容。我个人体验是，如果主力开发在 Windows 侧，WSL 只用来编译或跑脚本，那两套配置即使有差异也问题不大；但如果你的代码工作流集中在 WSL 里，建议以 WSL 侧配置为准，Windows 侧保持最小配置即可。

7. 后续还可以扩展的 Git 技能方向

7.1 从命令行到图形工具的选择

我上面讲的都是命令行操作，因为命令行是 Git 的基础，理解了命令行之后，用任何图形工具都更踏实。但对 Windows 用户来说，有些场景图形工具确实更直观，比如查看提交历史图、处理冲突。

官方自带的git gui和gitk可以临时用用，功能比较简单。我见过很多同事用 VS Code 自带的源代码管理面板配合命令行使用，日常操作效率很高。如果你喜欢更专注的 Git 客户端，市面上也有一些成熟选择，但我的建议永远是：图形工具可以做辅助，但核心原理和命令要掌握，因为代码托管平台的文档、自动化脚本、CI 环境里只有命令行。

7.2 分支管理策略值得花时间研究

Git 命令本身好学，真正决定团队协作效率的是分支管理策略。常见的模型包括 GitHub Flow（主分支即稳定分支，功能分支合并回主分支）、Git Flow（更正式的分支划分，有 develop、release、hotfix 分支）、以及一些轻量级的 trunk-based 开发方式。

不管你选哪种模型，操作层面都依赖 Git 的分支、合并、变基这套基本功。其中变基（rebase）和合并（merge）的区别，是我觉得每个 Git 使用者都应该搞清楚的。简单说，merge 保留每次分支合并的现场记录，提交历史会多一些分叉；rebase 把当前分支的提交“移植”到目标分支之上，历史更线性。在多端协作时，rebase 可以避免不必要的合并提交，但如果你已经把自己的分支推送到远程并且其他人正在用它，就不要轻易 rebase，否则会影响别人的工作副本。这个原则，实操两次就会深有体会。

7.3 进阶：用 Git Hooks 做自动化检查

当你的项目规模大起来、协作的人多起来，可以考虑用 Git Hooks 做一些自动化检查。Git Hooks 是 Git 在某些关键节点（比如提交前、推送前）自动执行的脚本，放在仓库的.git/hooks/目录下。虽然默认目录里的脚本都是示例，但你可以替换成自己的逻辑。

例如，在pre-commit钩子里运行代码格式化检查，在pre-push钩子里运行测试用例，能避免很多低级问题被推到远程。不过要注意，.git/hooks/目录里的脚本默认不会提交到远程仓库，团队成员需要各自复制。如果你想统一管理，可以使用core.hooksPath配置把钩子目录指向项目内的一个独立目录，然后把这个目录纳入版本控制。

这个方向属于锦上添花，新手期不用急着碰，但当你想把工程质量往前推一步时，Git Hooks 是一个低成本的切入点。

写在最后

写了这么多，其实 Git 在 Windows 上的安装配置并不复杂，复杂的是那些跨平台边界上的细节。我见过太多人卡在 SSH 认证、换行符、编码这些“软问题”上，看起来像是配置错误，实际上是环境层面的认知盲区。希望这篇能把那些容易踩的坑提前标注清楚，让你在真正遇到之前就有应对思路。如果你按照步骤配置完成，记得先在一个测试仓库里走一遍克隆、修改、提交、推送的完整流程，确认没问题之后再把自己的真实项目迁过来。我自己每次在全新电脑上配置 Git，还会额外复查一遍~/.ssh/config和全局.gitconfig，确认没有历史遗留的旧配置在暗地里捣乱——这套流程用熟了，配置一次基本十分钟内能搞定。