TortoiseGit 推送 Gitee 代码：从 SSH 配置到报错排查全流程

用 TortoiseGit 往 Gitee 上传代码这件事，网上教程不少，但多数都只写到“点这个、点那个”的层面，一旦中间冒出个报错，就不知道该往哪查。我见过太多人卡在同一个地方：装好了 TortoiseGit，也照着教程建了 Gitee 仓库，结果右键推送时弹出一行红字“git did not exit cleanly”，然后就没了下文。这篇文章我不打算只给你一份按钮点击清单，而是把从安装到日常推送全链路的关键点都讲清楚，包括环境配置、SSH 免密、首次推送的完整流程、高频报错的排查思路，以及拉取、分支、多远端这些日常操作。适合刚接触 Gitee 和 TortoiseGit 的 Windows 用户，也适合已经用了几天但总被各种报错卡住的人当作排查手册。

1. 为什么放弃命令行，选择小乌龟

TortoiseGit 在 Windows 下的存在感很强，注册右键菜单、集成文件资源管理器、文件图标自带状态标记——被广大用户直接喊成“小乌龟”。它本质上不是一个独立的 Git 实现，而是一个 Git 的图形化壳程序：你在界面上做的每一个操作，底层都是在调 Git 命令。这也是理解后面所有问题的关键：界面只是包装，运行时报的任何错误，本质上都是 Git 报的错。

有人会问：现在 IDEs 都内置 Git 面板了，GitHub Desktop、SourceTree 也做得不错，为什么还要单独用 TortoiseGit？我的实际体验是，它有几个很难替代的场景：一是不依赖 IDE，无论你用的是 VS Code、Visual Studio、PyCharm 还是根本不写代码的文档目录，只要在资源管理器里右键就能操作；二是它对 Git 概念的呈现非常透明，暂存、提交、推送、拉取、分支切换全部可以在右键菜单里完成，适合需要“看到 Git 在干嘛”的人；三是它和 Windows 的集成程度高，文件图标、右键菜单、日志图，比很多跨平台工具更符合 Windows 用户的操作直觉。

但这里要先把丑话说在前面：图形界面能降低操作门槛，却不能替代你对 Git 概念的理解。工作区、暂存区、本地仓库、远程仓库这几个概念，哪怕只是大概明白，很多操作就不会再“对着教程一步步点，点完不知道发生了什么”了。TortoiseGit 的提交（Commit）和推送（Push）是两件事，拉取（Pull）和获取（Fetch）也是两回事，这些不是界面能替你消化的。所以我后面讲每一步时，会顺带把概念也解释清楚。

如果你刚开始接触 Gitee，大概率同时看到过 GitHub、GitLab 这些名字。简单说，GitLab 有开源社区版可以自己部署，GitHub 和 Gitee 都是商业平台、提供免费账号；Gitee 在国内访问速度通常比 GitHub 稳定，所以很多人把它作为主力仓库或镜像仓库。操作流程三者也基本一致，这篇文章以 Gitee 为例讲，学会了以后换平台也只是换地址的问题。

2. 装好一个能用的 TortoiseGit：这些配置项别跳过

2.1 先装 Git for Windows，再加图形壳

TortoiseGit 安装之前，必须先装 Git for Windows。这不是可选项，因为 TortoiseGit 自己不包含真正的 Git 核心，它所有的提交、推送操作都要调用系统里的 Git.exe。你可以把关系理解为：TortoiseGit 是方向盘和仪表盘，Git for Windows 才是发动机。

Git for Windows 的安装没有太多坑，一路 Next 就行。唯一要留神的是安装路径和默认编辑器。路径不要放在带中文的目录下，否则某些场景下可能因为中文路径解析出问题；默认编辑器无论选 Vim 还是 Notepad++ 都行，反正 TortoiseGit 里写提交信息用的是自己的窗口，基本用不到系统编辑器。

装完后，建议在任意目录右键，确认菜单里有“Git Bash Here”。这个是后续生成 SSH 密钥、手动查看报错时最常用的入口。

2.2 TortoiseGit 安装：语言包和 SSH 客户端二选一

TortoiseGit 本身是开源软件，去官网下载安装包。安装过程中有些选项可能会让你懵，但有一个选项特别关键：SSH client 的类型。

