简介：围绕 Windows 平台 Git 图形化操作编写的 TortoiseGit 图文教程，面向刚接触版本控制、希望降低命令行使用门槛的开发者与运维学习者，帮助其熟悉仓库克隆、提交推送和分支协作等基础流程。压缩包内仅有 1 个 docx 文档，大小约 1.15MB，内容按安装配置、凭证管理、使用示例和常用操作组织，便于按主题检索查阅。教程具体涵盖 Git、TortoiseGit 及中文语言包的安装，常规选项、用户名与邮箱设置，凭证助手和 SSH Key 的配置，并通过克隆项目对比 HTTPS 与 SSH 两种连接方式。常用操作部分还梳理 Fetch、Merge、Commit、Push、分支管理以及文件状态角标含义，可帮助读者理解右键菜单背后的 Git 行为，积累日常排错与协作思路。目前已有 2150 人学习，适合作为 Windows 环境下 TortoiseGit 入门和随手查阅的紧凑型文档，也可供日常开发时快速定位配置与操作要点。

1. 右键菜单里的 Git：TortoiseGit 解决的是哪一层麻烦

命令行里敲git status、git commit -m敲得挺顺的人，一换到 Windows 资源管理器就容易抓瞎：改完文件不知道哪些进了暂存区，蓝色加号、红色感叹号到底代表什么，谁也说不清。TortoiseGit（俗称小乌龟）把 Git 的常用操作挂到右键菜单上，配合资源管理器图标角标，改了什么、走到哪一步，眼睛能直接看见。这份 TortoiseGit 使用教程的定位很实在：从装 Git、装小乌龟、配中文语言包开始，到克隆、提交、拉取、推送完整跑一遍，重点压在 SSH Key 和凭证管理这两块最容易卡住的地方。适合刚接手 Windows 开发机、团队用 Git 但自己还没跑通完整往返的从业者，也适合带新人时照着配环境的老手，当作一份 Git 图文教程对着点鼠标。

2. 装 Git、装小乌龟、装语言包：三步顺序错了就白折腾

2.1 依赖链：TortoiseGit 只是壳，git.exe 才是干活的那个

很多人以为装完 TortoiseGit 就能用了，结果右键菜单点“克隆”，弹一个Unable to find git.exe或者git.exe not found，一脸茫然。原因是 TortoiseGit 本身不实现任何版本控制逻辑，它是个纯前端，所有操作最后都要拼成命令行去调 Git for Windows 里的git.exe。壳装了、内核没装，或者内核装了但路径没对上，菜单能点，活干不了。

所以顺序是死的：先装 Git for Windows，装完在任意目录右键能看到Git Bash Here、Git GUI Here，说明内核就位；再装 TortoiseGit 主程序；最后装中文语言包。语言包是独立的 msi，必须在主程序之后装，顺序反了安装器会提示找不到 TortoiseGit，因为它要往主程序目录里写语言 dll。

安装路径上有个细节值得提前说：路径里不要带中文和空格之外的怪字符，尤其不要把 Git 装到同步盘目录（OneDrive、坚果云这类）下面。同步盘会实时扫描文件变更，.git目录动辄几万个小文件，扫描线程和 Git 的文件锁撞上，轻则操作卡顿，重则出现index.lock残留，之后每次操作都报 “Another git process seems to be running”。我一般把 Git 和 TortoiseGit 都放默认路径，项目目录单独放一个非同步盘的盘符。

装完先用命令行确认一遍，别急着点右键：

# 确认 git 在 PATH 里，且版本号能正常输出 git --version # 确认实际调用的是哪个 git.exe，多版本共存时这条能查出问题 where git

git --version输出版本号，说明 PATH 配置没问题；where git会列出所有命中的路径，如果第一行不是你刚装的那个，说明机器上还有旧版本（比如随某个 IDE 装的便携版）抢在前面。这时候要么调整 PATH 顺序，要么在 TortoiseGit 设置里手动指定路径，后者更省事。

提示：Git for Windows 安装向导里有一个 “Adjusting your PATH environment” 选项，保持默认的 “Git from the command line and also from 3rd-party software” 即可，选最下面那个 “Use Git and optional Unix tools from the Command Prompt” 会把find、sort这类 Unix 工具塞进 PATH，容易和 Windows 自带命令打架。

