前段时间帮一个刚接触技术协作的朋友配置 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 Gits 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 添加到系统 PATHCMD 和 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 youremail.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_emailexample.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 连接确认密钥是否生效配置好之后用下面的命令测试是否能连上 GitHubssh -T gitgithub.com如果你用的是 GitLab把域名换成你的 GitLab 地址ssh -T gitgitlab.com。第一次连接时终端会提示你确认远程主机的指纹fingerprint输入yes回车。这个提示是在确认你连的服务器不是伪造的正常情况下一定要输yes之后这个地址会被写入~/.ssh/known_hosts下次就不会再问了。如果配置成功GitHub 会返回类似这样的内容Hi your-username! Youve successfully authenticated, but GitHub does not provide shell access.看到这句话说明 SSH 链路已经通了。接下来你在克隆仓库时使用 SSH 格式的地址git clone gitgithub.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 personalemail.com -f ~/.ssh/id_ed25519_github ssh-keygen -t ed25519 -C companyemail.com -f ~/.ssh/id_ed25519_company这个Host配置实际上是 SSH 客户端的标准能力和 Git 本身无关。Git Bash 里的 SSH 会读取~/.ssh/configGit 发起 SSH 连接时也会自动遵循。这个配置改完后无需重启任何服务新连接立即生效。5. 常见问题与排查技巧实录5.1 SSH 连接提示 Permission denied (publickey)这是 SSH 配置时碰到最多的错误。终端提示gitgithub.com: Permission denied (publickey)先不要急着重新生成密钥按照下面的顺序排查确认公钥是否已经添加到平台在 GitHub 上检查Settings → SSH and GPG keys是否能看到你的公钥。确认你连的就是刚才添加公钥的那个账号用ssh -T gitgithub.com测试看返回的用户名是不是你预期的人。确认 ssh-agent 中加载了正确的密钥执行ssh-add -l如果列表是空的执行ssh-add ~/.ssh/id_ed25519。检查~/.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 gitgithub.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 notesGit 版本升级通常很平滑但偶尔会有不兼容的变化。比如某些旧版本的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 环境下的重复配置问题如果你和我一样电脑上同时装了 WSLWindows Subsystem for Linux可能已经发现 Git 的配置在 Windows 和 WSL 里是分开的。Windows 侧的 Git 读取C:\Users\你的用户名\.gitconfigWSL 里的 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确认没有历史遗留的旧配置在暗地里捣乱——这套流程用熟了配置一次基本十分钟内能搞定。