安装流程会让你在 TortoiseGitPlink 和 OpenSSH 之间选一个。这里的默认值通常是 TortoiseGitPlink，很多教程也直接默认下一步。但我的建议是选 OpenSSH。原因有三：一是 Gitee、GitHub 官方文档里演示的密钥生成命令基本都是针对 OpenSSH 的；二是你用 Git Bash 生成的密钥可以同时被命令行和 TortoiseGit 使用，不用额外装 PuTTY 生态；三是以后排查 SSH 问题，用 ssh -T git@gitee.com 这种命令直接测试，链路最短。如果选了 TortoiseGitPlink，也可以用 PuTTYgen 生成密钥、用 Pageant 管理，但这套流程和外面绝大多数教程对不上，容易把人绕晕。

语言方面，TortoiseGit 官方有简体中文语言包，安装时在安装器里选 Language 为中文即可，也可以之后单独下载 LanguagePack 安装。语言包不影响任何功能，只是界面文字翻译。

安装完成后，右键菜单会出现 TortoiseGit 相关的选项，文件图标也会在克隆了仓库的目录里显示 Git 状态标记。如果没看到，重启一次资源管理器通常就好了。

2.3 装完立刻改的三个设置

很多人装完 TortoiseGit 就直接克隆仓库，结果第一次提交时才发现作者名不对、中文文件名乱码、换行符出问题。这些其实都可以在设置里提前解决。

在任意目录右键，选 TortoiseGit -> Settings，打开设置面板。第一件事是设置全局身份：

• 路径：Git -> 全局设置
• 填写 姓名（name）和 电子邮件（email）
• 填好后点“应用”

这里填的 name 和 email 会写进全局 .gitconfig，之后每一次提交都会带上这个身份信息。email 一定要用你 Gitee 账号绑定的邮箱，否则提交记录在 Gitee 上不会被正确关联到你的账号，显示成一个独立用户。这是个很常见的问题，很多人提交完去 Gitee 网页上一看，头像是个奇怪的默认图标，十有八九就是邮箱没对上。

第二件事：在同一个设置面板里，找到 Git -> 编辑全局 .gitconfig（或直接手动编辑 C:\Users\你的用户名.gitconfig），在配置里加一行：

ini复制[core]
    quotepath = false

这个配置解决的是中文文件名乱码。Git 默认会把非 ASCII 文件名转成转义序列，不带这个配置的话，你在日志里看到的中文文件名会变成一串八进制转义字符，虽然不影响操作，但看着非常难受。

第三件事是换行符。Windows 文件默认行尾是 CRLF，Linux/macOS 是 LF，跨平台协作时如果不做转换，Git 会认为整个文件都被修改了。个人使用建议在全局 .gitconfig 里设置：

ini复制[core]
    autocrlf = true

这个配置的含义是提交时自动把 CRLF 转成 LF，检出时自动把 LF 转成 CRLF，对 Windows 单平台使用者最省心。如果你的团队里有 Linux/macOS 同事，往往统一设置更复杂一些，但在个人项目和绝大多数小团队场景下，autocrlf = true 是够用的。

如果你日常会用到 diff 和 merge 工具，还可以在 Settings 里配置外部比较工具，比如 Beyond Compare、Araxis Merge。这个不是必须，但配置之后解决冲突时体验会好很多，后面讲冲突时我会再提。

3. SSH 免密通道，第一次推送前先把钥匙配好

3.1 为什么推荐用 SSH 而不是 HTTPS

Gitee 支持两种拉取/推送协议：HTTPS 和 SSH。用 HTTPS 地址克隆和推送，每次操作都会要求输入 Gitee 的账号密码；虽然 Windows 的凭据管理器有时候能记住，但你永远不确定它什么时候失效、什么时候在另一台机器上又弹出来要账号。SSH 则是基于密钥对认证：你生成一对公钥和私钥，把公钥放到 Gitee 账号里，之后所有 Git 操作都通过密钥校验身份，不需要再输入账号密码。一次配置，长期免密，这几乎是所有推送场景里最省事的方案。

3.2 生成密钥对：选 ed25519 还是 RSA

如果你按我前面的建议，在安装 TortoiseGit 时选了 OpenSSH，那么生成密钥直接用 Git Bash 就行。

在任意目录右键，打开 Git Bash Here，执行：

bash复制ssh-keygen -t ed25519 -C "你的Gitee邮箱"

如果你所在的环境比较老，担心兼容性，也可以换成 RSA：

bash复制ssh-keygen -t rsa -b 4096 -C "你的Gitee邮箱"