2.2 全局设置里三个必改项：语言、升级检查、git.exe 路径

在准备存放项目的目录里（比如E:\Git）空白处右键，选TortoiseGit → Settings，左边是一棵配置树，右边跟着切换。第一次进来建议按顺序处理三件事。

第一件是语言。选中General，右侧Language下拉里挑“简体中文”。如果下拉里根本没有中文选项，说明语言包没装上或者装到了别的目录，回去重装语言包，别在这儿死磕。语言切换后部分对话框要重新打开才生效。

第二件是升级检查。同一个General页面，把自动检查更新的勾去掉。内网开发机、隔离环境的机器上，这个检查会每次启动尝试联网，超时之后弹一个毫无意义的提示框，纯粹浪费注意力。关掉它不影响任何功能。

第三件是 git.exe 路径。还是在General页，有个 Git.exe Path 的输入框。新版 Git for Windows 默认装在C:\Program Files\Git，git.exe在cmd\和bin\下各有一份：

如果安装时改过盘符（老教程里常见的D:\Program Files\Git\bin），这里就要跟着改。填完点“应用”→“确定”，然后随便找个仓库右键看菜单里的操作是否还报错。

2.3 用户名邮箱与凭证助手：密码交给谁保管，这是个安全决策

切到左边树的Git标签，右侧上半部分是Name和Email两个输入框。这两个值会写进全局配置的[user]段，之后每一次提交都会把这两个信息烙进 commit 对象里，是永久性的——改配置只影响之后的提交，历史记录改不了。所以名字建议用真名或团队约定的工号形式，邮箱用公司邮箱，别用个人邮箱随手填，后面查 blame 的时候会感谢自己。

下半部分有两个按钮值得解释，因为翻译容易误导：

• “编辑全局 .git/config(O)” —— 改的是C:\Users\<用户名>\.git\config，对本机所有仓库生效。
• “编辑本地 .git/config(L)” —— 改的是当前仓库下的.git\config，只对这个项目生效。在没有打开任何仓库的情况下，这个按钮是灰色不可点的，不是坏了。

老教程里流行往里加一段：

[credential] helper = store

作用是把 HTTPS 方式推送时输入的用户名密码存下来，下次不再问。方便是真方便，代价是密码以明文形式落在C:\Users\<用户名>\.git-credentials里，一行一个站点，格式是https://user:password@host。任何能读这个文件的进程都能拿到你的仓库密码。公用机器、共享账号、公司配发但多人用过的机器上，这条绝对不要开。

更稳妥的做法是用系统凭证管理器（Git Credential Manager），凭据加密存在 Windows 凭据库中，TortoiseGit 新版本默认就走这条路。如果确实要用 store，至少把文件权限收紧到只有自己能读：

# 收紧 .git-credentials 的访问权限，只保留当前用户 icacls "$env:USERPROFILE\.git-credentials" /inheritance:r /grant:r "$env:USERNAME:(R,W)"

命令行等价写法，方便在脚本里批量配置：

# 全局身份，写进 ~/.git/config 的 [user] 段 git config --global user.name "张三" git config --global user.email "zhangsan@example.com" # 让 Git 记住 HTTPS 凭据（明文存储，评估后再用） git config --global credential.helper store # 确认配置落地 git config --global --list

git config --global --list会把全局配置按key=value全列出来，检查user.name、user.email、credential.helper三项是否都在。如果只想看某一项，用git config --global user.name单独取值。改错了要删，用git config --global --unset credential.helper，比手动去编辑文件可靠。

3. SSH Key 从生成到落到服务器：一次配置省掉无数次输密码

3.1 HTTPS 与 SSH 的取舍：不是谁更高级，是场景不同

本地仓库和远程仓库之间就两条通道，选哪条跟技术水平没关系，跟网络环境和使用频率有关系。

HTTPS 走 443 端口，任何能上网的地方基本都通，公司防火墙、酒店网络、客户现场，很少拦 443。代价是每次 fetch/push 都要过一次身份验证，配了凭证助手才能免输。另外部分托管平台对 HTTPS 推送要求用访问令牌（token）代替密码，第一次遇到会懵：明明密码没错，就是 403。

