企业官网建设流程全解析

简介：这份资源是面向 Windows 平台 Git 初学者的 TortoiseGit 图文使用教程，以 docx 文档形式系统梳理了从环境搭建到日常协作的完整流程，帮助不熟悉命令行的用户借助右键菜单快速上手版本控制。压缩包内共 1 个 docx 文件，约 1.15MB，内容涵盖 Git 与 TortoiseGit 及中文语言包的下载安装、General 与 Git 选项卡配置、用户名邮箱设置，以及通过 credential helper 保存凭证、生成并上传 SSH Key 等关键环节。教程还以克隆项目为例对比 HTTPS 与 SSH 两种连接方式，并讲解拉取、合并、提交、推送和分支管理等常用操作，同时说明文件状态角标的含义，便于读者对照排查问题。目前已有 2152 人学习，适合需要一份可随时查阅的入门操作手册的开发者收藏使用。

1. 从右键菜单到版本控制：TortoiseGit 到底解决了谁的痛点

Windows 上做开发的人大多有过这种体验：命令行里敲git status看半天，切个分支要翻笔记，合并冲突时对着<<<<<<<标记发呆。TortoiseGit 就是冲着这个场景来的——它把 Git 的常用操作全部塞进资源管理器的右键菜单，克隆、提交、拉取、推送、看日志、解冲突，全都能在图形界面里点出来。这份《TortoiseGit 使用教程》覆盖了从 Git 与 TortoiseGit 的下载安装、中文语言包配置、用户名邮箱设置，到 HTTPS 与 SSH 两种连接方式的取舍、SSH Key 的生成与上传、克隆/提交/拉取/推送的完整流程，以及文件角标状态的含义。适合刚接触 Git 的 Windows 开发者、从 SVN/TFS 迁移过来的团队，以及需要给非命令行同事一套可落地操作规范的技术负责人。下面按「装好 → 配通 → 跑起来 → 避坑」的顺序拆。

2. 装对顺序与配通全局：Git、TortoiseGit、语言包三件套

2.1 安装顺序为什么不能反

TortoiseGit 本身不带 Git 内核，它只是一层壳，所有实际操作最终都调用git.exe。所以安装顺序必须是先 Git for Windows，再 TortoiseGit，最后中文语言包。反过来装，TortoiseGit 安装向导里找不到 Git 路径，后面还得手动补，多一道工序。语言包放在最后是因为它要往 TortoiseGit 的安装目录里写翻译文件，主程序没装好它没地方落。

安装 Git 时有一个选项值得留意：向导里会让你选默认编辑器，默认是 Vim。对不熟悉 Vim 的人来说，提交信息写错想退出都费劲，常见做法是改成 Notepad 或者 VS Code。另外 PATH 环境变量那一步，选「Git from the command line and also from 3rd-party software」，这样右键菜单和命令行都能用。

TortoiseGit 安装过程中会弹出一个配置向导，问你 Git 的安装路径。如果你 Git 装在默认位置，它一般能自动识别；装在非默认盘符（比如D:\Program Files\Git\bin），这里就要手动指过去。这个路径后面在设置里还能改，但第一次装的时候填对能省事。

2.2 全局设置：语言、git.exe 路径、用户身份

装完之后第一件事是打开设置。选定一个专门存放 Git 项目的目录（教程里用的是E:\Git），在资源管理器空白处右键 → TortoiseGit → Settings。这个「先建目录再进设置」的动作不是多余的，后面所有项目都往这个目录下克隆，管理起来清爽。

设置界面里要动三处：

• General → Language：选「简体中文」。语言包没装的话这里只有英文选项，说明语言包那一步漏了。
• General → 升级检查：取消勾选。内网环境或者不想被弹窗打断的话，这个检查每次启动都可能冒出来。
• General → Git.exe Path：确认指向git.exe所在目录，比如D:\Program Files\Git\bin。指错了后面所有操作都会报「找不到 git」。

