记得刚开始用Git那会儿，我真的是被命令行劝退了好几轮。每次无非就是add、commit、push，偏偏记不住参数，一紧张就查文档，查完又忘。后来换了TortoiseGit，才发现原来图形化操作Git可以这么省心：右键菜单点一点、文件状态看一眼图标就知道改没改，提交记录也能像看历史时间线一样直观。这篇笔记就围绕TortoiseGit基本使用来写，重点是把本机已有的Git版本库完整上传到Github远程版本库的整套流程，顺带把我踩过的坑、绕过的弯路一次说清楚。这篇文章适合那些装了Git但是不习惯命令行、想在Windows上用鼠标搞定一切的人，也适合刚接触Github、想把本地项目托管到远程仓库的初学者。1. 为什么我推荐TortoiseGit而不是直接在终端敲命令先说明一点：TortoiseGit不是Git本身，它是Git的图形化外壳。Windows上你必须先装好Git for Windows（就是那个能提供git.exe的环境），再装TortoiseGit，它才能接手工作。很多人以为装了TortoiseGit就等于装了Git，其实是两回事，这个先后顺序别搞反。它在Windows上最讨喜的地方是深度集成到了资源管理器右键菜单。你在文件夹里点右键，就能看到Git Clone、Commit、Push、Pull这些操作，不需要打开终端输入命令。而且它会给每个文件和文件夹叠加小图标状态标记，绿色勾表示已提交且没有改动，红色感叹号表示文件被修改过，蓝色加号表示新增文件在暂存区。文件有没有变化、变化有没有提交，扫一眼图标就知道，这种直观程度是纯命令行环境给不了的。有人可能会说，命令行也就几句话的事，何必用GUI？我的看法是，Git命令的高频场景其实就那么十来个，确实不难记。但Git的问题不在高频命令，而在出错时的处理逻辑。比如merge冲突、rebase中断、push被拒绝，这些场景在命令行下新手很容易懵，屏幕上一长串提示也不知道该听谁的。而TortoiseGit会把冲突文件列出来，用右键就能选“保留本地版本”还是“采用远程版本”，操作路径清晰很多。第二个推荐理由是它支持跨平台协作时常见的文件操作习惯。你可以在Windows资源管理器里直接比较版本差异、看提交历史、打标签，甚至查看某个文件是谁在什么时候改的，这些操作在TortoiseGit的日志对话框里做得非常直观。对于记不住命令、不喜欢盯着黑窗口的人来说，这是效率最高的路径。不过也要客观说一句：如果你是长期靠SSH远程登录服务器操作代码的开发者，那命令行终归绕不开。TortoiseGit适合的是本机开发、Windows桌面环境为主的场景。它帮你把“本机管理代码”这件事彻底图形化，但服务器上的Git操作还是得靠命令。这两者不冲突，反而互补。2. 装完之后别急着用，先调这三个配置很多人装完TortoiseGit就直接clone仓库，结果一提交发现中文乱码，或者push一直报认证失败，又或者文件图标怎么都不显示。这些问题大多不是TortoiseGit坏了，而是装完没做基础配置。下面这三个配置，我建议每个新装完的人先过一遍。2.1 用户名和邮箱：不设的话提交记录会变成“未知用户”TortoiseGit虽然支持在每次提交时弹窗让你填作者信息，但更稳妥的做法是在全局配置里固定好。打开任意文件夹，右键 -> TortoiseGit -> Settings -> Git，右侧有“用户名”和“邮箱地址”两个输入框，填成你自己的信息。注意这里填的用户名不是Github登录账号，是你在Git提交记录里展示的名字，邮箱也不要求必须和Github注册邮箱一致，但建议保持一致，这样Github能把你本地的提交和账号关联起来，头像和贡献图才正常。设置会自动写到全局.gitconfig里，以后所有仓库共用这套身份。如果某台机器上同时有工作账号和个人账号，那不要在全局这里填，应该在每个仓库的右键Settings里单独设置。2.2 中文乱码：输出编码和提交信息编码要被强制写成UTF-8Windows环境下中文乱码是出场率最高的坑。表现有两种：一种是TortoiseGit的日志信息里中文显示成乱码，另一种是命令行版Git中文路径显示成八进制转义符。不管哪种，根源都是编码不一致。默认情况下Windows使用GBK编码，而Git内部统一用UTF-8，不统一当然乱码。要解决，先打开Settings -> Git，找到“编辑全局.gitconfig”，在文本末尾追加以下行：[gui] encoding = utf-8 [i18n] commitencoding = utf-8 [core] quotepath = falsegui.encoding = utf-8告诉TortoiseGit用UTF-8解析界面和日志；commitencoding = utf-8保证提交信息按UTF-8保存；quotepath = false让中文路径不要被转义成八进制。改完保存，重启TortoiseGit，再打开日志对话框，中文基本就正常了。2.3 SSH客户端：选OpenSSH还是PuTTY要看你的密钥类型TortoiseGit在安装过程中会让你选SSH客户端，这个选择很多人都是随手点的，但它直接决定你之后连接Github用哪种密钥。两个选项分别是OpenSSH（Windows自带的ssh.exe或Git自带的）和TortoiseGitPlink（PuTTY的链路）。如果你选OpenSSH，那密钥文件是标准的OpenSSH格式，也就是用ssh-keygen生成的那对id_ed25519和id_ed25519.pub，和命令行Git共用一套；如果你选PuTTY，那密钥得用PuTTYgen生成.ppk格式，两者格式不通用。我个人推荐装新版时直接在设置里选OpenSSH。理由很简单：省事。你可以用命令行Git默认的密钥直接连接，不需要额外转格式，也不需要开Pageant加载密钥。Github官方文档里给的做法也是OpenSSH格式。如果你已经装完了，可以在Settings -> Network -> SSH Client里改。但要注意，改完之后测试连接方式也会跟着变，如果之前用PuTTY连接成功过，切换后需要重新生成或转换密钥。另外，如果文件图标不显示，去Settings -> Icon Overlays看看状态缓存设置。一般默认是“既调用状态缓存，也启用watch”，超过一定数量的文件时刷新会变慢甚至失灵。可以改成“仅调用状态缓存”，还能顺便解决和某些网盘软件抢占右键菜单导致的图标异常问题。3. 日常使用：克隆、提交、推送、拉取，围绕右键菜单捋一遍TortoiseGit的日常操作基本都集中在右键菜单里，但菜单选项多，新手容易分不清该点哪个。这一节按一条完整的开发链路往下走：从远程拿到代码、改代码、提交、推回去、再拉更新，每一步对应哪个入口、该注意什么。3.1 克隆远程仓库：URL决定了你走HTTPS还是SSH在本地新建目录，或者进入某个空目录，右键 -> Git Clone，把Github仓库的URL填进去。URL有两种格式：HTTPS的https://github.com/用户名/仓库名.git，SSH的git@github.com:用户名/仓库名.git。选哪种取决于你后续打算怎么认证。用HTTPS的话，首次push会弹窗要求验证身份，密码框填Personal Access Token而不是账号密码；用SSH的话，客户端会用密钥自动认证，不需要每次输token。关于认证后面专门讲，这里先记住一点：URL里不要带用户名和token。Clone的时候有个细节，对话框里有一项“Branch”，默认是空，表示克隆远端默认分支的所有历史。如果想节省时间只拉某个分支，可以填分支名，但新手不建议动，保持默认即可。另外TortoiseGit的Clone对话框支持勾选“递归克隆子模块”，如果项目里用了submodule，这个勾一定要打上，否则子模块内容拉不全。3.2 提交：先看差异，再选文件，最后写信息改完代码后，文件列表里会出现红色感叹号或蓝色问号图标。这时候右键文件 -> TortoiseGit -> Commit，会打开提交对话框。界面分两部分，上面是待提交文件的勾选框列表，下面是提交信息输入框。这里最容易被忽略的是“查看差异”按钮——提交之前一定养成习惯，双击每个文件，对比一下改动内容，确认没有误改、没有把调试代码带进去，再提交。提交信息建议写得有内容一点，比如“修复登录接口空指针问题”，不要写“更新”、“修改”这种一句废话。写清楚提交目的，一个月后翻日志还能想起来当时在干什么，这对个人项目尤其重要。提交时还有一个选项叫“包含工作目录中的新文件/修改文件”，默认勾选。如果你只想提交某几个文件，去掉自动勾选，只勾需要的文件就行。这个功能对“拆提交”很实用，比如一次改了三个功能点，就可以分三次提交，每次只勾对应文件，历史记录干净。3.3 推送：本地提交记录到远程仓库的过程Commit只是把改动记录在你本机仓库里，别人看不到，Github上也看不到。要让改动到远程，还得右键 -> Push。推送对话框里“Remote”选origin，“Branch”默认是本地当前分支。一般情况下直接点OK就好。这里要理解push和pull的区别。push是“把本地新提交推送到远程”，pull是“把远程新提交拉回本地”。两者方向相反，操作触发点不同：你改完代码要分享出去，是push；别人改完了你要拿最新的，是pull。还有一个fetch，它和pull很像但更温柔——fetch只把远程更新拉到本机的origin/xxx分支上，不帮你合并到工作区，pull则是fetch加merge一步到位。日常协作中，如果怕自动合并出意外，可以先fetch再右键查看分支比较，手动确认后再merge。3.4 拉取更新与解决冲突从远程拉代码，右键 -> Pull，对话框里会问合并策略。新手建议保持“Merge”不变，别碰“Rebase”。Merge会生成一个合并提交，历史里能看到“什么时候把远程分支并进来”，对个人项目完全够用；Rebase会把本地提交“搬”到远程提交之后，历史更线性，但改写历史有风险，不适合没经验的人玩。拉取最大的麻烦是冲突。判断标准很简单：Pull之后，如果某个文件同时显示红色感叹号和黄色感叹号的组合图标，说明这个文件冲突了。右键 -> Edit Conflicts，TortoiseGit会打开冲突编辑窗口，左边是本地版本，右边是远程版本，下面是你正在处理的合并结果。每一处冲突都要决定“保留本地”、“保留远程”还是“两边都保留”，手工处理后保存，再右键文件标记为“已解决”。这个过程第一次遇到会觉得紧张，其实只要记住：冲突的每一处都是二选一或二合一的取舍，选完保存、标记已解决、提交，就好了。4. 本地版本库上传Github的完整流程：四步把一个现有文件夹变成远程仓库这是很多人最关心的部分：我在本地有个项目文件夹，用TortoiseGit管理了一段时间，现在想整体推到Github上建个远程仓库。整个流程其实就四步，但它包含了几个最容易踩的坑，尤其是“远程仓库里已有文件”和“首次推送需要设置上游分支”这两个。4.1 第一步：在Github上创建空仓库，千万别勾初始化文件登录Github，点右上角加号 -> New repository，填好仓库名和可见性。有一个满屏都该注意的选项：是否勾选“Add a README file”和“.gitignore template”。对于已经存在本机仓库的情况，这两个选项一律不要勾，保持新仓库完全空白。原因很简单：如果你的Github仓库里有了README或者LICENSE，而本地仓库还没有这个文件，那么第一次push的时候Git会拒绝合并无关历史，因为两边在各自的起点上产生了不同提交记录。一旦发生这种拒绝，新手很容易陷入“强行推送覆盖远程”的冲动，那样会丢掉远程仓库里的初始化文件，或者引发更混乱的历史。正确做法就是让远程仓库保持空的状态，等本地第一版推上去再说。4.2 第二步：在本地文件夹里创建版本库如果你还没有在本地文件夹里初始化过Git仓库，右键文件夹 -> TortoiseGit -> 在此创建版本库。弹窗里会问“创建一个裸仓库吗”，选“不创建裸仓库”，这是标准的工作仓库模式。创建完成后，文件夹里会多一个隐藏的.git目录，这就是整个版本库的核心。如果之前已经用命令行Git创建过版本库，那这步跳过。不过还是建议确认一件事：右键 -> TortoiseGit -> Show Log，可以看到当前分支名。现在Github的新仓库默认分支叫main，而旧习惯是master。本地的分支名不一定要和远程一致，推送时可以指定把本地master推送到远程main，但我建议干脆统一。如果本地还没提交任何东西，最简单的方式是右键 -> Switch/Checkout -> 在“创建新分支”里输入main，确定后本地默认分支就改成main了，之后的提交都落在main上。4.3 第三步：配置Remote，把本地仓库和Github仓库关联起来本地仓库现在还不知道要去哪里，需要手动告诉它远程地址。右键 -> TortoiseGit -> Settings -> Git -> Remote，点击“Add”，Remote名称填origin（这是约定俗成的默认名，之后所有推送拉取都靠它），URL填Github仓库地址，类型按你的认证方式选HTTPS或SSH。填完点“Add/保存”，origin就出现在远程列表里了。这一步做完后，可以回到主界面右键 -> Fetch，看能不能从origin取到信息。因为远程是空仓库，fetch不会拉下任何东西，但只要没有报错，就说明网络和远程地址都没问题。4.4 第四步：首次推送，顺便设置上游分支右键 -> Push，Remote会默认选中origin。此时如果你本地在main分支上，Push对话框里会显示“Branch：main”，点确定开始推送。首次推送时TortoiseGit会弹出认证窗口，按前面讲的HTTPS填token或SSH密钥自动认证。推送完成后，对话框里会提示你是否设置了上游跟踪分支，建议勾选“设置上游”。这个“上游”的作用是让本地main分支记住自己对应的远程分支是origin/main，以后pull和push就不用每次指定分支了，直接右键点Pull/Push就没问题。如果没有在弹出的对话框里完成，也可以右键 -> Branch -> 选中main -> 勾选“更新上游跟踪分支”来补救。如果你在第一步看错了，远程仓库创建时勾了README，那么push多半会被拒绝，提示类似“fetch first”或“non-fast-forward”。这种情况下我最推荐的处理方式：不要强推，先Pull一次，把远程的README合并到本地，合并信息自动生成，然后再Push。两种历史被一个合并提交接起来，干净且没有丢内容。5. 认证问题：为什么输入账号密码一直失败这个问题被问得最多，而且几乎每个第一次用HTTPS方式连接Github的人都会栽一遍。你兴冲冲地Push，弹窗让你输用户名密码，你把Github的账号和邮箱密码填进去，结果每次都报认证失败。这不是你密码错了，而是Github从2021年8月起彻底停用了账号密码形式的Git操作认证，现在必须用Personal Access Token（个人访问令牌）当密码用，或者直接用SSH密钥认证。5.1 用HTTPS连接：生成一个当密码用的Token打开Github网页，头像 -> Settings -> Developer settings -> Personal access tokens -> Tokens (classic)，点Generate new token (classic)。Note填个能记住用途的名字，比如“tortoisegit-push”，Expiration看自己需要，个人项目选90天或No expiration都行，然后勾选repo这一个范围。生成后页面上会显示一串以ghp_开头的字符串，这个字符串只会完整显示这一次，一定要当场复制保存。然后回到TortoiseGit，在首次push弹出的认证窗口里，用户名栏输入你的Github用户名（不是邮箱也行），密码栏粘贴那串ghp_开头的token。由于TortoiseGit底层走的是Windows凭据管理器，认证成功之后token会被保存下来，后续再push通常不会再弹窗。如果以后token过期了，重新生成一个，然后在Windows的凭据管理器里找到对应条目删掉，下次push会重新弹窗让你填新token。有个细节提一下：千万不要把token以https://用户名:token@github.com/...的形式写进Remote URL里。那样token会明文存在.git/config文件里，一旦这个文件被提交或者被截图，等于账号直接泄露。正确的做法就是让凭据管理器代管，别手动拼URL。5.2 用SSH连接：生成密钥，配置到Github嫌token麻烦，或者不想每次到期都重新生成的话，用SSH更舒服。前提是TortoiseGit的SSH客户端设置成了OpenSSH（前面第2.3节提过）。打开Git Bash或CMD，执行：ssh-keygen -t ed25519 -C "你的邮箱@example.com"一路回车，会在用户目录的.ssh文件夹下生成id_ed25519和id_ed25519.pub两个文件。前者是私钥，绝对不要发给任何人；后者是公钥，可以公开。用文本编辑器打开id_ed25519.pub，复制全部内容，到Github网页 -> Settings -> SSH and GPG keys -> New SSH key，Title随便填，Key粘贴进去，保存。然后验证连接是否成功：ssh -T git@github.com如果看到类似“Hi 用户名! You've successfully authenticated”的提示，说明密钥配置好了。之后TortoiseGit的Remote URL改成git@github.com:用户名/仓库名.git，push时客户端会直接用私钥完成认证，不再弹窗输入任何密码。这个体验比token顺畅不少，比较推荐一劳永逸的方式。6. 用TortoiseGit久了容易犯的错：我踩过的几个坑工具用熟了之后，真正影响效率的不是不会操作，而是那些隐藏很深、平时不起眼的小问题。这几个坑我都实际踩过，写出来算是帮后来人省点时间。6.1 换行符CRLF导致整个文件都被标记为修改Windows系统里的文本文件换行符默认是CRLF，而Linux/Mac上用LF。Git为了跨平台协作，提供一个自动转换功能。如果某个项目里混合了不同换行符，你明明只改了一行，打开Diff一看整个文件几千行全是改动，非常劝退。这个问题根源通常是autocrlf配置不对。TortoiseGit默认安装会在全局配置里启用core.autocrlf=true，对纯Windows项目问题不大，但如果你在Windows上开发部署到Linux的项目，这个设置反而容易制造假改动。一个实用策略是：看项目里有没有.gitattributes文件，这个文件能逐路径规定换行符规则，比全局autocrlf靠谱得多。如果没有，个人项目建议在仓库根目录建一个，写入：* text=auto *.sh text eol=lf *.bat text eol=crlf这样明确约定各类文件的换行方式。注意改完.gitattributes之后记得重新commit一次，让Git按新规则规范化文件，否则之前的文件还是旧规则下的状态。6.2 “本地有改动”和“本地需要提交”是两回事TortoiseGit文件夹图标最让人踏实的一点是能随时看到仓库状态，但也容易造成一种错觉：图标变成红色感叹号就觉得工作区有问题。其实红色感叹号只说明文件内容和最近一次提交不一致，这种不一致是正常开发状态。真正要关注的是Commit对话框里“未提交的更改”和“已暂存的更改”两部分。你改了文件但不commit，改动只存在于工作区；一旦commit，这次改动就变成一个历史节点，可以随时回退。搞清楚这个边界，就不会出现“明明改了代码，push后远程却没有”的困惑了。6.3 误点Revert，把没提交的改动全丢掉了Revert这个功能，从名字上看像是“撤销提交”，但在TortoiseGit的右键菜单里，它默认对选中的文件执行“回滚到最近一次提交状态”。也就是说，你在文件上点了Revert，所有未提交的修改会直接丢失，且不会进回收站。这个功能很危险，尤其新手容易把它当成“撤销上一步操作”。如果你只是想撤销某一次提交，应该去Show Log里选择那次提交，然后右键选“Revert change by this commit”，那是生成一个反向提交来抵消旧的改动，不会碰你的工作区内容。区分这两个入口，能避免一次痛彻心扉的数据丢失。6.4 Windows路径过长或中文目录导致的操作失败Windows的路径最大长度默认260字符，如果项目目录层级很深、文件名又长，Git操作经常会报错。一个推荐做法是在Git for Windows安装时勾选“启用长路径支持”，或者通过组策略修改系统长路径限制。中文目录名本身不一定有问题，但某些老项目和工具链确实对非ASCII路径支持不好，建议新项目目录统一用英文字母命名。另外，仓库路径里尽量不要有空格和特殊符号，TortoiseGit对这类路径偶尔会报“fatal: Unable to create ...”，排查起来很闹心。6.5 忘了提前写.gitignore，把依赖目录一起提交了个人项目最常见的尴尬就是第一次提交时不小心把node_modules、target、build、.idea、__pycache__这类目录一起提交进去了。这些文件又大又没意义，还导致仓库体积暴涨。解决方法是仓库创建之初就准备.gitignore。TortoiseGit在右键创建版本库时并不会自动生成这个文件，你可以到Github新建仓库页面复制官方维护的模板，或者用现成的主流项目模板。如果已经误提交进去了，别指望直接删文件就能把它从Git历史里抹掉，那些目录还是躺在历史记录里。正确的清理方式是用git filter-branch或git-filter-repo改写历史，但这是相对操作，新手不建议单独研究，更建议吃一堑长一智，新项目从一开始就配好.gitignore。6.6 强推（Force Push）不到万不得已别用Push对话框里有一个“Force”选项，字面意思是强制把本地历史覆盖到远程。听起来很霸气，但它的实际效果是：远程仓库那些本地没有的提交会被直接丢弃。在多人协作的仓库里，一次强推等于抹掉别人的提交记录，属于事故级操作。即使是个人仓库，也只在远程历史已经乱到无法收拾时才考虑。如果你的push被拒绝，先按第4.4节的流程Pull合并，实在不行再考虑强推，而且强推前一定要确认远程上的提交没有独有内容。写了这么多，其实最想传达的还是那个感受：工具不在多，顺手就行。TortoiseGit这种图形化外壳，表面上只是把命令换成了按钮，但它真正降低的是“确认当前状态”的成本——文件有没有改、改了什么、提交后在什么位置，全部可视化呈现出来。配合第4节那套“空远程仓库起步、首推带上游”的流程，再把认证方案一次配好，后面的日常操作基本就是右键点几下的肌肉记忆。至于那些坑，遇到一次记下处理方式，下次就免疫了。
记得刚开始用Git那会儿，我真的是被命令行劝退了好几轮。每次无非就是add、commit、push，偏偏记不住参数，一紧张就查文档，查完又忘。后来换了TortoiseGit，才发现原来图形化操作Git可以这么省心：右键菜单点一点、文件状态看一眼图标就知道改没改，提交记录也能像看历史时间线一样直观。这篇笔记就围绕TortoiseGit基本使用来写，重点是把本机已有的Git版本库完整上传到Github远程版本库的整套流程，顺带把我踩过的坑、绕过的弯路一次说清楚。这篇文章适合那些装了Git但是不习惯命令行、想在Windows上用鼠标搞定一切的人，也适合刚接触Github、想把本地项目托管到远程仓库的初学者。1. 为什么我推荐TortoiseGit而不是直接在终端敲命令先说明一点：TortoiseGit不是Git本身，它是Git的图形化外壳。Windows上你必须先装好Git for Windows（就是那个能提供git.exe的环境），再装TortoiseGit，它才能接手工作。很多人以为装了TortoiseGit就等于装了Git，其实是两回事，这个先后顺序别搞反。它在Windows上最讨喜的地方是深度集成到了资源管理器右键菜单。你在文件夹里点右键，就能看到Git Clone、Commit、Push、Pull这些操作，不需要打开终端输入命令。而且它会给每个文件和文件夹叠加小图标状态标记，绿色勾表示已提交且没有改动，红色感叹号表示文件被修改过，蓝色加号表示新增文件在暂存区。文件有没有变化、变化有没有提交，扫一眼图标就知道，这种直观程度是纯命令行环境给不了的。有人可能会说，命令行也就几句话的事，何必用GUI？我的看法是，Git命令的高频场景其实就那么十来个，确实不难记。但Git的问题不在高频命令，而在出错时的处理逻辑。比如merge冲突、rebase中断、push被拒绝，这些场景在命令行下新手很容易懵，屏幕上一长串提示也不知道该听谁的。而TortoiseGit会把冲突文件列出来，用右键就能选“保留本地版本”还是“采用远程版本”，操作路径清晰很多。第二个推荐理由是它支持跨平台协作时常见的文件操作习惯。你可以在Windows资源管理器里直接比较版本差异、看提交历史、打标签，甚至查看某个文件是谁在什么时候改的，这些操作在TortoiseGit的日志对话框里做得非常直观。对于记不住命令、不喜欢盯着黑窗口的人来说，这是效率最高的路径。不过也要客观说一句：如果你是长期靠SSH远程登录服务器操作代码的开发者，那命令行终归绕不开。TortoiseGit适合的是本机开发、Windows桌面环境为主的场景。它帮你把“本机管理代码”这件事彻底图形化，但服务器上的Git操作还是得靠命令。这两者不冲突，反而互补。2. 装完之后别急着用，先调这三个配置很多人装完TortoiseGit就直接clone仓库，结果一提交发现中文乱码，或者push一直报认证失败，又或者文件图标怎么都不显示。这些问题大多不是TortoiseGit坏了，而是装完没做基础配置。下面这三个配置，我建议每个新装完的人先过一遍。2.1 用户名和邮箱：不设的话提交记录会变成“未知用户”TortoiseGit虽然支持在每次提交时弹窗让你填作者信息，但更稳妥的做法是在全局配置里固定好。打开任意文件夹，右键 -> TortoiseGit -> Settings -> Git，右侧有“用户名”和“邮箱地址”两个输入框，填成你自己的信息。注意这里填的用户名不是Github登录账号，是你在Git提交记录里展示的名字，邮箱也不要求必须和Github注册邮箱一致，但建议保持一致，这样Github能把你本地的提交和账号关联起来，头像和贡献图才正常。设置会自动写到全局.gitconfig里，以后所有仓库共用这套身份。如果某台机器上同时有工作账号和个人账号，那不要在全局这里填，应该在每个仓库的右键Settings里单独设置。2.2 中文乱码：输出编码和提交信息编码要被强制写成UTF-8Windows环境下中文乱码是出场率最高的坑。表现有两种：一种是TortoiseGit的日志信息里中文显示成乱码，另一种是命令行版Git中文路径显示成八进制转义符。不管哪种，根源都是编码不一致。默认情况下Windows使用GBK编码，而Git内部统一用UTF-8，不统一当然乱码。要解决，先打开Settings -> Git，找到“编辑全局.gitconfig”，在文本末尾追加以下行：[gui] encoding = utf-8 [i18n] commitencoding = utf-8 [core] quotepath = falsegui.encoding = utf-8告诉TortoiseGit用UTF-8解析界面和日志；commitencoding = utf-8保证提交信息按UTF-8保存；quotepath = false让中文路径不要被转义成八进制。改完保存，重启TortoiseGit，再打开日志对话框，中文基本就正常了。2.3 SSH客户端：选OpenSSH还是PuTTY要看你的密钥类型TortoiseGit在安装过程中会让你选SSH客户端，这个选择很多人都是随手点的，但它直接决定你之后连接Github用哪种密钥。两个选项分别是OpenSSH（Windows自带的ssh.exe或Git自带的）和TortoiseGitPlink（PuTTY的链路）。如果你选OpenSSH，那密钥文件是标准的OpenSSH格式，也就是用ssh-keygen生成的那对id_ed25519和id_ed25519.pub，和命令行Git共用一套；如果你选PuTTY，那密钥得用PuTTYgen生成.ppk格式，两者格式不通用。我个人推荐装新版时直接在设置里选OpenSSH。理由很简单：省事。你可以用命令行Git默认的密钥直接连接，不需要额外转格式，也不需要开Pageant加载密钥。Github官方文档里给的做法也是OpenSSH格式。如果你已经装完了，可以在Settings -> Network -> SSH Client里改。但要注意，改完之后测试连接方式也会跟着变，如果之前用PuTTY连接成功过，切换后需要重新生成或转换密钥。另外，如果文件图标不显示，去Settings -> Icon Overlays看看状态缓存设置。一般默认是“既调用状态缓存，也启用watch”，超过一定数量的文件时刷新会变慢甚至失灵。可以改成“仅调用状态缓存”，还能顺便解决和某些网盘软件抢占右键菜单导致的图标异常问题。3. 日常使用：克隆、提交、推送、拉取，围绕右键菜单捋一遍TortoiseGit的日常操作基本都集中在右键菜单里，但菜单选项多，新手容易分不清该点哪个。这一节按一条完整的开发链路往下走：从远程拿到代码、改代码、提交、推回去、再拉更新，每一步对应哪个入口、该注意什么。3.1 克隆远程仓库：URL决定了你走HTTPS还是SSH在本地新建目录，或者进入某个空目录，右键 -> Git Clone，把Github仓库的URL填进去。URL有两种格式：HTTPS的https://github.com/用户名/仓库名.git，SSH的git@github.com:用户名/仓库名.git。选哪种取决于你后续打算怎么认证。用HTTPS的话，首次push会弹窗要求验证身份，密码框填Personal Access Token而不是账号密码；用SSH的话，客户端会用密钥自动认证，不需要每次输token。关于认证后面专门讲，这里先记住一点：URL里不要带用户名和token。Clone的时候有个细节，对话框里有一项“Branch”，默认是空，表示克隆远端默认分支的所有历史。如果想节省时间只拉某个分支，可以填分支名，但新手不建议动，保持默认即可。另外TortoiseGit的Clone对话框支持勾选“递归克隆子模块”，如果项目里用了submodule，这个勾一定要打上，否则子模块内容拉不全。3.2 提交：先看差异，再选文件，最后写信息改完代码后，文件列表里会出现红色感叹号或蓝色问号图标。这时候右键文件 -> TortoiseGit -> Commit，会打开提交对话框。界面分两部分，上面是待提交文件的勾选框列表，下面是提交信息输入框。这里最容易被忽略的是“查看差异”按钮——提交之前一定养成习惯，双击每个文件，对比一下改动内容，确认没有误改、没有把调试代码带进去，再提交。提交信息建议写得有内容一点，比如“修复登录接口空指针问题”，不要写“更新”、“修改”这种一句废话。写清楚提交目的，一个月后翻日志还能想起来当时在干什么，这对个人项目尤其重要。提交时还有一个选项叫“包含工作目录中的新文件/修改文件”，默认勾选。如果你只想提交某几个文件，去掉自动勾选，只勾需要的文件就行。这个功能对“拆提交”很实用，比如一次改了三个功能点，就可以分三次提交，每次只勾对应文件，历史记录干净。3.3 推送：本地提交记录到远程仓库的过程Commit只是把改动记录在你本机仓库里，别人看不到，Github上也看不到。要让改动到远程，还得右键 -> Push。推送对话框里“Remote”选origin，“Branch”默认是本地当前分支。一般情况下直接点OK就好。这里要理解push和pull的区别。push是“把本地新提交推送到远程”，pull是“把远程新提交拉回本地”。两者方向相反，操作触发点不同：你改完代码要分享出去，是push；别人改完了你要拿最新的，是pull。还有一个fetch，它和pull很像但更温柔——fetch只把远程更新拉到本机的origin/xxx分支上，不帮你合并到工作区，pull则是fetch加merge一步到位。日常协作中，如果怕自动合并出意外，可以先fetch再右键查看分支比较，手动确认后再merge。3.4 拉取更新与解决冲突从远程拉代码，右键 -> Pull，对话框里会问合并策略。新手建议保持“Merge”不变，别碰“Rebase”。Merge会生成一个合并提交，历史里能看到“什么时候把远程分支并进来”，对个人项目完全够用；Rebase会把本地提交“搬”到远程提交之后，历史更线性，但改写历史有风险，不适合没经验的人玩。拉取最大的麻烦是冲突。判断标准很简单：Pull之后，如果某个文件同时显示红色感叹号和黄色感叹号的组合图标，说明这个文件冲突了。右键 -> Edit Conflicts，TortoiseGit会打开冲突编辑窗口，左边是本地版本，右边是远程版本，下面是你正在处理的合并结果。每一处冲突都要决定“保留本地”、“保留远程”还是“两边都保留”，手工处理后保存，再右键文件标记为“已解决”。这个过程第一次遇到会觉得紧张，其实只要记住：冲突的每一处都是二选一或二合一的取舍，选完保存、标记已解决、提交，就好了。4. 本地版本库上传Github的完整流程：四步把一个现有文件夹变成远程仓库这是很多人最关心的部分：我在本地有个项目文件夹，用TortoiseGit管理了一段时间，现在想整体推到Github上建个远程仓库。整个流程其实就四步，但它包含了几个最容易踩的坑，尤其是“远程仓库里已有文件”和“首次推送需要设置上游分支”这两个。4.1 第一步：在Github上创建空仓库，千万别勾初始化文件登录Github，点右上角加号 -> New repository，填好仓库名和可见性。有一个满屏都该注意的选项：是否勾选“Add a README file”和“.gitignore template”。对于已经存在本机仓库的情况，这两个选项一律不要勾，保持新仓库完全空白。原因很简单：如果你的Github仓库里有了README或者LICENSE，而本地仓库还没有这个文件，那么第一次push的时候Git会拒绝合并无关历史，因为两边在各自的起点上产生了不同提交记录。一旦发生这种拒绝，新手很容易陷入“强行推送覆盖远程”的冲动，那样会丢掉远程仓库里的初始化文件，或者引发更混乱的历史。正确做法就是让远程仓库保持空的状态，等本地第一版推上去再说。4.2 第二步：在本地文件夹里创建版本库如果你还没有在本地文件夹里初始化过Git仓库，右键文件夹 -> TortoiseGit -> 在此创建版本库。弹窗里会问“创建一个裸仓库吗”，选“不创建裸仓库”，这是标准的工作仓库模式。创建完成后，文件夹里会多一个隐藏的.git目录，这就是整个版本库的核心。如果之前已经用命令行Git创建过版本库，那这步跳过。不过还是建议确认一件事：右键 -> TortoiseGit -> Show Log，可以看到当前分支名。现在Github的新仓库默认分支叫main，而旧习惯是master。本地的分支名不一定要和远程一致，推送时可以指定把本地master推送到远程main，但我建议干脆统一。如果本地还没提交任何东西，最简单的方式是右键 -> Switch/Checkout -> 在“创建新分支”里输入main，确定后本地默认分支就改成main了，之后的提交都落在main上。4.3 第三步：配置Remote，把本地仓库和Github仓库关联起来本地仓库现在还不知道要去哪里，需要手动告诉它远程地址。右键 -> TortoiseGit -> Settings -> Git -> Remote，点击“Add”，Remote名称填origin（这是约定俗成的默认名，之后所有推送拉取都靠它），URL填Github仓库地址，类型按你的认证方式选HTTPS或SSH。填完点“Add/保存”，origin就出现在远程列表里了。这一步做完后，可以回到主界面右键 -> Fetch，看能不能从origin取到信息。因为远程是空仓库，fetch不会拉下任何东西，但只要没有报错，就说明网络和远程地址都没问题。4.4 第四步：首次推送，顺便设置上游分支右键 -> Push，Remote会默认选中origin。此时如果你本地在main分支上，Push对话框里会显示“Branch：main”，点确定开始推送。首次推送时TortoiseGit会弹出认证窗口，按前面讲的HTTPS填token或SSH密钥自动认证。推送完成后，对话框里会提示你是否设置了上游跟踪分支，建议勾选“设置上游”。这个“上游”的作用是让本地main分支记住自己对应的远程分支是origin/main，以后pull和push就不用每次指定分支了，直接右键点Pull/Push就没问题。如果没有在弹出的对话框里完成，也可以右键 -> Branch -> 选中main -> 勾选“更新上游跟踪分支”来补救。如果你在第一步看错了，远程仓库创建时勾了README，那么push多半会被拒绝，提示类似“fetch first”或“non-fast-forward”。这种情况下我最推荐的处理方式：不要强推，先Pull一次，把远程的README合并到本地，合并信息自动生成，然后再Push。两种历史被一个合并提交接起来，干净且没有丢内容。5. 认证问题：为什么输入账号密码一直失败这个问题被问得最多，而且几乎每个第一次用HTTPS方式连接Github的人都会栽一遍。你兴冲冲地Push，弹窗让你输用户名密码，你把Github的账号和邮箱密码填进去，结果每次都报认证失败。这不是你密码错了，而是Github从2021年8月起彻底停用了账号密码形式的Git操作认证，现在必须用Personal Access Token（个人访问令牌）当密码用，或者直接用SSH密钥认证。5.1 用HTTPS连接：生成一个当密码用的Token打开Github网页，头像 -> Settings -> Developer settings -> Personal access tokens -> Tokens (classic)，点Generate new token (classic)。Note填个能记住用途的名字，比如“tortoisegit-push”，Expiration看自己需要，个人项目选90天或No expiration都行，然后勾选repo这一个范围。生成后页面上会显示一串以ghp_开头的字符串，这个字符串只会完整显示这一次，一定要当场复制保存。然后回到TortoiseGit，在首次push弹出的认证窗口里，用户名栏输入你的Github用户名（不是邮箱也行），密码栏粘贴那串ghp_开头的token。由于TortoiseGit底层走的是Windows凭据管理器，认证成功之后token会被保存下来，后续再push通常不会再弹窗。如果以后token过期了，重新生成一个，然后在Windows的凭据管理器里找到对应条目删掉，下次push会重新弹窗让你填新token。有个细节提一下：千万不要把token以https://用户名:token@github.com/...的形式写进Remote URL里。那样token会明文存在.git/config文件里，一旦这个文件被提交或者被截图，等于账号直接泄露。正确的做法就是让凭据管理器代管，别手动拼URL。5.2 用SSH连接：生成密钥，配置到Github嫌token麻烦，或者不想每次到期都重新生成的话，用SSH更舒服。前提是TortoiseGit的SSH客户端设置成了OpenSSH（前面第2.3节提过）。打开Git Bash或CMD，执行：ssh-keygen -t ed25519 -C "你的邮箱@example.com"一路回车，会在用户目录的.ssh文件夹下生成id_ed25519和id_ed25519.pub两个文件。前者是私钥，绝对不要发给任何人；后者是公钥，可以公开。用文本编辑器打开id_ed25519.pub，复制全部内容，到Github网页 -> Settings -> SSH and GPG keys -> New SSH key，Title随便填，Key粘贴进去，保存。然后验证连接是否成功：ssh -T git@github.com如果看到类似“Hi 用户名! You've successfully authenticated”的提示，说明密钥配置好了。之后TortoiseGit的Remote URL改成git@github.com:用户名/仓库名.git，push时客户端会直接用私钥完成认证，不再弹窗输入任何密码。这个体验比token顺畅不少，比较推荐一劳永逸的方式。6. 用TortoiseGit久了容易犯的错：我踩过的几个坑工具用熟了之后，真正影响效率的不是不会操作，而是那些隐藏很深、平时不起眼的小问题。这几个坑我都实际踩过，写出来算是帮后来人省点时间。6.1 换行符CRLF导致整个文件都被标记为修改Windows系统里的文本文件换行符默认是CRLF，而Linux/Mac上用LF。Git为了跨平台协作，提供一个自动转换功能。如果某个项目里混合了不同换行符，你明明只改了一行，打开Diff一看整个文件几千行全是改动，非常劝退。这个问题根源通常是autocrlf配置不对。TortoiseGit默认安装会在全局配置里启用core.autocrlf=true，对纯Windows项目问题不大，但如果你在Windows上开发部署到Linux的项目，这个设置反而容易制造假改动。一个实用策略是：看项目里有没有.gitattributes文件，这个文件能逐路径规定换行符规则，比全局autocrlf靠谱得多。如果没有，个人项目建议在仓库根目录建一个，写入：* text=auto *.sh text eol=lf *.bat text eol=crlf这样明确约定各类文件的换行方式。注意改完.gitattributes之后记得重新commit一次，让Git按新规则规范化文件，否则之前的文件还是旧规则下的状态。6.2 “本地有改动”和“本地需要提交”是两回事TortoiseGit文件夹图标最让人踏实的一点是能随时看到仓库状态，但也容易造成一种错觉：图标变成红色感叹号就觉得工作区有问题。其实红色感叹号只说明文件内容和最近一次提交不一致，这种不一致是正常开发状态。真正要关注的是Commit对话框里“未提交的更改”和“已暂存的更改”两部分。你改了文件但不commit，改动只存在于工作区；一旦commit，这次改动就变成一个历史节点，可以随时回退。搞清楚这个边界，就不会出现“明明改了代码，push后远程却没有”的困惑了。6.3 误点Revert，把没提交的改动全丢掉了Revert这个功能，从名字上看像是“撤销提交”，但在TortoiseGit的右键菜单里，它默认对选中的文件执行“回滚到最近一次提交状态”。也就是说，你在文件上点了Revert，所有未提交的修改会直接丢失，且不会进回收站。这个功能很危险，尤其新手容易把它当成“撤销上一步操作”。如果你只是想撤销某一次提交，应该去Show Log里选择那次提交，然后右键选“Revert change by this commit”，那是生成一个反向提交来抵消旧的改动，不会碰你的工作区内容。区分这两个入口，能避免一次痛彻心扉的数据丢失。6.4 Windows路径过长或中文目录导致的操作失败Windows的路径最大长度默认260字符，如果项目目录层级很深、文件名又长，Git操作经常会报错。一个推荐做法是在Git for Windows安装时勾选“启用长路径支持”，或者通过组策略修改系统长路径限制。中文目录名本身不一定有问题，但某些老项目和工具链确实对非ASCII路径支持不好，建议新项目目录统一用英文字母命名。另外，仓库路径里尽量不要有空格和特殊符号，TortoiseGit对这类路径偶尔会报“fatal: Unable to create ...”，排查起来很闹心。6.5 忘了提前写.gitignore，把依赖目录一起提交了个人项目最常见的尴尬就是第一次提交时不小心把node_modules、target、build、.idea、__pycache__这类目录一起提交进去了。这些文件又大又没意义，还导致仓库体积暴涨。解决方法是仓库创建之初就准备.gitignore。TortoiseGit在右键创建版本库时并不会自动生成这个文件，你可以到Github新建仓库页面复制官方维护的模板，或者用现成的主流项目模板。如果已经误提交进去了，别指望直接删文件就能把它从Git历史里抹掉，那些目录还是躺在历史记录里。正确的清理方式是用git filter-branch或git-filter-repo改写历史，但这是相对操作，新手不建议单独研究，更建议吃一堑长一智，新项目从一开始就配好.gitignore。6.6 强推（Force Push）不到万不得已别用Push对话框里有一个“Force”选项，字面意思是强制把本地历史覆盖到远程。听起来很霸气，但它的实际效果是：远程仓库那些本地没有的提交会被直接丢弃。在多人协作的仓库里，一次强推等于抹掉别人的提交记录，属于事故级操作。即使是个人仓库，也只在远程历史已经乱到无法收拾时才考虑。如果你的push被拒绝，先按第4.4节的流程Pull合并，实在不行再考虑强推，而且强推前一定要确认远程上的提交没有独有内容。写了这么多，其实最想传达的还是那个感受：工具不在多，顺手就行。TortoiseGit这种图形化外壳，表面上只是把命令换成了按钮，但它真正降低的是“确认当前状态”的成本——文件有没有改、改了什么、提交后在什么位置，全部可视化呈现出来。配合第4节那套“空远程仓库起步、首推带上游”的流程，再把认证方案一次配好，后面的日常操作基本就是右键点几下的肌肉记忆。至于那些坑，遇到一次记下处理方式，下次就免疫了。