SSH 走 22 端口，一次配好密钥对，之后所有操作静默通过。代价是 22 端口在不少企业网络里是被封的，连不上就是连不上；而且公钥必须挂在你自己的账号下，换句话说，你对目标仓库得有权限，克隆别人的公开仓库倒是不受这个限制，但推送必须是你自己的。

团队里常见的做法是：日常开发机配 SSH，一次性看代码、临时拉个仓库用 HTTPS。两条通道可以共存，同一个仓库的 remote 地址随时能换。

3.2 用 Git GUI 生成密钥对，别去网上复制粘贴命令

先查有没有现成的。打开C:\Users\<用户名>\.ssh目录，看里面有没有id_rsa和id_rsa.pub这一对。有就直接跳到下一节，别重复生成——重复生成会覆盖旧私钥，而旧公钥可能已经挂在好几个服务器上了，覆盖之后那些仓库全部连不上，这是血泪经验。

没有的话，在任意文件夹空白处右键选Git GUI Here，弹出的窗口菜单栏Help → Show SSH Key。如果列表是空的，点Generate Key，拖动窗口里的进度条制造随机数（不是玄学，是给密钥生成器采集熵），生成完把文本框里的全部内容复制出来。这个文本框里的就是公钥。

命令行方式等价，而且参数可控性更好：

# -t 指定算法，-b 指定长度，-C 是注释，用来在服务器端区分是哪台机器 ssh-keygen -t rsa -b 4096 -C "work-pc-2024" # 一路回车，默认存到 ~/.ssh/id_rsa，密码短语可以留空 ls -l ~/.ssh

参数逐个说：-t rsa是算法类型，兼容性最好，几乎所有服务端都认；-b 4096是密钥长度，2048 现在偏短，4096 生成慢一点但一劳永逸；-C后面的注释不参与加密，纯粹是给人看的，强烈建议写上“机器名+年份”，将来在服务器上看到一堆公钥时能分辨哪个该删。生成过程会问你要不要设 passphrase，设了更安全但每次用都要输，日常开发机一般不设，笔记本外带的话建议设。

生成完目录里是两样东西：id_rsa是私钥，绝对不能外发、不能进版本库、不能放共享盘；id_rsa.pub是公钥，可以随便给。顺手确认一下.ssh目录没有被同步盘接管，私钥泄出去等于把仓库钥匙给了别人。

3.3 公钥上传之后，还有一道 SSH client 的坎

把id_rsa.pub的内容整段复制（从ssh-rsa开头到注释结尾，必须是一行，中间不能有换行），登录代码托管平台，找到 SSH Keys 设置页，新建一个，粘贴进去保存。自建 Git 服务（Gitblit、GitLab 社区版这类）的入口通常在用户中心或头像菜单下的 SSH Keys。

上传完先别急着克隆，先在命令行验证连通性：

# -v 输出握手细节，首次连接会问是否接受主机指纹，输 yes ssh -vT git@your-git-host.example.com

期望看到的是类似Hi <用户名>! You've successfully authenticated的欢迎语。如果报Permission denied (publickey)，按这个顺序查：公钥有没有粘全（末尾少几个字符也会失败）、粘的是不是.pub文件的内容、服务端账号是不是你当前登录的这个、-i指定的私钥路径对不对。

真正容易翻车的地方在 TortoiseGit 这一侧。它默认使用的 SSH 客户端不是 OpenSSH，而是自带的TortoisePlink，只认 PuTTY 格式的.ppk私钥。你用ssh-keygen生成的是 OpenSSH 格式的id_rsa，直接点克隆，会得到一句No supported authentication methods available或者disconnected: no supported authentication methods available (server sent: publickey)。第一次遇到会以为是公钥没配好，反复重传，其实公钥一点问题没有。

两条路解决。要么把id_rsa转成.ppk（用 PuTTYgen 导入再另存），要么把 TortoiseGit 的 SSH 客户端换成 OpenSSH——后者更省事，我一般这么做：Settings → Network，把SSH client那一栏改成C:\Program Files\Git\usr\bin\ssh.exe。改完确定，重新克隆即可。这一步在各类教程里经常被跳过，导致读者卡在“公钥明明传了为什么还连不上”。