执行后一路回车即可，默认会把密钥生成到 C:\Users\你的用户名\.ssh\ 目录下，私钥文件叫 id_ed25519（或 id_rsa），公钥文件叫 id_ed25519.pub（或 id_rsa.pub）。中间如果有提示设置 passphrase，建议留空，否则以后每次用私钥还要输入一遍口令，反而违背了免密的初衷。

查看公钥内容：

bash复制cat ~/.ssh/id_ed25519.pub

复制整行输出，这就是你要交给 Gitee 的公钥。

3.3 把公钥添加到 Gitee，并测试连接

登录 Gitee 网页端，右上角头像 -> 设置 -> 安全设置 -> SSH 公钥。把刚才复制的公钥粘贴进去，标题可以随便填，比如“我的Windows电脑”，然后确认。

添加完之后，建议先做一次连通性测试。在 Git Bash 里执行：

bash复制ssh -T git@gitee.com

第一次连接会提示确认 host key，输入 yes 回车。如果配置成功，会看到类似“Hi xxx! You've successfully authenticated, but Gitee does not provide shell access.”这样的返回信息。出现这句话，就说明 SSH 通道已经打通了。

我见过不少人在这一步没做测试就直接去克隆仓库，结果克隆时报 Permission denied (publickey)，然后开始怀疑仓库地址是不是写错了。其实问题九成出在公钥没配好。先测试再往下走，能省掉大量盲目排查的时间。

4. 从空仓库到第一条提交：首次推送走一遍

4.1 Gitee 新建仓库时的三个选择

在 Gitee 网页右上角点“新建仓库”，会看到仓库名、路径、开源/私有等选项。几个关键选项我展开说一下，因为它们直接影响你本地的第一步操作。

仓库名建议和本地项目文件夹同名，方便对应。是否私有，取决于项目性质，这个随时能改。下面三个选项容易被忽略：

• 是否使用 Readme 文件初始化这个仓库：如果勾选了，Gitee 会在云端自动生成一个带 README.md 的初始提交，也就是远程仓库里已经有一条历史了。如果你本地目录恰好也是一个已经被 Git 初始化的仓库，两个仓库的历史是互不相干的，直接推送会被 Git 拒绝。这一点是新手最常见的坑，后面我会专门讲怎么补救。
• 选择 .gitignore 模板：可以选对应语言的模板，让云端自动生成一份 .gitignore。不过我个人建议在本地项目里自己维护 .gitignore，因为云端模板有时候不全。
• 选择开源许可证：公开项目建议选，比如 MIT、Apache-2.0；私有项目无所谓的，不选也行。许可证就是告诉别人你能不能用、怎么用你的代码，拖到后面选也来得及。

如果这是你的第一个仓库，最简单省事的做法是：先不勾选“初始化仓库”相关选项，保持空仓库状态，等本地代码推上去之后，再在网页端手动添加 README 或 .gitignore。这样避免了两套历史打架的问题。

4.2 在本地项目里完成第一次提交

打开你的本地项目文件夹，先看你有没有 .gitignore 文件。没有的话，右键新建一个，至少写上常见的忽略目标：

gitignore复制node_modules/
dist/
build/
target/
.idea/
.vscode/
*.log
.DS_Store

为什么强调先写 .gitignore？因为很多新手第一次提交时，把一个几十 MB 的 node_modules 或 target 目录直接推上去了，之后的每一次拉取都变慢，仓库体积也直线飙升。Git 擅长管理代码文本，不擅长当网盘用。

写好后，在项目文件夹里右键，选 TortoiseGit -> 添加。这个操作会把当前目录下所有未跟踪的文件加入暂存区。如果你希望提交时再选，也可以跳过添加，直接在提交窗口里手动勾选文件——TortoiseGit 的提交界面会把“未纳入版本控制”的文件单独列出来，默认不勾选，你按需勾选即可。

然后右键，选“Git 提交(C)”（注意是 Commit，不是 Push）。提交窗口里你能看到：

• Message 输入框：写提交信息。我个人的习惯是写清楚“这次改了什么”，而不是写“修改代码”这种没信息量的话。第一次提交可以写“init project”或“first commit”。
• “Changes made”列表：列出已暂存的变更、未暂存的变更、未纳入版本控制的文件。
• Author 区域：会显示你在 2.3 节设置的名字和邮箱，如果这里不是你预期的那份身份，说明全局设置没生效，先回去改。

点提交按钮后，这次“快照”就记到本地仓库了。注意，这时候 Gitee 线上仓库里还什么都没有，提交只是完成了本地记录。很多人第一次提交完，看到窗口一闪而过就以为上传成功了，跑去 Gitee 网页上一看，仓库是空的，然后懵了。不要急，下一步才上传。

