个人主页杨利杰YJlio❄️个人专栏《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》《微信助手》 《锤子助手》 《Python》 《Kali Linux》《那些年未解决的Windows疑难杂症》让复杂的事情更简单让重复的工作自动化文章目录img srchttps://i-blog.csdnimg.cn/direct/15109afe39674568a5fbfc9a75343036.png alt1 / 1. 我为什么要把 Windows 下的 Git 环境重新梳理一遍img srchttps://i-blog.csdnimg.cn/direct/b4667309ca804e5fbd865c8f53db9d57.png alt2 / 2. 我想要的“可用”到底指的是什么img srchttps://i-blog.csdnimg.cn/direct/3beea2d2e40c46409b53a699a0c75ffc.png alt3 / 3. 我在开始之前先把几个基础问题想明白了3.1 Git 不是代码平台它更像版本管理核心工具3.2 Windows 下最大的问题往往不是安装而是细节默认值3.3 我给自己的原则是先简单稳定再逐步完善img srchttps://i-blog.csdnimg.cn/direct/6e77ef4fb6cf44a8bbcd36732006bd24.png alt4 / 4. 我在 Windows 上安装 Git 时最关注的不是“快”而是“后面少出问题”4.1 安装完成后我先做的第一件事是确认命令能不能直接用4.2 我会顺手确认 Git 的真实路径4.3 我不会忽略终端选择img srchttps://i-blog.csdnimg.cn/direct/432906fd95fa47948a030ff7510b9014.png alt5 / 5. 我把 Git 的基础配置一次性定规范了5.1 用户名和邮箱5.2 默认分支名称5.3 换行策略5.4 默认编辑器5.5 我会看一眼全局配置文件img srchttps://i-blog.csdnimg.cn/direct/6c0503227f654af9a0106a231fc7dcd4.png alt6 / 6. 我最终更偏向用 SSH把认证这件事一次性理顺6.1 为什么我后来更偏向 SSH6.2 我生成 SSH 密钥的过程6.3 我会先把 SSH Agent 处理好6.4 我验证 SSH 是否真的通了img srchttps://i-blog.csdnimg.cn/direct/828c7ea35b2d46b2bdd4b5d814fa8c6b.png alt7 / 7. 当我第一次把仓库拉到本地时我更看重“结构清楚”而不是“先跑起来再说”7.1 我会先选一个统一的本地代码目录7.2 我用 clone 而不是下载 ZIP7.3 我会先看分支和远端信息img srchttps://i-blog.csdnimg.cn/direct/9a812ac811ec443eaf6646806e81a40d.png alt8 / 8. 我把第一次提交流程完整跑通后才真正觉得环境稳了8.1 我会先新建一个测试分支8.2 我会做一个最小修改8.3 我会显式 add再 commit8.4 我会再做一次 push 验证img srchttps://i-blog.csdnimg.cn/direct/b2ecca22e02f47a8b4b528f277705806.png alt9 / 9. 我在日常使用中最常用的 Git 命令其实并不多9.1 状态类9.2 提交类9.3 分支类9.4 同步类img srchttps://i-blog.csdnimg.cn/direct/3a5c24069b1e4e7bb94ef28912f8b18e.png alt10 / 10. 我在 Windows 下踩过的几个典型坑后来看都很有代表性10.1 git 命令无法识别现象我后来总结的常见原因我通常怎么排10.2 push 时提示权限失败现象常见原因我通常先查什么10.3 提交时换行符异常现象常见原因我对这个问题的体会10.4 默认编辑器弹出来后不会退出现象原因我的处理方式img srchttps://i-blog.csdnimg.cn/direct/dfcc6c42b2db43de9393f2546fd02c57.png alt11 / 11. 我怎么验证这套环境已经真的进入稳定状态11.1 我的验证清单11.2 我会再做一轮最小闭环测试img srchttps://i-blog.csdnimg.cn/direct/c8963150bdb14b7ab385f6b7f2989f5a.png alt12 / 12. 总结提升我后来越来越相信开源的第一步不是写代码而是把环境打磨顺适用环境关键词返回顶部1. 我为什么要把 Windows 下的 Git 环境重新梳理一遍很多人刚接触开源的时候第一反应往往是“先把项目拉下来再说”。但我自己真正开始折腾以后才发现开源开发的第一道门槛不是代码而是环境。尤其是在 Windows 下很多问题并不是 Git 本身难而是下面这些细节很容易把人劝退Git 安装完了但命令行里识别不到能 clone 仓库但 push 的时候权限报错提交记录能成功可用户名和邮箱全是错的分支切来切去最后自己都不知道改到了哪里终端、编辑器、SSH、凭据管理混在一起越配越乱我这篇文章不讲空泛概念而是把我自己在Windows 下把 Git 从零配到“可以稳定使用”的整套过程梳理出来。目标很明确不是只把 Git 装上而是把一套真正能用于开源项目协作的本地环境配顺。2. 我想要的“可用”到底指的是什么我后来给自己定了一个很实际的标准所谓“可用”不是屏幕上出现一个 Git 图标而是我能完整跑通下面这条链路正常安装 Git在终端里直接执行 Git 命令配好用户名和邮箱配好默认分支和换行策略通过 SSH 或 HTTPS 连接代码平台成功 clone 仓库新建分支、修改文件、提交代码正常 push 到远端出问题时我自己能知道该从哪里排查也就是说我更看重的是“可持续使用”而不是“装完算完”。为了把这个思路说清楚我先画一张简单的结构图安装 Git验证命令可用配置用户名和邮箱设置默认分支与换行策略配置 SSH 或 HTTPS 认证克隆远端仓库创建分支并修改文件提交 CommitPush 到远端进入日常开源协作状态当这条链路完整跑通以后我才认为这套环境是真正能干活的。3. 我在开始之前先把几个基础问题想明白了在正式动手之前我先把几个常见疑问想清楚不然越到后面越容易乱。3.1 Git 不是代码平台它更像版本管理核心工具我以前刚接触的时候容易把 Git 和 GitHub、AtomGit、GitLab 混成一件事。后来实际用了才真正分清Git本地版本管理工具GitHub / AtomGit / GitLab远端代码托管平台SSH / HTTPS本地和远端通信的方式这个区分非常重要。因为很多问题表面看像“Git 出故障了”其实是平台认证或网络权限的问题。3.2 Windows 下最大的问题往往不是安装而是细节默认值我后来总结Windows 下 Git 最容易出问题的地方主要有三个PATH 环境变量换行符 CRLF / LF认证方式SSH / HTTPS看着都不大但每一个都能把后续使用体验拉低。3.3 我给自己的原则是先简单稳定再逐步完善我没有一上来就追求“最高级配置”而是先做到命令可用基础配置正确能成功拉取和提交能自己读懂常见报错这是我觉得更现实的路线。环境搭建最怕一步到位的幻想最稳妥的方式反而是先把最基本的链路跑通。4. 我在 Windows 上安装 Git 时最关注的不是“快”而是“后面少出问题”4.1 安装完成后我先做的第一件事是确认命令能不能直接用安装完 Git 以后我不会急着 clone 仓库而是先打开终端确认版本。我通常会在Git Bash或Windows Terminal / PowerShell里执行git--version如果返回类似下面的结果就说明 Git 本体已经装好了gitversion2.x.x.windows.x这一步看似简单但它其实是在确认两个关键问题Git 是否真的安装成功系统是否已经能正确识别 Git 命令如果这一步都不通后面做再多配置都没有意义。4.2 我会顺手确认 Git 的真实路径有时候系统里可能存在多个 Git或者以前装过旧版本结果当前调用的根本不是新装的那个。所以我会多做一步检查wheregit如果是 Git Bash也可以这样看whichgit这一步的价值在于我能知道当前系统到底调用的是哪一个 Git 可执行文件。这对后面排查“明明装了却行为不一致”的问题非常有帮助。4.3 我不会忽略终端选择在 Windows 环境里我最终是把终端使用习惯分成了两类Git Bash对 Git 命令兼容性更自然很多类 Unix 操作更顺手PowerShell / Windows Terminal更适合日常 Windows 运维、脚本和统一终端管理我的实际做法是Git 相关高频操作用 Git Bash 或 Windows TerminalWindows 系统排障、脚本调试更多放在 PowerShell这样用久了不会别扭也不会因为终端切换把自己弄乱。5. 我把 Git 的基础配置一次性定规范了Git 装完如果不做基础配置后面提交记录很容易变得很混乱。所以我一般会把下面几项一次性配好。5.1 用户名和邮箱这是提交记录里最基础的信息。我会执行gitconfig--globaluser.nameYJliogitconfig--globaluser.emailyour_emailexample.com然后再确认一遍gitconfig--global--list或者单独看gitconfig--globaluser.namegitconfig--globaluser.email为什么我很重视这个因为后面每一次 commit 都会带上这些信息。如果一开始配错了后面仓库历史里就会留下很多不一致的记录修起来会很麻烦。5.2 默认分支名称为了避免不同仓库里默认分支风格不统一我会直接设置默认分支名gitconfig--globalinit.defaultBranch main这样以后我本地新初始化仓库时默认就是main不会再出现一会儿master一会儿main的混乱情况。5.3 换行策略这是 Windows 下特别容易被忽略但又特别容易踩坑的一项。我一般会设置gitconfig--globalcore.autocrlftrue它的核心作用可以简单理解为在 Windows 本地工作区使用常见换行方式提交到 Git 仓库时尽量减少换行差异带来的干扰当然不同团队可能有不同规范但对大多数 Windows 本地使用场景来说这个设置更省心。5.4 默认编辑器有时候 Git 会在提交说明、rebase、merge 等场景里调用默认编辑器。如果默认编辑器不顺手体验会很差。比如我如果想用 VS Code会这样配gitconfig--globalcore.editorcode --wait这里的--wait很关键。因为 Git 需要等编辑器关闭后才知道输入已经完成。5.5 我会看一眼全局配置文件在 Windows 下Git 全局配置通常会写到当前用户目录下的.gitconfig文件里。我有时也会直接查看它确认有没有被旧配置污染。notepad %USERPROFILE%\.gitconfig这一步的意义不是“炫技”而是为了做到心里有数我的 Git 到底被配置成了什么样不靠猜。6. 我最终更偏向用 SSH把认证这件事一次性理顺Git 本地环境是否真正顺手认证方式几乎决定了一半体验。6.1 为什么我后来更偏向 SSHHTTPS 也能用但我自己的体验是首次上手容易理解但长期使用时经常会遇到凭据、令牌、缓存、重新登录等问题多个平台切换时管理起来不够干净而 SSH 的优势在于配好以后使用更流畅仓库 clone / pull / push 更稳定更适合我长期参与多个仓库协作所以我后面基本都优先用 SSH。6.2 我生成 SSH 密钥的过程我一般直接执行ssh-keygen-ted25519-Cyour_emailexample.com如果当前环境不支持ed25519也可以考虑 RSA但优先级上我更倾向于前者。执行以后系统通常会提示保存路径。如果没有特别需求我一般就直接用默认路径。接着我会看到类似下面这些文件私钥id_ed25519公钥id_ed25519.pub这里必须记住一点私钥绝对不能随便发给别人真正需要复制到平台上的是公钥内容。6.3 我会先把 SSH Agent 处理好为了避免每次都重复输入我会先启动 agent再加载私钥。在 Git Bash 下常见做法如下eval$(ssh-agent-s)ssh-add ~/.ssh/id_ed25519如果是在 Windows PowerShell 场景下我也会关注系统里的 OpenSSH Agent 服务是否正常。6.4 我验证 SSH 是否真的通了把公钥加到代码平台后我不会直接上来就 clone 仓库而是先做一次连通性验证。例如ssh-Tgitgithub.com或者对应平台的 SSH 域名。如果能看到欢迎信息或者认证成功提示我才认为这条链路是通的。这一步非常重要因为它能提前暴露很多问题比如密钥没加对账号没绑定公钥本机走错了密钥SSH 域名或端口被拦截7. 当我第一次把仓库拉到本地时我更看重“结构清楚”而不是“先跑起来再说”认证通了以后我才开始真正接触仓库。7.1 我会先选一个统一的本地代码目录我不喜欢今天 clone 到桌面、明天 clone 到下载目录、后天又放到 D 盘随手建的文件夹。这样看似快后面会非常乱。所以我通常会先规划一个统一位置例如D:\Code或者C:\Users\当前用户名\Code这件事看起来很小但长期看特别值。因为项目一多目录规划就是秩序。7.2 我用 clone 而不是下载 ZIP正式做开源协作时我不会用“下载 ZIP”代替 clone。因为 ZIP 只有文件没有版本历史也没有后续提交链路。我会直接执行gitclone gitgithub.com:yourname/your-repo.git成功后进入项目目录cdyour-repo然后先看仓库状态gitstatus如果状态正常我再继续下一步。7.3 我会先看分支和远端信息刚进一个仓库时我通常会先看这两项gitbranchgitremote-v这样我能马上知道当前在哪个分支远端仓库地址是什么当前仓库是不是我预期中的那个仓库这类动作很基础但能避免很多低级误操作。8. 我把第一次提交流程完整跑通后才真正觉得环境稳了环境配得再漂亮如果不能完成一次真实提交那它在我眼里还是“半成品”。8.1 我会先新建一个测试分支我不喜欢上来就在主分支上直接改所以通常会先创建测试分支gitcheckout-btest/init-git-env这一步的意义是避免污染主分支验证本地分支创建是否正常提前建立分支协作意识8.2 我会做一个最小修改比如我创建一个简单文本文件echoGit environment readytest.txt然后查看状态gitstatus这时 Git 会告诉我哪个文件是新增的。8.3 我会显式 add再 commitgitaddtest.txtgitcommit-mchore: verify local git environment on Windows如果这一步成功我就知道以下几件事都没问题用户名邮箱可用Git 本地提交链路正常工作区到暂存区到提交区的基本流程已经跑通8.4 我会再做一次 push 验证gitpush-uorigin test/init-git-env当 push 成功以后我才真正放心。因为这说明本地仓库正常远端地址正常认证正常网络权限基本正常分支推送链路完整到这里我心里才有底这套 Windows 下的 Git 开源开发环境已经不是“装好了”而是真的“能用了”。9. 我在日常使用中最常用的 Git 命令其实并不多很多人会被 Git 吓到是因为命令看起来特别多。但我自己真正高频使用下来最常用的核心命令其实就这些。9.1 状态类gitstatusgitbranchgitlog--oneline--graph--decorate-10这几条命令的价值很大git status看当前改动状态git branch看当前所在分支git log --oneline --graph --decorate -10快速看最近提交历史9.2 提交类gitadd.gitadd文件名gitcommit-m提交说明这里我自己的习惯是能精确 add 文件时就尽量不要总是git add .这样更不容易把不该提交的内容带进去。9.3 分支类gitcheckout 分支名gitcheckout-b新分支名gitswitch 分支名gitswitch-c新分支名现在switch在分支切换语义上更清晰但很多旧文档里还是checkout。我自己两套都能接受关键是要清楚自己在做什么。9.4 同步类gitpullgitfetchgitpush我后来更习惯先fetch再看差异再决定怎么合并而不是无脑pull。这样更可控。10. 我在 Windows 下踩过的几个典型坑后来看都很有代表性这一部分我觉得特别重要。因为真正决定一篇文章有没有实用价值的往往不是前面的“正常流程”而是出问题以后怎么定位。10.1git命令无法识别现象终端输入git --version提示找不到命令。我后来总结的常见原因Git 没装完整PATH 没加进去当前终端是安装前打开的没有重新打开系统里有多个 Git路径冲突我通常怎么排先看wheregit如果根本找不到优先看安装路径和 PATH。如果找到了多个结果我会确认当前到底调的是哪一个。10.2 push 时提示权限失败现象clone 没问题但 push 报权限错误。常见原因当前账号对目标仓库没有写权限SSH 密钥没有绑定到正确账号使用了错误的远端地址HTTPS 凭据缓存错乱我通常先查什么gitremote-vssh-T对应平台SSH地址我会先确认是仓库权限问题还是本机认证问题。这两类问题长得像但处理方向完全不同。10.3 提交时换行符异常现象文件明明只改了一点却显示大量变更。常见原因Windows 和 Unix 换行规则不一致仓库本身有.gitattributes本地core.autocrlf设置和团队规范不一致我对这个问题的体会这个坑特别烦因为它不一定报错但会污染提交记录。所以我后来越来越重视项目里的换行规范而不是只看本机默认值。10.4 默认编辑器弹出来后不会退出现象commit、merge 时进入编辑器不知道怎么结束。原因默认编辑器没设好编辑器命令缺少等待参数对终端编辑器操作不熟悉我的处理方式如果我要用 VS Code就直接设置gitconfig--globalcore.editorcode --wait这能少掉很多麻烦。11. 我怎么验证这套环境已经真的进入稳定状态很多人做到“能 clone 一次”就停了但我一般会再做一次完整验证确保这不是偶然成功。11.1 我的验证清单我通常会按下面这份清单逐项确认git --version正常返回版本git config --global --list能看到核心配置SSH 连通验证通过可以 clone 仓库可以创建新分支可以 add / commit可以 push 到远端编辑器调用正常终端里没有明显路径或权限异常11.2 我会再做一轮最小闭环测试也就是下面这个过程gitcheckout-btest/second-checkechosecond checktest.txtgitaddtest.txtgitcommit-mtest: second environment verificationgitpush-uorigin test/second-check如果这一轮仍然稳定那我基本就能确认这不是碰巧成功而是环境真的成型了。12. 总结提升我后来越来越相信开源的第一步不是写代码而是把环境打磨顺把这套 Windows 下 Git 开源开发环境重新走通以后我最大的感受其实很朴素很多人不是输在不会而是输在第一步环境太乱。Git 本身没有想象中那么难真正让人焦虑的往往是下面这些“小问题”叠在一起命令不通配置不清认证混乱分支失控出错时不知道从哪看而我这次重新梳理的重点就是把这些容易散、容易乱、容易踩坑的地方一次性捋顺。当本地环境真正稳定下来以后后面的事情才会开始顺看开源项目 README 更有底气clone 项目不再紧张提交代码更规范分支协作更清楚遇到问题时知道怎么自己排查所以在我看来Windows 下 Git 从零配置到可用真正有价值的不是“装了一个工具”而是把自己进入开源协作的第一道门槛迈过去了。如果我后面继续往下走我会把这套基础环境继续延伸到这些场景VS Code 与 Git 联动Git 常见分支协作方式.gitignore的整理逻辑开源项目第一次提交 Pull Request 的完整过程Windows 下 SSH、多账号、多仓库的管理方法对刚开始接触开源的人来说我反而觉得不用追求一步到位。先把 Git 环境真正配到能稳定使用再慢慢往后扩展节奏会稳很多。适用环境Windows 10 / Windows 11Git for WindowsGit Bash / PowerShell / Windows Terminal适合刚开始接触 Git、准备参与开源项目协作的场景关键词WindowsGit开源Git环境配置SSHGit BashPowerShell开源开发环境返回顶部 返回顶部