4. 克隆、提交、拉取、推送：一个本地项目跑通完整往返

4.1 克隆：URL 填对，空仓库那个报错别慌

在准备放项目的目录空白处右键，选Git 克隆 / Clone，弹出对话框三样东西要填：URL、目标目录、分支。URL 从仓库页面复制，注意区分 HTTPS 和 SSH 两种形式，别把 SSH 地址粘到只支持 HTTPS 的代理配置里。

URL 粘错、公钥没配、目录非空，是这个对话框最常见的三种失败。目录非空时 TortoiseGit 会拒绝克隆，因为目标目录里已有的文件可能被覆盖。做法是先建一个空子目录，克隆到子目录里。

还有一种情况：仓库在服务端刚创建，一个提交都没有。克隆时会报：

fatal: Couldn't find remote ref HEAD

这不是你配错了。Git 的 HEAD 指向一个分支引用，空仓库里连分支都不存在，HEAD 自然解析不出东西。解决办法是先在服务端做一次初始化提交（网页端加个 README），或者本地先git init、提交一次、再推上去。老教程里没提这个坑，很多人在自建服务上建完空仓库就卡在这儿。

克隆成功的标志是文件夹图标右下角出现绿色对号。如果没有角标但文件都在，看第 5 章第 1 条。

命令行验证克隆结果的等价操作：

# 查看 remote 地址是否正确指向目标仓库 git remote -v # 查看当前分支与最近三次提交 git log --oneline -3 # 查看工作区状态，克隆完应该是 clean git status

git remote -v会输出 fetch 和 push 两条地址，正常情况下一致。如果克隆后用 HTTPS、后来想换 SSH，不用重新克隆，git remote set-url origin <新地址>一条命令换掉即可，历史记录和本地分支都保留。

4.2 提交：这是纯本地操作，不会联网

改完文件，在项目目录空白处右键，Git 提交(C) -> "master"（分支名会跟着当前分支变）。提交对话框分三块：左上角是改动文件列表，勾选哪些就提交哪些；下方是提交信息输入框；中间还有变更预览，双击文件能看逐行差异。

这里有个习惯值得养成：提交前先双击看一遍 diff。图形界面的便利之处就在这，不用记git diff的输出格式，红色删除、绿色新增一目了然。见过太多人一次勾三四十个文件、写一句“修改”，半年后出问题往回查，日志里全是黑匣子。

提交信息写什么，团队规范不一，但最低要求是“说清这次改了什么、为什么改”。一句话能说清就别写两句，说不清说明这次提交塞了太多不相关的东西，该拆。

再强调一遍：提交（Commit）只写本地仓库，不联网、不碰服务器。很多人点完提交就以为代码已经上去了，关了电脑回家，第二天同事拉不到，这是最常见的新手误解。真正上传是下一步的推送。

# 提交后确认本地领先远程几个提交 git status # 看最近提交的哈希和说明 git log --oneline -5 # 看本地分支与远程分支的领先/落后关系 git branch -vv

git branch -vv的输出里，[origin/master: ahead 2]表示本地比远程多两个提交，还没推。ahead和behind两个数字是判断“该拉还是该推”最直接的依据。

4.3 拉取再推送：顺序反了整个流程就得重来

提交完点推送，如果远程有你没拉过的提交，会被拒绝，报non-fast-forward。避免的方法很朴素：推之前先拉。

在项目目录右键 →Git 同步，弹出同步窗口。这个窗口把拉取、推送、日志三件事放在一个界面，比来回点右键菜单高效。点“拉取(P)”，把远程分支的更新取回本地并合并。

结果只有两种。远程没变化，提示“已经是最新的”，直接点“推送(H)”；远程有变化且没冲突，Git 自动合并，本地多出一条合并记录（或者快进），然后推送；远程有变化且同一文件的同一区域被改过，冲突，文件上出现黄色感叹号，内容里插入<<<<<<<、=======、>>>>>>>三段标记。

冲突不是故障，是 Git 把决策权交回给人。做法是打开文件，把三段标记连同不要的内容一起删掉，保留最终想要的版本，保存，右键该文件选解决冲突 → 标记为已解决，然后提交、推送。别直接删标记就完事，删之前想清楚这段逻辑到底该保留谁的。