4.3 第一次推送：填远程地址和分支

提交完成后，项目文件夹右键，选“推送(Push)”。弹出推送窗口，界面大概是这样的：

• 远端（Remote）：下拉框选 origin。第一次推送时你可能没有这个名字，可以选“远端: 无”或直接输入 URL。
• URL：填入你在 Gitee 仓库页面复制的地址。建议复制 SSH 格式的地址，也就是 git@gitee.com:你的用户名/仓库名.git 这种。注意不要用 HTTPS 地址，用了的话你还是会被要求输入账号密码。
• 远端分支：远程仓库要接收的分支名。本地分支默认通常是 master 或 main，取决于你在哪一步初始化的 Git 仓库。Gitee 新建空仓库时，网页上会显示它期待的默认分支名，常见是 master；以页面显示的为准就好。
• 本地分支：显示你当前所在的分支，确认即可。

点“确定”，如果一切正常，你会看到推送进度窗口，最终显示一条类似“master -> master”的更新记录，并提示成功。这时候再去 Gitee 网页上刷新，代码就已经躺在仓库里了。

4.4 远程仓库已经初始化过 README 的补救流程

如果你在 4.1 中勾选了“用 Readme 初始化仓库”，而且本地项目也已经有了一次提交，推送时大概率会报错，错误信息里包含 failed to push some refs 和 non-fast-forward 这样的关键词。这是因为远程仓库有一个本地完全没有的历史（README 初始提交），Git 认为直接推送会导致远程历史被覆盖，所以拒绝执行。

补救方法很简单：先把远程仓库拉下来，和本地历史合并，再推送。在项目文件夹里右键，选 TortoiseGit -> 拉取(Pull)，拉取窗口里选择来源为 origin，分支选远程的 master（或 main），合并策略建议第一次直接选默认的 merge 而不是 rebase，逻辑上更直观。点确定后，远程的 README 提交会和本地提交合并成一条分叉再合并的历史。如果两边没有同名文件冲突，这个操作会顺利结束；如果 README 文件和本地某个文件同名，TortoiseGit 会提示冲突，需要按第 6 章讲的方法解决冲突。

合并完成后，再执行一次推送，就能成功了。整个过程不需要删除远程仓库重建，那样虽然简单，但不优雅，而且容易误伤已经提交的 issue 关联。

5. 高频翻车现场：这些报错和坑基本每个人都会遇到

5.1 “git did not exit cleanly”到底怎么排查

这是 TortoiseGit 用户最常见的报错，字体红红的，看起来非常严重，实际意思是：TortoiseGit 调用的 Git 命令没有正常退出，退出码非 0，但 TortoiseGit 自己只给你显示了这句话，没把真正的错误原因给你。所以你的首要任务是让真正的错误信息露出来。

第一步，打开 TortoiseGit Settings -> General，勾选“Show command line output”（显示命令行的输出）。这样出错时，窗口里会带上 Git 命令原本的报错内容，不再只有一句笼统的提示。

第二步，如果窗口里的信息还是不够直观，直接在项目目录里打开 Git Bash Here，手动执行：

bash复制git push -v

或者：

bash复制git pull -v

你就能看到 Git 到底在哪个环节失败。这比自己猜答案高效得多。

我把这些年见过的高频错误原因汇总成一张表，方便你对号入座：

5.2 提交作者显示不对，怎么一次性改干净

这个问题我在 2.3 节提过：提交记录里的作者名和邮箱跟你预想的不一样。原因基本只有一种——本机 Git 的 user.name 和 user.email 没配好，可能用了系统默认值，也可能填了一个从来没用过的邮箱。

先查当前配置，在 Git Bash 里执行：

bash复制git config --global user.name
git config --global user.email

如果输出为空，就重新设置：

bash复制git config --global user.name "你的名字"
git config --global user.email "你的Gitee邮箱"

如果你是想改已经提交到仓库里的历史记录，情况会复杂一些。如果那些提交还没推送，可以在 Git Bash 里用 rebase 交互模式重新指定作者，常见做法是：

bash复制git rebase -i HEAD~n

然后把对应提交的动词从 pick 改成 edit，逐个执行：

bash复制git commit --amend --author="你的名字 <你的邮箱>" --no-edit
git rebase --continue