然后是用户身份。左边切到 Git 标签，右边填 Name 和 Email。这两个值会写进每一次提交记录，是你在版本历史里的标识。填错了不是不能改，但历史提交里的作者信息改起来很麻烦，所以第一次就填对。

这里有个容易混淆的点：设置界面里有两个编辑配置文件的按钮，「编辑全局 .git/config」和「编辑本地 .git/config」。全局配置对当前用户所有仓库生效，本地配置只对当前打开的这个仓库生效。教程里提到本地按钮在没有项目时是灰色的，就是这个原因——没有仓库就没有本地配置文件可编辑。新手经常在这两个之间点错，改了半天发现换个项目不生效，就是改到本地去了。

2.3 凭证助手：记住密码的代价

HTTPS 方式克隆和推送每次都要输账号密码，烦。教程给的办法是在全局.git/config里加两行：

[credential] helper = store

加完之后，第一次输入的用户名密码会被记住，后续推送不再询问。逻辑很直接：helper = store告诉 Git 把凭证存到磁盘上，Windows 下默认落在用户主目录的.git-credentials文件里。

参数说明：store是明文存储，没有加密。这意味着任何能读到你用户目录的进程都能拿到这组凭证。教程原文也提醒了「密码会明文保存，请小心保存」，这句话不是客套。共享电脑、多人共用的开发机，不建议开这个。更稳妥的做法是用 SSH 方式，或者用 Windows 凭据管理器（helper = manager），后者把凭证交给系统加密存储，比明文强。

改完配置记得点应用再确定，直接关窗口不生效。验证方法是随便打开一个仓库执行一次拉取，看还问不问密码。

3. SSH 方式打通远程：从生成密钥到克隆落地

3.1 先判断有没有现成的密钥对

SSH 方式的核心是一对密钥：私钥id_rsa留在本地，公钥id_rsa.pub交给服务器。判断有没有现成的，看用户主目录下的.ssh文件夹：

# Windows 下在 Git Bash 或 CMD 里执行 ls ~/.ssh # 期望看到 id_rsa 和 id_rsa.pub 两个文件

有这两个文件就直接跳到上传公钥那一步，没有才需要生成。教程里给的是图形化路径：任意文件夹右键 → Git GUI Here → Help → Show SSH Key，没有 Key 就点 Generate Key。这个方式对不碰命令行的人友好，生成完把内容复制出来即可。

命令行方式更通用，一条命令搞定：

ssh-keygen -t rsa -b 4096 -C "your_email@example.com" # -t rsa 指定密钥类型 # -b 4096 密钥长度，4096 位比默认 2048 更稳 # -C 注释，一般填邮箱，方便在服务器端识别是哪台机器

执行过程中会问保存路径，直接回车用默认的~/.ssh/id_rsa；然后问要不要设密码短语（passphrase），设了每次用密钥都要输，不设就是空密码。团队内部机器、个人开发机一般不设，图省事；对安全要求高的环境建议设一个。

生成完.ssh目录下就有了两个文件。私钥id_rsa绝对不能外传，公钥id_rsa.pub可以随便给。这个关系搞反了是血泪级别的错误——把私钥贴到服务器上，等于把家门钥匙挂在门口。

3.2 公钥上传到服务器的两条路径

公钥内容用记事本打开id_rsa.pub全选复制。上传位置取决于你用的服务器：

粘贴时注意别多带换行或空格，公钥是一整行，格式以ssh-rsa开头、邮箱结尾。粘错了服务器不会报格式错误，只会在克隆时提示权限拒绝，排查起来很绕。

为什么服务器要认公钥？因为 SSH 协议下服务器拿公钥加密一段挑战信息，只有持有对应私钥的客户端才能解开，解开了就证明「你是你」。这比每次输密码安全，也省事。

3.3 克隆：URL 填对，目录选对

克隆入口在右键菜单：空白处右键 → Git 克隆（Clone）。弹窗里两个关键字段：