# 拉取时用 rebase 代替默认 merge，历史更线性 git pull --rebase origin master # 冲突解决后继续 rebase git rebase --continue # 中途想放弃，回到拉取前的状态 git rebase --abort

--rebase和默认合并的区别：默认合并会产生一个“Merge branch 'master' of ...”的合并提交，多人频繁拉取时历史会变成一团乱麻；--rebase把你本地的提交“摘下来”，接到远程最新提交之后，历史是一条直线。团队没有强制要求时，我一般用 rebase，看日志干净。但注意 rebase 会改写提交哈希，已经推到远程的分支不要 rebase，会坑到别人。

推送时如果弹出用户名密码框，说明当前用的是 HTTPS 通道且没配凭证助手，填一次即可（配了 store 或凭证管理器就不会再问）。第一次连新服务器还会问是否接受主机密钥指纹，选是，指纹会写进known_hosts，之后不再问。

4.4 角标与分支：把七种图标当成状态指示灯

资源管理器的图标角标是 TortoiseGit 最有价值的部分，它把仓库状态压缩成一个视觉信号。七种常见状态：

蓝色问号和蓝色加号最容易混：问号是“Git 不知道这个文件”，得先“添加”；加号是“已经加入暂存区，等着提交”。很多人改了新文件直接点提交，发现列表里没有，就是因为没先添加。

分支操作在右键菜单TortoiseGit → 切换/检出、创建分支、合并里。日常节奏是：主分支保持可发布状态，功能开发开新分支，做完合并回去。切换分支前先确认工作区干净（没有红色感叹号和黄色感叹号），否则切换会被拒绝或者把改动带过去，后者更麻烦。

# 列出本地分支及跟踪关系 git branch -vv # 新建并切换到功能分支 git checkout -b feature/login # 合并回主分支（先切回 master） git checkout master git merge --no-ff feature/login

--no-ff强制产生一个合并提交，好处是分支历史可追溯，能一眼看出“这一坨改动是一个功能”，代价是日志多一层。小团队、提交频繁的场景用不用都行，关键是团队统一。

5. 避坑与排查：图标消失、冲突收尾、认证反复失败

5.1 现象：所有角标变回普通文件夹图标

现象：右键菜单一切正常，能提交能推送，但资源管理器里所有文件都是普通图标，没有任何绿色对号或红色感叹号。

原因：Windows 资源管理器对图标覆盖（Overlay Icon）有硬性限制，整机最多注册 15 个覆盖标识，按注册表里的字母顺序取前 15 个。装了几个网盘客户端、压缩软件、同步工具之后，TortoiseGit 的标识被挤到 15 名开外，系统直接不显示。另一种情况是安装时没勾选“Icon Overlays”组件。

解决：打开注册表编辑器，定位到HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers，看TortoiseGit开头的项排在第几位。在项名前面加空格（加一个空格就前移一位），把它顶到前 15 名内，然后重启资源管理器进程：

# 重启资源管理器让图标缓存刷新 Stop-Process -Name explorer -Force

64 位系统上这个注册表路径还有Wow6432Node分支，两处都要检查。如果项根本不存在，说明安装时组件没选，重新运行安装包修复。

5.2 现象：拉取后文件全是冲突标记，不知道从哪下手

现象：同步窗口点拉取，提示有冲突，文件图标变黄色感叹号，打开文件看到<<<<<<< HEAD、=======、>>>>>>>三段内容交织。

原因：你改的文件和远程别人改的文件，落在同一区域。Git 无法判断该保留谁，于是把两版都塞进文件里等你裁决。这跟操作失误无关，是正常的协作结果。

解决：别慌，也别用“强制拉取覆盖本地”这种操作——那会直接丢掉你未提交的改动。逐个文件打开，按业务逻辑决定保留哪段，删掉三段标记。改完保存，右键文件TortoiseGit → 解决冲突 → 标记为已解决，全部处理完再提交、再推送。冲突文件多的时候用TortoiseGit → 编辑冲突打开三方合并工具，左边本地、右边远程、中间结果，比手改文本高效得多。

5.3 现象：密码明明改对了，推送还是 403 或者一直弹框

