Git 这东西我几乎每天都在用但每次帮人排查环境问题发现卡住的往往不是命令本身而是最开始下载、安装、配置这三步没走顺。这篇以 Windows 系统为例把 Git 从下载安装到配置、再到常用命令和实战示例完整过一遍适合刚接触 Git 的小白也适合已经在用但想补强底层的同学。我会把每一步背后的原因也讲清楚而不是只丢一串命令让你复制。你在自己电脑上照着点基本能一次走通。1. 装 Git 前的思考Windows 上到底需要哪种 Git1.1 先确认你的 Windows 版本和包管理现状动手之前先花一分钟确认环境。按下 Win R 输入 winver 回车能看到当前系统版本。Windows 10 和 Windows 11 都是 64 位居多少数老机器是 32 位这会直接影响你下载哪个安装包。之后再打开命令行cmd 或 Windows Terminal输入 git --version如果系统提示“不是内部或外部命令”说明这台机器还没有 Git或者装了但没加入环境变量。还有一种情况电脑上已经装了某个图形化 Git 客户端比如 GitKraken、SourceTree、TortoiseGit但命令行里的 git 命令照样不可用。原因是这些图形客户端大多内置了自己的 Git 引擎没有把可执行文件放进系统 PATH。我的建议是不管平时习惯用哪种图形界面都在系统层面装一份 Git for Windows这样任何终端、任何编辑器都能调用它。1.2 为什么我不建议用图形化工具完全替代命令行图形工具的优点是直观缺点也明显很多关键操作被按钮封装了出问题时你看不到底层指令到底是什么。比如一个“同步”按钮背后可能是 fetch、rebase、push 的组合一旦出现冲突图形界面给出的提示往往不如一行 git status 来得清晰。命令行不是让你抛弃效率而是让你拥有解释错误的能力。Git 本身是一个命令行工具所有 IDE 的 Git 插件都是在调用它。自己在终端里敲过一遍 init、add、commit、push以后看 IDE 里的报错日志你会立刻明白是哪一步出了岔子。这篇教程会尽量说清楚每条命令“为什么要这样写”而不是让你死记。2. 下载与安装走一遍完整流程2.1 下载源的选择与安装包类型Git 的官方下载页是 git-scm.com进入后选择 Windows 版本页面会自动识别你的系统位数。如果你不确定位数可以直接选 64-bit 的安装包如果是 32 位老系统再选 32-bit 版本。国内网络环境下从官方站点下载大文件偶尔会比较慢。如果你遇到这种情况可以去阿里云开源软件站或腾讯云软件源找 Git 的安装包它们是国内服务器速度通常更快。下载时注意认准包名里的版本号比如 2.4x.x-windows-64-bit.exe别下成 portable 版。portable 版是免安装的适合临时用但集成到右键菜单和环境变量上不如安装版方便。作为主力开发工具我建议装标准安装版。安装包下载好后双击运行。Windows 可能会弹出 UAC 用户账户控制点“是”就行。接下来的安装向导每一步都值得仔细看因为某些选项装完以后修改起来比较麻烦。2.2 逐项勾选安装选项不踩坑安装开始后会进入选择组件页。这里我建议保留这几个核心选项Git Bash Here右键菜单会出现“Git Bash Here”让你直接在某个文件夹打开 Git Bash 终端非常实用建议勾选Git GUI Here 是打开图形界面可勾可不勾。Git LFS大型文件支持。如果以后要处理设计稿、二进制包、数据集这类大文件提前装好能省事建议勾上。Associate .git* configuration files with default editor把 Git 配置文件关联到默认编辑器无所谓可跳过。Associate .sh files to be run with Bash让 .sh 脚本默认用 Bash 运行建议不勾避免影响系统里其他脚本的打开方式。下一步是选择默认编辑器。默认是 Vim新手容易卡住因为不小心进入编辑模式后不知道怎么退出。我更推荐选 Visual Studio Code 或 Notepad前提是你已经安装了其中一个。如果电脑上都没有那就先用 Vim后面我会给出改成 VS Code 的配置方法。记住一句在 Vim 里要退出编辑提交信息按 Esc输入 :wq回车。接着是最关键的 PATH 环境选项 Use Git from Git Bash only只在 Git Bash 里能用 gitcmd 和 PowerShell 以及 VS Code 终端都会说找不到 git不建议。Git from the command line and also from 3rd-party software推荐。会把 Git 的可执行目录加进系统 PATH所有终端都能直接用 git。Use Git and optional Unix tools from Command Prompt会把 Git 自带的 find、sort 等 Unix 工具也加入 PATH可能与 Windows 自带命令冲突不推荐。然后是 HTTPS 传输后端默认是 OpenSSL推荐保持默认。它和 Linux 上 Git 的行为一致很多文档里的 SSL 问题排查方法都能复用。如果你所在环境有大量自签名证书后面遇到证书报错时可以再考虑切到 Windows Secure Channel也就是原生证书库具体我在常见问题部分展开。换行符转换页面有三个选项是 Windows 用户最容易踩坑的地方我单独用一小节讲。2.3 安装过程中的换行符选择原理Windows 文本文件换行符是 CRLF回车 换行Linux 和 macOS 是 LF只有换行。Git 仓库内部倾向统一存 LF但 Windows 用户希望工作区保持 CRLF。安装向导给你三个选择Checkout Windows-style, commit Unix-style line endings推荐适合多数情况。检出到工作区时转成 CRLF提交到仓库时统一改成 LF。Checkout as-is, commit Unix-style line endings检出时不转换提交时转成 LF。适合项目里已经有明确换行规范、并且你不想让 Git 自动改动的场景。Checkout as-is, commit as-is完全不转换最容易出现“文件被 Git 认为全部改动”的乱象不建议新手选。我推荐你在安装时选第一项。装完后如果发现某个项目表现异常再用 .gitattributes 对特定文件单独控制这个后面讲。之后会问终端模拟器选 Use MinTTY 即可复制粘贴体验更接近 Linux 终端。最后会勾选 Enable file system caching建议保留它能提升 Git 在 Windows 上的文件状态读取速度。Enable symbolic links 默认不要勾除非你开过开发者模式并且确需要符号链接。一路 Next 完成安装。最后验证重新打开一个 cmd输入 git --version能看到版本号就说明安装成功。如果还提示找不到命令多半是 PATH 没生效重启命令行或注销重新登录即可。3. 基础配置让 Git 记住你的身份和偏好3.1 全局用户信息与配置文件位置Git 每次提交都会记录作者和邮箱所以第一件事就是配置身份。打开终端执行git config --global user.name 你的名字 git config --global user.email 你的邮箱example.com这两条命令写入的是全局配置文件。在 Windows 上它的位置是 C:\Users\你的用户名.gitconfig。你可以用记事本打开它或者用下面命令查看git config --global --list git config --global --edit--edit 会用默认编辑器打开配置文件。之前如果选了 Vim这里打开的就是 Vim你同样可以用 :wq 退出。我更推荐把默认编辑器改成 VS Codegit config --global core.editor code --wait配置文件的优先级是 system全机器小于 global当前用户小于 local当前仓库。也就是说如果你在一个仓库里执行了不带 --global 的 git config user.name它会覆盖全局配置只对这个仓库生效。看当前仓库的实际生效配置可以执行git config --list --show-origin这个命令会告诉你每个配置项来自哪个文件排查“为什么我的用户名没变”非常有用。3.2 换行符与防乱码设置安装时选过换行符但我建议再把 core.autocrlf 显式写一遍避免不同版本行为不一致git config --global core.autocrlf truetrue 的意思是提交时 CRLF 转 LF检出时 LF 转 CRLF。这个值适合 Windows 单平台开发。如果你的项目成员全是 Linux或者团队依靠 .gitattributes 管理则可以不设这条保持 false 或 input。还有一个与中文密切相关的配置git config --global core.quotepath false默认情况下Git 会把非 ASCII 文件名转义成八进制序列比如中文文件显示成 \346\226\207\346\241\243.txt。设置成 false 后中文名会原样显示。这几乎是 Windows 中文用户的必设项。再来几个顺手配置git config --global init.defaultBranch main git config --global color.ui auto git config --global alias.st status git config --global alias.lg log --oneline --graph --all --decorate git config --global alias.br branchinit.defaultBranch 让 git init 创建的主分支叫 main而不是容易引发误会的 master。color.ui auto 让日志和 diff 输出有颜色。别名可以缩短常用命令比如 git st 等价于 git statusgit lg 能画出分支图建议保存到配置文件里。3.3 SSH 密钥生成与远程平台连接推送代码到 GitHub、Gitee 或 GitLab 时除了 HTTPS 密码登录更推荐用 SSH 密钥。生成方法在 Windows 上很简单ssh-keygen -t ed25519 -C 你的邮箱example.com一路回车会在 C:\Users\你的用户名.ssh 下生成 id_ed25519私钥和 id_ed25519.pub公钥。用记事本打开 .pub 文件把内容完整复制然后登录代码托管平台在 SSH Keys 设置里粘贴保存。验证连接ssh -T gitgithub.com首次连接会询问是否信任主机指纹输入 yes。如果看到 “Hi xxx! Youve successfully authenticated”说明通了。这里有个 Windows 特有的坑Git Bash 使用的可能是 Git 自带的 ssh也可能是 Windows 自带的 OpenSSH。可以用 where ssh 查看路径。如果之后出现权限问题优先检查密钥文件路径是否在 ~/.ssh 下以及公钥是否粘贴完整。4. 常用命令速查从入门到能干活4.1 本地仓库生命周期前面配置完成现在开始接触命令。以“本地仓库”为主线最基本的一套流程是初始化、改文件、暂存、提交、看状态。git init # 初始化仓库 git add README.md # 把文件加入暂存区 git status # 查看工作区与暂存区状态 git commit -m first commit # 提交暂存区内容 git log --oneline # 查看提交历史git add 是把“修改”放上暂存台git commit 是把暂存台的内容一次性“拍照”保存。你可以多次 add 后一次 commit也可以一次 add 一个文件。想取消暂存但保留修改用git restore --staged README.md想彻底丢弃工作区里未暂存的修改git restore README.md这个命令比较激进它会用暂存区或 HEAD 的内容覆盖当前工作区不可恢复。确认操作前先 git status 看清楚。查看改动内容比看状态更重要git diff # 工作区与暂存区差异 git diff --cached # 暂存区与最后一次提交的差异 git diff HEAD # 工作区与最后一次提交的全部差异这里要记住git status 只告诉你“哪些文件变了”git diff 才告诉你“具体变了什么”排查 bug 时后者的价值更大。4.2 远程仓库协作拿到一个新的远端仓库最常用的是克隆git clone gitgitee.com:yourname/example.git git clone https://github.com/yourname/example.git克隆下来的目录会自动关联远端。如果你想给已有本地仓库配置远端git remote add origin gitgithub.com:yourname/example.git git remote -v # 查看远端地址推送和拉取的常规流程git push -u origin main # 首次推送并记录上游分支 git push # 之后直接推送 git pull # 拉取远端并合并fetch merge git fetch # 只拉取不合并 git merge origin/main # 手动合并拿到的远端分支第一次 push 用 -u 是为了告诉本地分支“我的默认上游是 origin/main”后面就能直接 git pull / git push不用反复指定远端。如果远端地址换了git remote set-url origin gitgithub.com:new/nrepo.git想删除远程分支git push origin --delete old-branch4.3 分支合并与冲突解决分支操作是 Git 日常的核心。切换分支和新建分支在 Git 2.23 以后有更清晰的语法git switch feature # 切换到已有分支 git switch -c feature/login # 新建并切换到新分支 git branch # 查看本地分支 git branch -vv # 查看分支与上游的对应关系老一点的教程会用 git checkout -b和 git switch -c 效果一样。switch 语义更明确新手可以直接用它。把分支合回主分支的经典流程git switch main git merge feature/login git branch -d feature/login如果被合并的分支已经删除-d 就能确认删除如果分支还没合并-d 会拒绝你需要 -D 强制删。强制删除要谨慎除非你确定不要这个分支的内容。合并时最怕的是冲突。当两个分支修改了同一行Git 无法自动决定保留谁会把冲突标记写进文件 HEAD 当前分支内容 待合并分支内容 feature/login你手动编辑文件把 、、 这些标记删掉留下最终想要的代码然后git add 冲突文件 git commit这就完成了冲突解决。不要想着机器自动解决所有冲突人工过一遍内容永远是最稳妥的。4.4 撤销、暂存和日志恢复手滑是常态。改错了想放弃、提交错了想撤回你需要一套撤销工具包。先看暂存相关。手头做了一半的改动不想提交可以先藏起来git stash push -m wip git stash list git stash popstash 会把工作区和暂存区的改动藏到一个栈里pop 会恢复最近一次。注意 pop 时如果工作区已经改动了同一个文件也会出现冲突处理方式和分支冲突一样。再看提交历史修正。想改最近一次提交的信息git commit --amend -m new message如果刚才 commit 漏了一个文件可以先 git add 那个文件再执行 git commit --amend --no-edit这样能补进上一次提交而不改提交信息。这里要注意amend 会改写 commit 记录如果这个提交已经推送到公共远端不要再使用。更深层的恢复工具是 reflog。每次操作都会在本地记录 HEAD 的移动轨迹git reflog假设你 git reset --hard 上错了可以通过 reflog 找到之前的提交号然后git reset --hard HEAD{2}reflog 默认保留 90 天是误操作的最后一道保险。管理 reset 的三个模式可以对照看模式工作区暂存区提交历史典型场景--soft不变不变回退仅撤销 commit保留所有改动--mixed不变清空回退撤销 commit 和暂存保留工作区改动--hard清空清空回退彻底回到旧提交放弃所有改动如果你已经产生了需要保留历史的“后悔操作”更推荐 revertgit revert commit它会在当前分支生成一个“反向提交”不会改写历史适合公共分支。5. 实战示例用一条真实场景串起来5.1 从零初始化并完成第一次分支合并场景你在本地新建一个项目想接入 Git然后开分支做功能再合并回主分支。打开 Git Bash进入项目目录mkdir hello-git cd hello-git git init新建一个说明文件echo # Hello Git README.md git add README.md git commit -m init project提交成功后查看当前分支和文件状态git branch git status然后开一个功能分支git switch -c feature/login echo login module login.py git add login.py git commit -m add login module回到主分支查看历史再合并git switch main git log --oneline --graph --all git merge feature/login git branch -d feature/login这时用 git lg 看分支图会看到 main 分支的记录是线性的因为 feature 分支是从 main 最新点分出去的合并时 Git 默认走 Fast-forward直接把 main 快进到 feature 的位置。如果 feature 分支提交之前 main 又有新提交就会产生一次真正的 merge commit。5.2 模拟一次冲突并解决两个人同时改了同一个文件是团队协作里最常见的场景。我们本地模拟一下。先在 main 分支上提交初始文件 main.py内容是def hello(): return hello然后开一个分支 feature/zhang把返回改为 hello zhang提交。再切回 main把同一行改成 hello wang提交。此时 main 和 feature/zhang 在同一个文件同一行都产生了新提交。将 feature 合并进来git switch main git merge feature/zhangGit 会提示CONFLICT (content): Merge conflict in main.py打开 main.py能看到def hello(): HEAD return hello wang return hello zhang feature/zhang手动把文件改成想要的内容删掉所有冲突标记def hello(): return hello from both然后git add main.py git commit -m merge: resolve conflict到这里冲突解决完毕。我的经验是解决冲突时不要只看自己所在分支尽量把两边代码的上下文都读一遍。很多线上 bug 就是冲突解决时顺手删了对方的逻辑导致的。5.3 克隆远端项目并推送自己的修改现在模拟真正参与一个已有项目。从远端克隆git clone gitgitee.com:yourname/example.git cd example确认当前分支然后基于最新 main 建自己的功能分支git switch -c task/update-readme改完文件后提交git add README.md git commit -m docs: update readme推送前先更新本地分支与远端同步git pull --rebase origin main为什么推荐 pull --rebase普通 pull 会产生一个 merge 提交时间一长历史就变得复杂。用 --rebase 会把你本地未推送的提交“垫”到远端最新提交之后历史更干净。如果 rebase 过程中出现冲突解决完冲突后执行git add 冲突文件 git rebase --continue最后推送git push -u origin task/update-readme输出结果会显示远端仓库新增了一条分支。接下来你就可以在代码托管平台上发起合并请求让团队其他人评审。整个过程看起来步骤多但拆开只有四件事新建分支、改代码、同步远端、推送。熟练以后一分钟就能完成。6. 常见问题与排查技巧实录6.1 中文乱码文件名、提交内容、记事本三连坑很多 Windows 用户在 Git 里看到中文文件名显示成 \346\226\207\346\241\243.txt这其实不是文件名被改坏而是 Git 的转义显示。解决方法是git config --global core.quotepath false设置完之后重新执行 git status中文就能正常显示。Git Bash 窗口里如果提交信息的中文显示成乱码可能是终端编码问题。在 Git Bash 窗口标题栏右键选择 Options把 Text 里的 Character set 改成 UTF-8。Windows Terminal 则默认使用 UTF-8基本不会出现这个问题。有人还会遇到系统记事本打开 UTF-8 文件中文乱码。新版 Windows 的记事本默认是 UTF-8 编码如果打开旧的无 BOM 文件却被当成 ANSI 读取就会乱码。实际处理时可以在“编码”下拉菜单里手动选择 UTF-8或者把文件另存为带 BOM 的 UTF-8。对 Git 项目来说更推荐用 VS Code 这类专业编辑器并统一给文件配置好编码。6.2 提交时遇到一长串 git -c 开头的命令使用 VS Code 或其他 IDE 提交时你有时会在 IDE 的输出面板看到类似这样的命令git -c diff.mnemonicprefixfalse -c core.quotepathfalse --no-optional-locks push -u origin main这不是异常而是 IDE 为了控制 Git 行为附加的临时配置。它实际等于在命令行里临时设置了几个配置项core.quotepathfalse 关闭中文转义diff.mnemonicprefixfalse 让 diff 前缀更简洁--no-optional-locks 避免后台操作给仓库加锁。你在命令行里也可以这样用git -c core.quotepathfalse status这里的 -c 只是“本次命令临时覆盖配置”不会修改你的全局配置很安全。6.3 fatal: unable to access SSL certificate problemWindows 下访问 HTTPS 远端仓库时有时会报fatal: unable to access https://...: SSL certificate problem: unable to get local issuer certificate大多是系统根证书库不完整或者某些企业网络对 TLS 加密做了二次封装。排查思路分几步先确认远端地址是否写对浏览器能打开不一定代表命令行能直接访问。如果本地仓库使用的是自签名证书或内网证书可以考虑让 Git 使用 Windows 证书库git config --global http.sslBackend schannel这是让 Git 调用 Windows 原生证书库而不是 OpenSSL 的自带库。很多内网环境下这个配置能直接解决证书不识别问题。不要一上来就执行 http.sslVerify false那等于永久跳过所有证书校验非常不安全。除非你是临时验证用完立刻改回 true。如果你的远端在海外而访问不稳定更务实的做法是把远端仓库也托管一份到国内代码托管平台在本地把远端地址切换到那份上。这样既不牺牲安全也能改善访问体验。6.4 fatal: detected dubious ownership in repositoryGit 2.35.2 以后增加了安全检查。Windows 下有时打开某个路径下的仓库会报fatal: detected dubious ownership in repository at D:/projects/xxx原因是 Git 检测到仓库目录的所有者与当前用户不一致比如从压缩包解压出来的目录、从同事那里拷贝的项目、或者是通过某些云盘同步来的目录。正确做法是把目录加入安全白名单git config --global --add safe.directory D:/projects/xxx如果你确定这台机器上所有 Git 仓库都由你个人管理也可以一次性配置git config --global --add safe.directory *但我不建议在共用机器上这么做安全保护有它存在的意义。逐个添加受影响目录更稳妥。6.5 换行符导致的“全文件 diff 风暴”Windows 用户经常遇到一个奇怪现象自己只改了一行代码git diff 却显示整个文件几百行全部被修改甚至每行末尾都出现 ^M。这不是代码真的全变了而是换行符从 CRLF 变成了 LF 或者反过来。最根本的解决方案是把换行符规则写进版本库。在仓库根目录创建 .gitattributes 文件内容可以这样写* textauto *.sh text eollf *.bat text eolcrlf *.cmd text eolcrlf *.png binary *.jpg binary第一行表示文本文件统一由 Git 自动判断换行符第二行强制脚本文件在仓库内和工作区都用 LF第三四行让 Windows 批处理保持 CRLF二进制文件明确标记为 binary避免 Git 尝试处理。提交 .gitattributes 后需要一次性纠正仓库里已有的换行符git add --renormalize . git commit -m normalize line endings这个命令会按新规则重新规范化所有文件的换行符。它只会影响换行符不会动文件内容。建议团队在项目初始化阶段就把 .gitattributes 加上越早代价越小。6.6 误操作后如何恢复到某个历史状态最后再来一条兜底技巧。假设你在分支上开发了三天昨天一个 git reset --hard 把所有工作区改动清掉了心态快崩了。先别急在 Git 里大部分操作都能救回来。第一步用 reflog 看所有历史git reflog输出里每一行是一个历史标记形如 HEAD{0}、HEAD{1}。找到你想要的提交比如三小时前那个 HEAD{2}然后git reset --hard HEAD{2}reflog 是本地的操作日志只要你没有清理过 Git 的回收机制这个回退操作通常能成功。但如果改动从没被 add 或 commit 过reflog 也帮不了你因为没有提交就没有恢复依据。这也是我一直提醒自己的习惯可以把一个功能的改动拆成多次小提交宁可多 commit不要长时间攒着不提交。.gitattributes 我提了两次这里再重复一次它是我在 Windows 环境里最推荐的团队级配置文件。花十分钟写好它能避免无数个换行符引发的假冲突。最后再分享一个小技巧在 PowerShell 里装一个 posh-git你的命令行提示符会直接显示当前分支、是否有未提交改动日常操作会顺手很多。