如果提交已经推送到了 Gitee，就要非常谨慎了。改历史等于重写历史，会让其他协作者的本地仓库变得不一致。这种情况下我一般不建议新手自己动手，最稳妥的办法是以后的提交保证正确，历史记录保持原样，或者集体约定好在一个合适的时间窗口内统一修正。

5.3 中文文件名乱码和 CRLF 换行符问题

“git did not exit cleanly”之外，我遇到最多的两个“不报错但难受”的问题，一个是中文文件名乱码，一个是整个文件被标记为改动。

中文文件名乱码在 TortoiseGit 的日志视图里尤其明显，明明文件名是“用户需求.md”，显示出来却是 "\346\265\213\350\257\225.md" 这种转义序列。原因和解决我在 2.3 已经写了，就是在全局 .gitconfig 里加：

ini复制[core]
    quotepath = false

加完之后，新日志会正常显示中文，历史日志也立即生效，不用重装。

CRLF 换行符问题则更隐蔽。假设你在 Windows 上写了一个文件，行尾是 CRLF，同事在 Linux 上拉下来改了两行，再推回去，Git 有时候会把这个文件判为整个文件都改了，因为行尾全变了。这种情况通常就是有人没做 autocrlf 配置，或者团队里配置不一致。我建议 Windows 用户统一用：

ini复制[core]
    autocrlf = true

如果你的项目已经有大量文件是 LF 结尾，团队又跨平台，可以考虑换成：

ini复制[core]
    autocrlf = input

这表示提交时转成 LF，检出时不强制转换。两种方案没有绝对对错，关键整个团队统一。别小看这个配置，很多“我什么都没改，为什么 Git 显示我改了几百行”的诡异问题，最后都是换行符配置不一致引起的。

5.4 TortoiseGit 切换账号的正确姿势

有时候你本机配了 A 账号的 SSH 密钥，突然想用 B 账号推送代码。TortoiseGit 不像浏览器那样有个明显的“退出登录”按钮，切换账号主要看你是哪种协议。

如果你用的是 HTTPS 地址，账号密码通常被 Windows 凭据管理器记住了。切换账号的方法是：打开控制面板 -> 用户账户 -> 凭据管理器 -> Windows 凭据，在列表里找到 gitee.com 或 git 开头的条目，点开删除。下次推送时，TortoiseGit 会重新弹出窗口要你输入新的账号密码，然后重新保存。这是 HTTPS 方式最常见的坑：密码改了、账号换了一个，凭据管理器里还存着旧值，一直报 Authentication failed。

如果你用的是 SSH 地址，切换账号的逻辑是：Git 通过本机 ~/.ssh/ 目录下的私钥来认证，私钥对应哪个 Gitee 账号，推送时就被识别为哪个用户。所以想切换账号，要替换对应的私钥文件，或者用 SSH config 配置多个 Host。简单场景下，直接把 ~/.ssh 下的旧密钥改名备份，重新生成一份新密钥，并加到新账号的 SSH 公钥列表里，就可以完成切换。

另外补充一个细节：TortoiseGit -> Settings -> Saved Data 里可以清空 URL 历史、账号密码等缓存数据。如果遇到莫名其妙的登录态问题，去这里全选清理一次再操作，往往就正常了。

6. 把送代码变成日常：拉取、冲突、分支与多仓库管理

6.1 日常循环：拉取、修改、提交、推送

代码推到 Gitee 之后，日常工作流就变成了一个循环：拉取最新代码 -> 修改代码 -> 提交到本地 -> 推送到远程。用 TortoiseGit 操作非常直接。

拉取时，在项目文件夹右键，选 TortoiseGit -> 拉取(Pull)。这里要注意的是“拉取”实际上包含两步：从远程获取最新提交，再合并到当前分支。TortoiseGit 的拉取窗口里可以选合并方式：

• 不指定：Git 默认 merge，自动产生一个合并提交
• 设置 --rebase：把本地提交“垫”到远程提交之后，历史更线性，适合个人分支
• 设置 --ff-only：只有能快进合并时才合并，否则报错

我个人的习惯是个人分支上用 rebase，团队分支上老实 merge，减少历史分叉。但这不是绝对规则，你们团队如果没有历史整洁度要求，直接默认 merge 也完全没问题。

拉取完成后，正常写代码、改代码。文件图标上的状态会跟着变，绿色勾表示未修改，红色感叹号表示有修改，蓝色加号表示新增文件。提交和推送的流程和首次推送一致，只是推送时不需要再填 URL 了，因为你已经保存了 origin 远端。