现象：在托管平台改了账号密码，本地推送反复失败；或者每次操作都弹认证框，填了也不记住。

原因：两条线索。用 HTTPS +credential.helper=store的，旧密码已经明文存在C:\Users\<用户名>\.git-credentials里，Git 每次都拿旧密码去认证，服务端自然拒绝。用 SSH 的，TortoiseGit 的 SSH client 指向TortoisePlink，不认 OpenSSH 格式的id_rsa，表现是一连串认证失败。

解决：HTTPS 的，打开.git-credentials，删掉对应站点那一行，或者整文件清空后重新推一次让它重写。Windows 凭据管理器里也存了一份，在“控制面板 → 凭据管理器 → Windows 凭据”里找到对应条目删除。SSH 的，去Settings → Network把 SSH client 改成C:\Program Files\Git\usr\bin\ssh.exe，再试。

5.4 现象：推送被拒，提示 non-fast-forward

现象：点推送，弹窗报rejected、non-fast-forward，或者中文的“推送被拒绝，需要先拉取”。

原因：远程分支上有你本地没有的提交。Git 拒绝推送是为了防止你用旧历史覆盖别人的新提交，这是保护机制不是故障。

解决：先拉取，有冲突按 5.2 处理，没冲突直接推。绝对不要在共享分支上用强制推送（--force）绕过这个检查，那等于把同事的提交从历史上抹掉，找回来非常麻烦。只有自己独占的特性分支、且确定要重写历史时，才考虑--force-with-lease，它会先检查远程有没有别人的新提交，比裸--force安全一档。

5.5 现象：只改了一个字符，整个文件显示全改；中文名显示成八进制

现象：diff 里一行没动的地方也标红，或者文件名显示成\346\226\207\346\241\243.txt这种转义串。

原因：换行符问题。Windows 用 CRLF，Linux/macOS 用 LF，两边没统一时 Git 会把整文件视为逐行变更。中文名乱码是core.quotepath默认开启，Git 把非 ASCII 字符转义输出了。

解决：

# Windows 开发机：提交时转 LF，检出时转 CRLF git config --global core.autocrlf true # 让 Git 直接输出中文文件名 git config --global core.quotepath false

core.autocrlf三个取值要分清：true给 Windows，input给 Linux/macOS，false表示不做任何转换。团队里如果有人设false有人设true，同一个文件会在两人之间来回“全文件修改”，这是最典型的配置不一致事故。项目根目录放一个.gitattributes文件写死规则，比靠每个人自觉可靠。

6. 把右键菜单用成流水线：提交前那五步自检

配置调通只是起点，真正决定这套工具好不好用的是日常节奏。我现在的习惯是把操作压缩成固定五步，每步对应右键菜单里的一个入口，走完一遍不超过两分钟，但能挡掉八成的返工。

第 3 步最容易被跳过，也最容易出事。图形界面的 diff 面板比命令行友好得多，双击文件就能看逐行对比，红色删除绿色新增，扫一眼就知道有没有把本地调试用的console.log、测试账号密码、绝对路径带上去。这种事出一次就够记一辈子。

再补一个进阶用法：TortoiseGit → 显示日志打开日志窗口，选中任意一次提交，右键能对单个文件做“追溯（blame）”，逐行看这行代码是哪次提交、谁改的、当时写了什么说明。排查“这行诡异的判断是谁加的”这类问题时，比翻聊天记录快得多。日志窗口还能选两个提交做对比，输出完整差异，做发布前的变更评审很顺手。

最后说个我自己的教训。早年带一个项目，图省事在全局配置里开了credential.helper=store，机器是团队共用的测试机，谁都能登。某天发现仓库里多了几个不属于任何人的提交，查了半天才反应过来是.git-credentials里的明文密码被读走了。从那以后我每台机器配完环境，第一件事是确认凭证助手的类型，共用机器一律改成系统凭据管理器，个人机器才考虑 store，而且配完立刻用icacls收权限。这份 TortoiseGit 使用教程里的配置章节我反复看了几遍，就是因为它把“记住密码”当成一个便利功能在讲，而实际用起来，它同时是个安全决策——便利和安全从来都是一枚硬币的两面，选之前得知道自己放弃的是什么。

希望帮到你。

本文还有配套的精品资源，点击获取