• URL：从服务器仓库页面复制的 SSH 地址，形如git@host:group/project.git。注意 SSH 地址和 HTTPS 地址长得不一样，复制错了会走 HTTPS 通道然后卡在密码输入。
• 目录：本地存放位置，建议统一放在前面建好的E:\Git下，每个项目一个子目录。

点确定后弹出进度窗口。这里有个教程里点到的坑：服务器端仓库至少要有一个文件（比如一个 README），否则拉取时会报fatal: Couldn't find remote ref HEAD。原因是空仓库没有 HEAD 引用，克隆流程拿不到默认分支。遇到这个报错不用怀疑网络，先去服务器上建个初始文件。

克隆成功后文件夹上会出现角标。角标是 TortoiseGit 最直观的状态反馈，含义如下：

角标不显示是另一个高频问题，通常是资源管理器图标覆盖缓存没刷新，或者 TortoiseGit 的图标覆盖设置被其他软件挤占。重启资源管理器一般能解决，顽固的话需要调整注册表里的图标覆盖顺序。

4. 日常四步走：改、提交、拉取、推送的实操节奏

4.1 提交到本地：先攒后交，信息写清楚

日常流程和 SVN、TFS 的习惯一致：改文件 → 提交本地 → 拉取同步 → 推送远程。第一步改动不用多说，改完文件角标变红。第二步在项目空白处右键 → Git 提交 → “master”。弹窗上半部分是提交信息输入框，下半部分是变更文件列表，勾选要提交的文件。

提交信息别写「修改」「更新」这种。多人协作时，日志是唯一的追溯线索，写清楚「修复登录页空指针」「补充接口超时重试」比什么都强。教程里提到可以顺便新建分支，这个在需要隔离改动时用，日常小改直接提交当前分支即可。

点提交后进度窗口走完，改动进入本地仓库。注意此时远程仓库还没有这些内容，角标会变成「本地领先远程」的状态。很多人以为点了提交就完事了，结果同事拉不到代码，就是漏了推送。

4.2 拉取在前，推送在后

推送之前先拉取，这是减少冲突最有效的一招。右键 → Git 同步，打开同步窗口，点「拉取」。如果远程没有新提交，提示已是最新；如果远程有别人的改动，会尝试合并。

合并顺利的话直接进下一步推送。合并冲突的话，TortoiseGit 会列出冲突文件，双击进入冲突编辑器，逐段选择保留哪边的改动，标记解决后保存，再提交一次合并结果。冲突的本质是同一文件的同一区域被两边改了，工具只能帮你可视化，判断留谁还得靠人。

教程里那句「修改本地内容之前最好先拉取一下」值得当纪律执行。养成动手前先拉的习惯，冲突概率能降一大截。反过来，改了半天才拉，一合并发现大段冲突，返工成本高得多。

4.3 推送与凭证

推送入口在同步窗口的「推送」按钮，或者右键菜单 TortoiseGit → 推送。弹窗一般保持默认，点确定。HTTPS 方式下会弹用户名密码框，输对了进度走完显示成功。如果前面配了helper = store，这次输完以后就不再问了。

SSH 方式下不弹密码框（除非密钥设了 passphrase），直接走完。这也是 SSH 一劳永逸的地方——配一次，后面所有仓库都省心。

推送失败的常见原因有三个：远程有新提交没拉（提示 non-fast-forward，先拉再推）、权限不足（公钥没配对或者账号没有写权限）、网络不通（公司内网访问外部托管平台受限）。看进度窗口的报错原文，基本能定位到是哪一类。

5. 避坑清单：角标、冲突、凭证与路径的五个翻车现场

5.1 角标全变问号或干脆不显示

现象：克隆下来的项目，所有文件都是蓝色问号，或者文件夹上什么角标都没有。

原因：蓝色问号意味着 Git 不跟踪这些文件，通常是.git目录丢失或克隆不完整；完全不显示角标则是 Windows 图标覆盖缓存的问题，系统对图标覆盖 handler 有数量限制，装了一堆网盘、同步工具后 TortoiseGit 的覆盖图标可能被挤掉。