这里有个经验性的建议：提交信息要“小步快跑”。一个功能拆成多个有意义的提交，每个提交只做一件事，比攒了一周最后来一个“update”要健康得多。推送也建议频繁些，Gitee 本身免费，没有理由把代码只放在本地。代码只有推到远程，才算是真正备份了一份。

6.2 冲突不可怕：TortoiseGit 解决冲突的完整路径

多人协作时，最让人紧张的就是“冲突”。实际上冲突只是 Git 告诉你“两边的修改有重叠，我不知道该听谁的”，这不是错误，更不是灾难。

通常在 Pull 或 Push 时会出现冲突提示。TortoiseGit 会把冲突文件标记为红色感叹号加一个“矛盾”图标。右键冲突文件，选“编辑冲突(Edit conflicts)”，它会打开一个三方合并视图：左边是本地版本，右边是远程版本，中间是合并结果。如果你是像我一样配置了 Beyond Compare，也可以选“使用外部合并工具”，体验会更好。

手动解决冲突的原则是：逐段确认每一处标记为冲突的内容，选择保留哪一边，或者手动改成一个两边都不完全相同的新版本。解决完之后，在文件上右键选“标记为已解决(Mark as resolved)”，然后像正常一样提交。提交信息里 TortoiseGit 会默认带上 “Merge” 相关字样，保持默认就行。

我见过太多人一看到冲突就慌了，第一反应是撤销所有修改重新拉取。其实完全没必要，只要你不是同时把同一行代码改成两种完全不同的逻辑，冲突大多在几分钟内就能搞定。

6.3 分支操作：从只会推 master 到会用分支

刚开始用 Git/Gitee 的人常常只有一个 master（或 main）分支，所有代码都直接往主干上推。等到项目稍微大一点，或者和两三个人协作时，直接推主干的坏处就显现出来了：某个功能还没做完，你不想推到主干影响别人，但你又想备份和同步代码，这时候分支就是解决方案。

TortoiseGit 的分支操作在右键菜单里很集中。“创建分支(Create Branch)”用来新建分支，需要填分支名和基于哪个提交创建。“切换/检出(Switch/Checkout)”用来在分支之间跳转。“合并(Merge)”把其他分支的提交并到当前分支。“删除分支(Delete Branch)”清理已合并完毕的分支。

分支命名的约定，业内有一套通用习惯，配合搜索引擎也能搜到，我实际项目里常用的几种：

这些不是强制规范，但能让分支名一眼看出目的。配合“特性分支”的思路：一个功能开一个分支，做完合并回主干，再删掉分支，主干永远保持可发布状态，协作体验会好很多。

6.4 一个项目同时挂 Gitee 和其他远端：远程管理实操

很多人喜欢把代码同时推到 Gitee 和 GitHub，一个当主力，一个当备份，这就是“多远端”需求。TortoiseGit 管理多远端很方便。

在项目文件夹右键，选 TortoiseGit -> 设置(Settings)，左侧选“Git -> 远端(Remote)”。你会看到已经存在的远端列表，比如 origin。点“添加(Add)”可以新增一个远端，填写名称和 URL。比如：

• origin 指向 Gitee：git@gitee.com:用户名/仓库.git
• github 指向 GitHub：git@github.com:用户名/仓库.git

命名是自定义的，好记就行。添加完保存后，你推送时在远端下拉框里就能选择推送到哪个远端，或者同时勾选多个远端一次推送。

还要分清楚推送和获取的区别。“获取(Fetch)”只是把远程最新提交拉取到本地的远程跟踪分支，比如 origin/master，它不会动你当前工作区。而“拉取(Pull)”是获取之后再做一次合并。多远端的场景下，偶尔跑一次 Fetch，看一眼各远端的差异，再决定怎么合并，会比直接 Pull 更可控。

如果你用前端框架，比如 React、Vue 项目，流程没有任何不同，唯一要注意的是项目里有个巨大的 node_modules 目录，务必确保 .gitignore 把 node_modules/ 忽略了。之前见过有人第一次推代码，把整个 node_modules 几万个文件全推上去，Gitee 仓库直接卡死，最后只能删库重建。这个教训很便宜，但很经典。

最后分享一个我个人的操作习惯：每次推送前，先在 TortoiseGit 日志图里看一下本地领先远程几个提交、本地和远程有没有分叉；确认没问题再推送。养成这个习惯之后，我几乎没有再遇到过推送被拒的情况。Git 和 Gitee 这套体系，恐怖就恐怖在第一次的未知，真跑通一次全流程之后，剩下的全是肌肉记忆。