直接开始不绕弯子。标题是《git的安装和使用windows》但我得先说一句在Windows上装Git大部分人其实卡在了“安装之后”。点Next谁都会真正让你头疼的是换行符替你改了文件、SSH连不上、提交记录里署错名、中文路径乱码这些烂事。这篇文章我会把安装过程、初始配置、日常命令、分支合并、排错这五个阶段全部过一遍重点放在Windows环境下你一定会遇到的坑和对应的处理办法。1. 第一步选型为什么 Windows 上装 Git 会牵扯到一堆“版本”先别急着下载搞清楚你装的是什么东西。Windows上不能直接跑Linux那套Git所以Git官方提供的是基于MSYS2环境编译的版本Git for Windows就是最主流的那个。你可能在下载页见过“MinGit”“PortableGit”“Git for Windows Setup”这些选项它们本质上是同一套东西的不同打包形式Git for Windows Setup官方安装包平时装机用这个就行自带Git Bash、Git GUI、SSH客户端、系统PATH注入一套全齐。PortableGit便携版解压即用适合不想要安装器、放在U盘里到处跑的人但不会自动配置PATH和右键菜单。MinGit最小版只有git.exe和核心依赖一般给IDE或自动化工具内嵌用不适合人类日常操作。1.1 MSYS2/MinGW 构建与 Cygwin 构建的本质区别Windows上跑Git这类命令行工具有两条技术路线理解这个你以后就不会被各种“Git Bash怎么这么怪”“为什么在CMD里报错”的问题整懵。Cygwin路线是模拟一个完整的POSIX层把Linux的系统调用翻译成Windows调用对开发者是最友好的但性能差、体积大像一个虚拟机里跑着半套Linux。MSYS2/MinGW路线是直接用GCC编译C代码到Windows原生程序运行时库尽量最小化Git for Windows选的就是这条路。Git Bash本质上是MSYS2提供的一个类似于Unix终端的模拟环境它支持大部分Linux常用命令ls、grep、sed、awk这些也能跑bash脚本但底层全部是Windows进程。这个区分的实操意义是Git Bash里能用的命令不代表CMD和PowerShell里就能用。比如你在Git Bash里敲ls没问题切到CMD敲ls报错这不是Git坏了是CMD根本不认识ls。反过来Git Bash里访问Windows路径要用斜杠转换规则比如C:\Users\YourName在Git Bash里通常写成/c/Users/YourName。1.2 32位还是64位其实没你想的那么纠结现在下载页默认给你64位版本机器内存小于4G的老电脑才需要考虑32位。更需要注意的其实是另外一个选项在安装向导的“Select Components”页面务必保持默认勾选Git Bash Here和Git GUI Here这两个选项决定了右键菜单里能不能直接出现“Open Git Bash here”和“Open Git GUI here”。很多人在这一步为了“表面清爽”把右键菜单取消结果后面每次都要从开始菜单启动再cd到项目目录纯粹给自己找罪受。1.3 安装向导里那些容易忽略的选项安装过程大部分点Next就行但有三处值得停下来思考一是默认编辑器选择。如果你没装其他编辑器默认的Vim会让你在输入commit message时彻底懵掉。没装编辑器的建议在安装前先装个VS Code或者Notepad然后在这步选“Use Visual Studio Code as Gits default editor”已经装好的可以在安装后通过命令切换。二是PATH环境变量配置。默认选项是“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”会把一堆Linux命令一起加进PATH遇到和Windows自带命令重名的情况容易踩雷。三是换行符转换这是Windows上最坑的一步。默认选项是“Checkout Windows-style, commit Unix-style line endings”也就是检出时把LF自动转换为CRLF提交时把CRLF自动转换为LF。这个选项对绝大多数人是正确的但它也意味着你以后会频繁看到warning: LF will be replaced by CRLF这类提示。想彻底关掉自动转换选最下面的“Checkout as-is, commit as-is”但这会给你和你的队友埋下“明明没改文件却显示全部改动”的大坑。具体处理办法在第二章详细展开。提示装完以后Windows搜索框里输入git --version看到版本号就说明PATH配置成功。如果提示“不是内部或外部命令”多半是PATH没生效重启命令行窗口或者注销重登一次。2. 装完不是结束三件配置事没做等于白装Git装完不等于能用。你随便找一个目录执行git commit大概率会得到一段红色报错核心是找不到user.name和user.email。很多新手在“git config --global user.name”这一步就开始出问题下面按优先级说清楚。2.1 user.name 和 user.email提交记录上署名是谁这两个配置决定了你的每次提交在Git记录里显示成谁。需要注意user.name不是你的Windows用户名也不是GitHub昵称是你想在提交记录里显示的名字可以和账号无关。user.email建议和你托管平台的邮箱保持一致比如GitHub的邮箱这样提交记录才能正确关联到你的账户。GitHub后来出于隐私考虑支持了noreply邮箱如果你用了这个也要和平台设置一致。配置命令如下git config --global user.name Your Name git config --global user.email youexample.com--global表示当前用户全局生效不带这个参数就只对当前仓库生效。检查是否配置成功的命令是git config --global --list这会把所有全局配置项列出来。修改的话重复执行一次同名命令即可配置错了不可怕可怕的是提交完之后全队人都看到你用了错误身份。2.2 换行符问题为什么明明一行没改却显示整个文件都变化这是Windows用户最绕不开的坑。简单说Windows用回车加换行CRLF作为行结尾Linux和macOS只用换行LF。Git默认在检出时把LF转成CRLF提交时把CRLF转回LF这个机制保证了仓库里的文件永远是LF而你在Windows上编辑时看到的是CRLF。麻烦出在下面几种情况你关闭了自动转换然后一个文件在Windows上编辑后提交仓库里就变成了CRLF。队友在Linux上编辑同一行代码本地是LF两边都提交后Git会认为整个文件的所有行都被修改了。你打开一个本来就带CRLF的文件在某些编辑器和Git的交互下diff界面看到一个文件全部被标记为修改。处理原则仓库里统一用LF检出时Windows上要不要自动转CRLF取决于你的团队约定。一般情况下保持默认的core.autocrlftrue就行。如果你在一个两位成员分别用Windows和macOS的团队里可以在仓库根目录放一个.gitattributes文件对特定类型文件强制声明行结束符这比依赖每个人的本地配置要可靠得多* textauto *.js text eollf *.sh text eollf *.bat text eolcrlf以后遇到“没改文件但diff显示全部变动”先执行git add --renormalize .再重新提交能解决一部分历史坏记录。2.3 SSH vs HTTPS本地免密方案怎么选在Windows上连远程仓库GitHub、GitLab、Gitee等传输方式一般是HTTPS或SSH两种。HTTPS方式每次push要输入用户名和密码但Windows上有Git Credential Manager帮你在首次输入后记住凭据之后自动静默提交适合大多数人。配置方式是git config --global credential.helper manager-core这是新版Git for Windows的默认值如果发现老版本没有改成wincred也行用得省心。SSH方式需要生成密钥对把公钥放到托管平台。Windows上用SSH的好处是你自己控制了认证密钥多设备场景更好管理。生成密钥ssh-keygen -t ed25519 -C your_emailexample.com一路回车会在C:\Users\你的用户名\.ssh\下生成id_ed25519私钥和id_ed25519.pub公钥。把公钥内容复制到GitHub的Settings-SSH keys里然后测试连接ssh -T gitgithub.com这里有个实操细节Git for Windows自带的SSH和你系统OpenSSH可能发生端口冲突。如果你装了Windows OpenSSH客户端通常Win10以上自带又使用Git默认配置可能会看到ssh: connect to host github.com port 22: Connection refused或调度器错误。解决办法是让Git使用系统自带的OpenSSH而不是内置的git config --global core.sshCommand C:/Windows/System32/OpenSSH/ssh.exe也可以把/c/Windows/System32/OpenSSH/加到系统PATH最前面。这一步查不出来的时候千万别贸然重装Git先看看是不是两个SSH打架。3. 日常三连之外Windows 上最容易踩的坑很多人把Git用成“add-commit-push三连”这没错但你得知道每一条命令到底做了什么以及Windows上有哪些特有的大坑。3.1 add、commit、push 的正确姿势与工作区概念先花三十秒理解Git的三个区工作区是你的文件目录暂存区是git add之后文件暂存的地方本地仓库是git commit之后写入的地方。git add是把改动选入暂存区git commit是把暂存区快照提交到本地仓库git push才是把本地仓库的提交推到远程。实操中最常犯的一个错误是在项目根目录执行git add .把一堆不该提交的临时文件一起加了进去。解决办法是养成先看状态再add的习惯git status git diff git add 具体文件 git commit -m feat: 描述你的改动git status永远是第一道防线它告诉你哪些文件被修改了、哪些还没被追踪。Windows上新手常见问题是把node_modules、bin、obj这类依赖生成目录也提交上去正确做法是在仓库根目录创建.gitignore文件node_modules/ dist/ build/ *.log .DS_Store Thumbs.dbWindows上特别容易漏掉.gitignore自身新建文件时注意文件名开头有点暂时改不了用命令行创建即可。3.2 Git Bash、CMD、PowerShell 的差异Windows下操作Git有三种终端我在实际教学里会建议初学者优先用Git Bash原因很简单Git Bash 是 Git 官方打包的 Unix 环境语法兼容性最好教程里几乎所有的命令都能直接复制粘贴跑通。如果你在CMD或PowerShell里跑Git有几点要留意CMD不支持单引号所有git commit message里的单引号要改成双引号否则报错。PowerShell对符号和某些字符的解析方式不同比如git log --oneline --all这种参数个别版本解析时需要用引号包裹参数。PowerShell的curl是Invoke-WebRequest的别名想用真正的curl得先输入curl.exe才能访问真实程序。这个坑曾经让我在处理GitHub API时浪费了半小时。在Windows上真正要小心的是路径中包含中文或空格。Git本身支持unicode路径但某些老插件或外部工具特别是涉及SSH和打包类的程序对中文路径处理得不好建议项目文件夹尽量用英文小写命名senior开发者的习惯是my-project而不是我的项目。3.3 文件权限和大小写不敏感的坑Windows文件系统默认不区分文件名大小写你创建一个Readme.md再创建一个README.md在Windows上会是同一个文件。Git在默认配置下对文件名是区分大小写的这就会导致你在Windows上clone一个仓库、然后把Readme.md改名为README.mdgit status显示是正常的重命名但在Linux上这两个文件同时存在会导致直接无法clone。如果遇到还需要保留两个大小写不同文件的情况得调整Git的配置让文件系统大小写敏感git config core.ignorecase false但要注意core.ignorecase设为false之后Windows上原有的文件可能突然消失因为文件名不匹配操作前一定备份。大多数情况下我建议维持默认只在团队跨平台时通过约定来限定文件名格式。另外一个容易忽略的是文件权限。Windows上Git不会记录可执行权限位但如果你被git diff中的old mode 100644 / new mode 100755困扰这说明有队友在Unix环境修改了文件权限。Windows下没法直接调整仓库里记录的权限位但可以批量修复git config core.filemode false设置之后Git在Windows上忽略文件权限差就不会过度报告这类变更了。4. 分支与合并在 Windows 上处理冲突的实操分支是Git相对SVN等老版本控制工具的核心优势。新手往往开发都在master上直接提交这是最危险的习惯。建立分支让你的功能开发、修复、试验都互不影响。Windows上做分支合并主要的问题是合并冲突的提示与编辑器集成下面拆开讲。4.1 分支创建合并的日常流程一个标准流程是这样的# 切到主分支并拉取最新代码 git checkout main git pull origin main # 创建并切换到功能分支 git checkout -b feature/awesome-feature # 开发完提交 git add . git commit -m feat: 完成新功能 # 回到主分支合并功能分支 git checkout main git pull origin main git merge feature/awesome-feature # 推送并删除远端分支 git push origin main git push origin --delete feature/awesome-feature建议把目标分支更新到最新再合并避免合并出一堆无谓的历史分叉。git pull是fetch和merge的组合旧版本默认会生成一次merge提交这会让你日志看起来很乱。Windows用户可以在拉取时加上--rebase参数让历史更线性git pull --rebase origin main个人体会是功能分支的生命周期越短越好尽量让分支只承载一个功能合并完即刻删除。不要因为“留着备用”就把分支堆满地。4.2 合并冲突的识别与解决合并时如果两处修改对同一行都有改动Git会停下并提示冲突生成一堆带标记的文件 HEAD 当前分支的代码 被合并分支的代码 feature/awesome-featureWindows用户常犯的错是手动用记事本打开改完、保存并直接提交。这错的严重性在于Git只能通过标记识别冲突你只删掉标记并没有实际解决冲突它会认为冲突已解决。推荐解决方式是用Git GUI合并工具Git for Windows自带Git GUI但配置麻烦我比较推荐VS Code装了之后Git会询问是否作为合并编辑器。VS Code里冲突部分会高亮成三种颜色当前内容、传入内容、两者都采用直接点按钮选择保存后执行git add并提交。全程不用碰符号。如果冲突文件数量太多建议把合并拆成小步骤先合并一个文件、解决完再继续比一次性解决所有冲突更容易出错砸锅。4.3 反悔药reset、revert、stash人人都会犯错Windows上使用reset和revert的差别必须分清git reset --hard HEAD~1把本地历史彻底回退到上一个版本工作区同步强制覆盖所有未提交的改动直接消失无法找回。git commit --amend把最后一次提交合并并覆盖适合“commit信息打错了”这种场景。git revert commit生成一个反操作的提交历史是完整的适合已经push到远程、需要保留历史的情况下撤销某次改动。需要特别强调的是已经推送到远程的提交不要用reset去撤销。因为如果你推回一个和远端历史不匹配的分支你的队友pull时会进入一个“两个历史不相干”的混乱状态。正确做法用git revert生成一条新的撤销提交所有人都能平滑同步。stash是Windows环境下特别顺手的一个功能因为你经常要“临时放下手里开发到一半的活儿去修生产紧急bug”git stash # 暂存当前工作区改动 git stash pop # 恢复最近的暂存 git stash list # 查看暂存列表 git stash drop # 丢弃某个暂存实测中遇到过一个问题在Windows上git stash pop之后出现冲突因为你stash里的改动和当前分支的新改动对同一行动了手。这时Git会打出冲突标记处理方式和普通冲突一样。另外嫉久不恢复的stash一定记得drop否则积攒一堆无用的快照。5. 排错从 SSH 认证失败到乱码的完整排查链路最后用一个完整的排查过程讲Windows上最容易被搜索到的三类问题。你以后遇到问题按这个思路来不要上来就卸载重装。5.1 SSH 认证失败的完整排查步骤症状git push时报Permission denied (publickey).或者ssh: connect to host github.com port 22: Connection timed out。排查链路逐条过第一步确认当前本地Git用的SSH是哪一个which ssh如果输出路径是/usr/bin/ssh说明你用的是Git自带的SSH如果输出C:\Windows\System32\OpenSSH\ssh.exe说明是系统OpenSSH。二者行为不同尤其是密钥读取位置可能不一致一个是/c/Users/你的用户名/.ssh/一个是C:\Users\你的用户名\.ssh\路径格式不一样但指向同一个物理目录。第二步确认密钥文件存在且权限正确在Git Bash里检查ls -la ~/.ssh/正常情况下应有id_ed25519和id_ed25519.pub。私钥权限问题往往出现在刚拷贝过密钥文件时Windows的NTFS权限系统和Unix不同但Git Bash下偶尔会发生私钥权限过大的报错。修复办法是打开文件属性把“继承”关掉只留当前用户完全控制。第三步测试具体连接排错ssh -T gitgithub.com -v-v会输出整个握手过程的日志重点看两行debug1: Offering public key: id_ed25519表示本地在尝试用这个密钥如果后面跟着server accepts key则成功。如果看到Load key id_ed25519: incorrect permissions那就是上面的权限问题。第四步检查仓库的远程地址协议git remote -v如果显示的是gitgithub.com:xxx/xxx.git说明走SSH如果显示https://github.com/xxx/xxx.git说明走HTTPS。两种情况报错信息不同处理方式也不同。实际经验是80%的SSH认证失败不是公钥没配好是本地私钥权限不对或Git用了错误的SSH程序。而且Windows的防火墙或代理也可能阻断22端口。遇到超时问题的检查你的安全软件和系统代理但这里不展开——这种属于环境问题不属于Git本身。5.2 中文乱码问题在Git Bash里git log看到中文commit message乱码或者提交时中文文件名乱码这是Windows中文环境下的历史遗留问题。先检查三个配置git config --global core.quotepath false git config --global i18n.commitencoding utf-8 git config --global i18n.logoutputencoding utf-8core.quotepath false解决中文文件名显示为八进制数字的问题i18n.*解决编码转换问题。还有一类乱码出现在Git Bash窗口里——如果窗口编码不是UTF-8中文就会显示成鈥樷这样的乱码。解决办法是在Git Bash窗口标题栏右键-选项-文本-本地编码里选UTF-8或者直接运行echo export LC_ALLen_US.UTF-8 ~/.bashrc这会把Git Bash环境变量的LANG和LC_ALL固定为UTF-8避免大部分显示乱码。5.3 常见警告与提示以及一条救命的配置新老手都会看到的一行提示是hint: Youve added another git path inside your local git repository...这通常是把Git仓库嵌套到了另一个Git仓库里多见于你把项目直接clone到了桌面或“我的文档”而父目录本身已经是一个Git仓库。解决办法是换个干净目录比如D:\WorkSpace\重新clone或者确认子项目需要单独管理时用子模块机制而不是直接在嵌套目录里操作。还有一个Windows专属提示容易吓到人warning: in the working copy of xxx.js, CRLF will be replaced by LF...这只是一个提醒不是错误。它提示你本地检出的CRLF会在下次commit时自动转成LF再入库。说明core.autocrlftrue在工作符合预期。真正需要担心的是如果你换到Linux环境又关掉了autocrlf才可能出现文件整体需要重写的状况。最后给一条救命的配置在Windows上务必备份你的~/.ssh/目录和全局.gitconfig前者是你的所有机器身份后者是你积累多年的配置习惯。重装或换电脑时把这些搬过去你能在十分钟内恢复完整的Git使用环境不用重新踩一遍所有坑。