解决：先确认项目根目录下有.git文件夹，没有就重新克隆。有的话重启资源管理器（任务管理器里重启 explorer.exe），还不行就检查注册表HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers，把 TortoiseGit 相关项前面的空格去掉让它排到前面。

5.2 推送被拒：non-fast-forward

现象：推送时进度窗口报rejected，提示non-fast-forward或fetch first。

原因：远程分支上有你本地没有的提交，Git 拒绝覆盖，防止丢别人的代码。

解决：先拉取再推送。同步窗口点拉取，合并完再推。不要用强制推送（force push）绕过，那会覆盖远程历史，协作场景下是事故级操作。

5.3 凭证记住了但推送仍要密码

现象：明明配了helper = store，每次推送还是弹密码框。

原因：配置写在了本地.git/config而不是全局配置，只对那一个仓库生效；或者 URL 从 HTTPS 换成了 SSH，凭证助手对 SSH 不生效。

解决：打开设置确认改的是全局配置；检查远程地址是 HTTPS 还是 SSH，SSH 方式本来就不走凭证助手，靠密钥对认证。

5.4 克隆报 Couldn't find remote ref HEAD

现象：克隆进度走到一半报错退出。

原因：远程仓库是空的，没有任何提交，没有 HEAD 引用。

解决：在服务器端先建一个初始文件（README 之类）提交上去，再重新克隆。这不是本地环境问题，别在网络上浪费时间排查。

5.5 中文乱码与路径空格

现象：提交信息或文件名里的中文显示成乱码；或者 Git 路径带空格导致某些操作失败。

原因：Git 默认对非 ASCII 字符的处理配置不一致；安装路径含空格时部分调用没加引号。

解决：在 Git Bash 里执行git config --global core.quotepath false让中文路径正常显示，提交信息乱码则检查编辑器和终端编码是否统一为 UTF-8。安装路径尽量避开空格和中文，D:\Program Files\Git这种带空格的路径虽然多数情况能用，但出问题时是隐形的排查障碍。

6. 进阶验证：用日志和差异对比确认操作真的落地

图形界面用久了容易产生一种错觉：点了按钮就是成功了。实际不是，进度窗口一闪而过不代表结果正确。我一般用两个动作做验证，成本很低但能挡住大部分「以为提交了其实没有」的情况。

第一个是看日志。项目右键 → TortoiseGit → 显示日志，能看到当前分支的提交历史，每条记录带作者、时间、提交信息和变更文件数。推送之后再看一次，如果远程分支的日志里出现了你刚才那条提交，才算真正推上去了。日志窗口还能对比任意两个提交的差异，排查「这个改动是哪次提交引入的」特别顺手。

第二个是看差异。提交前在提交弹窗里双击某个文件，能逐行看到改了什么。这个习惯能挡住误提交——比如调试时临时改的配置、本地生成的日志文件，提交前扫一眼差异就能发现并排除。比提交完再回滚省事得多。

再补一个 SSH 连通性验证的命令，配完密钥不确定通不通时用：

ssh -T git@your-git-host # 成功会返回类似 "Hi xxx! You've successfully authenticated" # 失败会提示 Permission denied (publickey)

-T表示不分配终端，只做认证测试。返回权限拒绝的话，按顺序查：公钥是否完整粘贴、私钥是否在~/.ssh下、服务器端 SSH 功能是否开启。这三步覆盖了绝大多数 SSH 认证失败。

还有一个容易被忽略的点：TortoiseGit 的很多操作和命令行是等价的，图形界面出问题时，打开 Git Bash 在项目目录下敲git status和git log --oneline -5，往往比在界面上翻菜单更快定位。图形工具是加速器，不是黑匣子，底下的 Git 命令该会还得会。

从那以后我每次配完新机器，都强制走一遍「克隆一个测试仓库 → 改一个文件 → 提交 → 拉取 → 推送 → 看日志确认」的闭环，全通了才认为环境配好了。这套动作五分钟，能提前暴露路径、凭证、权限三类问题，比等到正式项目上翻车强。希望帮到你。

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