企业官网建设流程全解析

前两天有个新手同事抱着电脑过来找我，说在命令行里执行git push老是提示权限错误，项目文件拷来拷去乱成一锅粥，问我有没有更直观的办法，能让他一边看着文件状态一边把代码从本机推到 Github 远程仓库。我直接给他装了 TortoiseGit，五分钟演示完一套完整流程，他当场就明白了。如果你也是刚从 SVN 或者纯图形界面转过来，还没习惯命令行，或者已经装了 Git 但总觉得git add、git commit、git push这套操作太抽象，那这篇笔记就是给你准备的。我会把 TortoiseGit 这个图形化客户端的基本使用，以及“Git 本机版本库上传至 Github 远程版本库”这条主线完整拆开讲，从安装配置到日常提交，再到最后推上 Github，每一步都写清楚为什么要这么做，顺便把我在实际使用中踩过的坑一并列出来。

1. 为什么要用 TortoiseGit：思路与选型

1.1 Git 到底在解决什么问题

先把最基础的事情说透。Git 是一个分布式版本控制系统，它和 SVN 最大的区别在于：每个开发者的本机都有一份完整的仓库历史，不需要时刻连接中央服务器才能提交。这意味着你在本地可以随意创建分支、提交版本、回滚错误，等到网络通畅时再和远程仓库同步。

但是，Git 的命令行操作对新手来说确实有门槛。一个是概念多：工作区、暂存区、本地仓库、远程仓库、HEAD、分支指针；另一个是命令组合多：git status、git add、git commit、git push、git pull这一套组合拳如果没理解，很容易出现“我明明提交了怎么远程没有”的困惑。更麻烦的是，命令行里的错误提示常常是一大段英文，新手一看到fatal就直接慌了。

这时候就需要一个 GUI 工具来兜底。GUI 工具不是给“不会命令行的人”用的，而是给“不想被命令行细节干扰的人”用的。它把仓库状态可视化出来，哪个文件改了、哪个文件暂存了、哪个分支领先还是落后，一眼就能看明白。

1.2 GUI 工具和命令行怎么选

我的建议是：不要搞成对立关系。命令行能做的自动化事情更多，比如写脚本、批量操作、在服务器上执行；GUI 工具的优势是直观、点选式操作、出错率低。实际项目里，两者经常混用。你在本机做代码整理、提交，用 TortoiseGit 点几下就完成；要处理复杂的 rebase 或者写自动化流程，再打开命令行。

市面上的 Git 图形客户端不少，有 TortoiseGit、SourceTree、GitKraken、VS Code 自带的源代码管理面板。但我个人推荐新手先接触 TortoiseGit，原因有三：

1. TortoiseGit 和 Windows 资源管理器深度集成，文件夹和文件右键就能看到 Git 操作菜单，不需要打开额外窗口。
2. 它是开源免费的，没有试用期限制，安装体积小。
3. 它继承了 TortoiseSVN 的操作习惯，如果你以前用过 TortoiseSVN，上手成本几乎为零。

1.3 TortoiseGit 的核心优势与定位

TortoiseGit 不是一个“简化版 Git”，它只是一个图形化外壳，底层调用的还是 Git 命令。所以你在 TortoiseGit 里做的任何操作，本质上都是执行对应的 Git 指令。这也解释了为什么有时候你能在命令行里看到 TortoiseGit 弹出的操作日志。

它最实用的几个功能是：

• 文件状态图标：修改过的文件、冲突的文件、已忽略的文件都会在资源管理器中盖上不同颜色的图标。
• 右键菜单集合：提交、拉取、推送、切换分支、创建分支、打标签、查看日志，全都集中在右键菜单里。
• 可视化日志：每个提交的作者、时间、提交信息、变更文件列表都一目了然。
• 冲突编辑器：合并冲突时用图形化界面逐个文件处理，比在命令行里改三个符号舒服得多。

不过要注意，版本检查图标在文件数量很多的大仓库里可能会有刷新延迟，这是我实测中遇到的一个小毛病，后面第 5 部分会专门说。

2. 环境准备：安装和初始化配置

2.1 安装 Git for Windows

TortoiseGit 说到底是个壳子，它依赖 Git 本身，所以第一步永远是先装 Git for Windows。这一步不难，但有几个选项需要注意。

打开 Git 官网下载安装包，一路 Next 时，你会遇到几个关键选项：

• “调整你的 PATH 环境变量”这一项，建议选 “Git from the command line and also from 3rd-party software”，这样 TortoiseGit 能顺利找到 Git。
• “配置行结束符转换”这一项，我建议选默认的 “Checkout Windows-style, commit Unix-style line endings”，也就是签出时转成 Windows 的 CRLF，提交时转成 LF。这个选项和后面换行符警告有直接关系，新手先用默认，后面第 5 部分再展开讲。
• “配置终端模拟器”选默认的 MinTTY 即可。

安装完成后，在任意文件夹空白处点右键，如果能看到 “Git Bash Here” 这个选项，就说明 Git 安装成功了。这一步是整个流程的地基，地基不稳后面全白搭。

2.2 安装 TortoiseGit 与中文语言包

TortoiseGit 的安装包同样在官网下载，装完默认是英文界面。如果看英文费劲，可以装一个中文语言包。语言包也是独立安装程序，装完打开 TortoiseGit 的 Settings，在 “General” 里把 Language 改成 “中文（简体）”，然后重启资源管理器或注销一次，界面就变成中文了。

这里要提醒一句：界面中文化和 Git 的文件编码完全是两回事。仓库里的文件、commit message 里的中文能不能正常显示，取决于文件本身编码和 Git 的配置。很多新手看到 TortoiseGit 界面变成中文后，提交信息里还是出现乱码，就是因为没有设置core.quotepath和字符编码。这个我也会在第 5 部分给出现成的配置方式。

安装完成后，在文件夹右键菜单里能看到 “TortoiseGit” 子菜单，包括 “Git 同步”、“拉取”、“提交”、“推送”、“切换/检出”等常用操作。注意，如果你的系统有文件夹图标覆盖层显示不出来的问题，那通常是图标缓存或资源管理器冲突导致的，不是安装失败。

2.3 SSH 密钥配置：先打通认证

要把本机仓库推送到 Github 远程仓库，必须解决认证问题。Github 目前推荐 SSH 方式，而不是 HTTPS 方式。SSH 的好处是配置一次之后，后续推送拉取都不需要反复输入账号密码；HTTPS 方式虽然也能用，但为了避免密码泄漏和每次输密码的麻烦，我更推荐 SSH。

在安装了 Git for Windows 之后，打开 Git Bash，执行下面这段命令，把邮箱换成你自己的常用邮箱：

ssh-keygen -t ed25519 -C "your_email@example.com"

命令执行后会有几个提示：

• 第一个提示询问密钥保存路径，直接按回车使用默认路径（一般是C:\Users\你的用户名\.ssh\id_ed25519）。
• 第二个提示输入私钥密码，可以直接留空，按两下回车；也可以输入一个短语，以后每次使用 SSH 操作时要输入。

生成完成后，用cat ~/.ssh/id_ed25519.pub查看公钥内容，复制整段以ssh-ed25519开头的字符串。然后在 Github 网页端操作：右上角头像 → Settings → SSH and GPG keys → New SSH key，Title 随意填写，Key 粘贴刚才复制的内容，保存。

为了确认密钥配置成功，回到 Git Bash 执行：

ssh -T git@github.com

如果看到类似 “Hi xxx! You've successfully authenticated” 的提示，说明 SSH 认证已经打通，可以继续往下走。这一步别跳，否则后面怎么推送都会报权限错误。

3. TortoiseGit 本地仓库的基本操作

3.1 初始化仓库与关键设置

本地仓库听起来很抽象，其实就是一个由 Git 管理的文件夹。Git 会在文件夹里隐藏一个.git目录，里面记录所有版本数据。所以初始化仓库的操作非常直观：在你项目的根文件夹里右键，选择 “Git 创建版本库”。

注意，右键菜单里有两个选项：“Git 创建版本库”和 “Git 在这里创建版本库”。前者是在当前文件夹内部创建.git，后者是创建一个包含当前文件夹的新目录作为仓库。一般我们选前者，让现有项目文件夹直接变成仓库。

创建完成后，项目文件夹的图标上可能会多出绿色对钩，表示仓库已就绪。如果你发现没有图标变化，先检查文件夹选项里是否开启了“显示隐藏文件”，再看看资源管理器是否启用了 TortoiseGit 的标覆盖。

这里还有一个建议：初始化仓库后，应该先创建一个.gitignore文件再第一次提交。.gitignore用来排除不需要纳入版本管理的文件，比如编译产物、IDE 配置、临时文件。不设这个文件，你提交之后可能发现一坨bin、obj、node_modules全被 Git 跟踪了，后面清理起来非常麻烦。用记事本或编辑工具在仓库根目录新建.gitignore，把不需要的文件或目录写进去：

# 编译输出 bin/ obj/ # 依赖目录 node_modules/ # 日志文件 *.log

3.2 日常提交流程：工作区到本地仓库

Git 的提交分两步：从工作区到暂存区，从暂存区到本地仓库。TortoiseGit 把这套过程整合到一个提交界面里，但你脑内要始终清楚这两个概念。

当你修改了一个文件后，文件图标会变成红色感叹号。右键该文件或仓库根目录，选择 “Git 提交”，会弹出提交窗口。窗口上半部分是暂存区预览，下半部分列出所有变更文件。每个文件前有个复选框，勾选它等价于git add，把一个文件放到暂存区。取消勾选则是不暂存。下方的“提交信息”输入框等价于git commit -m "说明"。

这里有一个我强烈建议的细节：不要把所有文件一股脑全部勾选提交。每次提交只放相关的修改，提交信息写清楚“这次改了什么、为什么改”，比如 “修复登录接口超时问题” 而不是 “改bug”。这样以后看历史日志时，每一条提交都能对应一段明确的工作内容，排查问题时方便得多。

提交完成后，版本只存在于本地仓库，还没有到远程。很多新手会误以为“我提交了，服务器上应该有了”，其实还差一个推送动作。

3.3 分支管理与冲突处理

分支是 Git 区别于 SVN 的核心能力之一。TortoiseGit 里操作分支非常直观：右键仓库根目录 → TortoiseGit → “创建分支”，输入分支名称，选择基于哪个分支创建，确定。

默认分支名一般是master，但 Github 新仓库默认分支名是main，两者混用容易迷茫。建议本机初始化仓库后就把默认分支名改成main，或者在初始化时直接指定。改分支名在 TortoiseGit 里也能做：右击仓库根目录 → TortoiseGit → “重命名分支”。

切换分支用 “切换/检出” 功能，它会弹出对话框让你选择要切过去的分支。这里有一个关键细节：切换分支前，工作区必须是干净的，也就是所有修改都已经提交或暂存。如果你有未提交的修改就切换分支，TortoiseGit 会阻止你，或者把修改带到目标分支上，容易造成混乱。

当你在一个分支上改了某个文件，另一个分支也改了同一个文件的同一处，合并时就会产生冲突。冲突文件的图标会变成黄色感叹号。这时候双击冲突文件，TortoiseGit 会打开合并冲突编辑器，左侧是当前分支版本，右侧是合并进来的版本，中间是合并结果。你可以逐段选择保留哪个版本，或者手动编辑中间区域。处理完所有冲突后，标记为已解决，再进行一次提交，合并才算完成。

3.4 查看历史与还原操作

查看历史日志是 TortoiseGit 里使用频率很高的功能，直接右键仓库根目录 → “显示日志”。日志视图里能看到所有提交记录，每条记录对应的时间、作者、提交说明都一清二楚。点开某条提交，底部会列出这次提交新增、修改、删除了哪些文件，还能直接双击文件查看具体改动内容。

日志功能对排查“什么时候改坏了”特别有用。我实际遇到过一个情况：某天项目突然编译不过，但是我已经忘了最近改了什么。打开日志，从最近一次提交往前逐个点击查看 diff，很快定位到是一条把配置项名字拼错的提交，然后用 “还原此版本做出的更改” 功能把它撤销。

TortoiseGit 里有两个容易混淆的还原操作：

• “还原” 指撤销工作区未提交的修改，把文件恢复到最近一次提交的状态。
• “还原此版本做出的更改” 指基于某一条历史提交，生成一个反向变更，把这次提交的影响撤销掉。

前者适合还没提交就想放弃修改的场景，后者适合已经提交了但发现改错、要撤回的场景。注意，后者会生成一个新提交，而不是把历史抹掉。在多人协作时，这种“向前修复”的方式比“改写历史”更安全。

4. 本机仓库上传至 Github 远程仓库的完整流程

4.1 在 Github 上创建远程仓库

本地仓库准备好之后，就可以把它推到 Github 上。先登录 Github 网页端，点击右上角的加号，选择 “New repository”。这里有几步需要注意：

• Repository name：填一个仓库名，建议和你本地项目名一致，例如my-project。
• Description：仓库说明，可填可不填，但填了便于别人知道这个项目是干什么的。
• Public / Private：公开仓库任何人可见，私有仓库只有你和你邀请的协作者可见。个人项目如果没打算开源，建议先选 Private，以后想公开再改。
• 不要勾选 “Add a README file”“Add .gitignore”“Choose a license”。因为这些选项会在远程仓库生成初始提交，导致本地仓库和远程仓库是两个互不相关的历史，首次推送时需要额外处理合并，对新手不友好。

创建完成后，Github 会展示一种推代码的指引。目前推荐 SSH 方式，远程地址形如：

git@github.com:你的用户名/your-project.git

这个地址就是远程仓库的“门牌号”，后面推送全靠它。

4.2 添加远程地址与首次推送

远程仓库创建好了，现在回到本地项目文件夹，右键仓库根目录 → TortoiseGit → “设置”，进入 “远程” 配置页，给本地仓库添加一个远程地址。这里的操作路径在不同版本中稍有差异，但核心字段一样：

• 远程名称（Remote）：默认填origin，这是约定的主远程仓库名称，没有特殊理由不建议改。
• URL：粘贴刚才从 Github 复制的那段git@github.com:...。
• 推送 URL 可以和 URL 保持一致，除非你配置了特殊的推送规则。

保存后，远程配置就完成了。接下来是首次推送：右键仓库根目录 → “Git 同步”，在弹出的同步对话框里选择推送方向，通常是从本地main分支推送到origin的main分支。勾选 “推送所有分支” 或者 “推送到所有远端” 要看实际需求，首次推送我建议只推送当前分支，干净利落。

点击“推送”后，TortoiseGit 会调用 SSH 认证。如果之前配置 SSH 密钥时没有设置私钥密码，这一步会直接通过；如果设置了，会弹窗要求输入密码。推送成功后，刷新 Github 仓库页面，就能看到你的项目文件和提交记录了。

这里我要强调一点：首次推送时必须确保本地仓库至少已经有一个提交，否则远程仓库是一个空对象，推送会报错。所以流程是：本地 init → 提交 → 关联远程 → 推送，不要调换顺序。

4.3 后续更新：拉取、推送与协作

首次推送完成后，日常操作就变成了两条线：把远程更新的代码拉下来，把自己本地的新提交推上去。

拉取用右键菜单里的 “Git 拉取” 或 “Git 同步” 里的拉取按钮。拉取本质上是两步合并：先git fetch把远程的最新提交下载到本地缓存，再git merge合并到当前分支。TortoiseGit 提供了一个组合动作叫 “拉取”，实际执行的就是 fetch + merge。

推送则是把本地已经提交、远程还没有的提交上传。这里有一个常见的理解误区：git push不会把你工作区未提交的修改传到远程。你要先提交（commit），再推送（push），这是一套固定流程。

多人协作时，拉取和推送的顺序非常重要。正确的习惯是：

1. 动手改代码前先拉取一次，确保本地和远程尽量同步。
2. 本地完成提交。
3. 推送前再拉取一次。如果远程有别人推送的新提交，本地会进行一次合并，可能产生冲突，处理完冲突后再推送。
4. 确认没有冲突后，推送。

这样做的核心原因是 Git 默认不允许“非快进”推送。简单说，如果远程仓库的提交历史包含了本地没有的提交，而你的推送会让远程历史被覆盖，Git 会直接拒绝合并。这不是 Git 故意刁难你，而是为了保障每个参与者的提交都不丢失。

5. 常见问题与排查实录

5.1 认证相关错误

推送或拉取时最常见的错误是类似这样的提示：“Permission denied (publickey)” 或者 “Failed to authenticate”。这个问题的排查顺序是固定的：

第一，确认你本机是否存在 SSH 私钥。看C:\Users\你的用户名\.ssh\下有没有id_ed25519或id_rsa文件。如果没有，回到第 2.3 节重新生成密钥。

第二，确认公钥是否已经添加到 Github 账户。Github 上的 SSH and GPG keys 页面里应该有刚才添加的那条记录。如果之前添加过，但换了台电脑或重装了系统，需要重新添加新生成的公钥。

第三，确认远程地址是不是 SSH 开头。如果远程地址误填成了https://github.com/...，TortoiseGit 走的就是 HTTPS 认证，如果你没有配置 PAT 或者凭据过期，也会报错。

一个调试小技巧：在 Git Bash 里执行ssh -T git@github.com，如果提示 success，说明密钥本身没问题；如果提示 permission denied，说明密钥和账户没对上。这个命令能快速定位问题在本地还是远程。

5.2 推送被拒绝（Non-fast-forward）

当你看到 “Updates were rejected because the remote contains work that you do not have locally” 或者 “Non-fast-forward” 时，说明远程有本地没有的提交。新手常犯的错误是直接强推，也就是在 GUI 里勾选 “强制推送”。这个操作我建议一律不要用，因为它会覆盖远程历史，可能导致别人的提交丢失，后果非常严重。

正确的做法是：先 “拉取” 远程更新，处理合并冲突，提交合并结果，再推送。TortoiseGit 在同步窗口里也提供了拉取按钮，你可以先拉取，看到冲突就解决冲突，解决完提交，再点推送。

需要留意的是，如果远程分支和本地分支从某个历史点开始分叉得太严重，拉取时会提示 “Failed to merge” 或者产生大量冲突。这时候不要慌，逐个解决冲突，或者用 “中止合并” 先恢复原状，重新梳理分支后再合并。

5.3 换行符警告与误提交

在 Windows 上使用 Git，几乎每个人都会遇到换行符问题。现象有两种：一种是git add时提示 “warning: LF will be replaced by CRLF”；另一种是打开历史 diff 时，发现整个文件被标记为修改，但肉眼看起来内容一样。

原因就是 Windows 用CRLF作为换行符，而 Linux/Mac 用LF。Git 为了兼容这两种环境，提供了core.autocrlf配置。TortoiseGit 里也可以设置。

我常用的配置方案是：

git config --global core.autocrlf true

这个配置的含义是：从仓库检出文件时自动转成CRLF，提交时自动转回LF。这样仓库内部统一存储LF，Windows 上的编辑器又能正常打开文件，基本能消除换行符警告。

如果你发现仓库里已经混入了大量错误换行符，比如某些老文件是CRLF入库的，这时用 TortoiseGit 的 “显示日志” 里那种整体 diff 会非常痛苦。彻底清理的办法是把所有文件统一转成LF再提交一次，实际操作可以用编辑器批量转换，但要注意这会生成一个“整个仓库都改动”的提交，最好在和其他人沟通后再做。

5.4 大文件与子模块问题

Git 处理大文件一直不擅长。如果你不小心把几百兆的压缩包、视频或者编译产物提交进了仓库，就会出现两个问题：仓库体积暴涨，每次克隆都要下载所有历史版本的这些大文件；推送时也可能因为单文件超过平台限制而被拒绝。

我的建议是，从一开始就在.gitignore里排除这些文件。如果已经误提交了，不要只删除文件再提交，因为历史提交里还躺着那个大文件。需要改写历史才能真正删掉，但改写历史又会影响其他人，成本比较高。真正的预防手段只有一个：用.gitignore挡住入口，并且养成提交前看变更列表的习惯。

还有一种情况是子模块。如果你在一个仓库里通过 Git 引用了另一个 Git 仓库，TortoiseGit 会显示为子模块。新手经常会发现，明明更新了子模块里的代码，父仓库的提交里却没有相应变化，或者克隆父仓库后子模块目录是空的。这是因为子模块的本质是一个指针，指向另一个仓库的某个具体提交。要正确更新子模块，需要在父仓库里右键 “更新子模块”，或者使用命令行git submodule update --init --recursive。

5.5 文件状态图标不显示

资源管理器里的文件图标突然全部变成白色，没有绿色对钩和红色感叹号，这是 Windows 下很常见的问题。原因通常是系统图标覆盖层有上限，而 TortoiseGit 的图标没有优先加载。

常规解决办法有两种：

第一种，打开 TortoiseGit 的 Settings → Icon Overlays，把 “Status Cache” 从 “Default” 改成 “Shell”，或者改为 “None”。改成 Shell 可以更频繁地刷新文件状态，但文件夹文件多时会比较卡；改成 None 则完全禁用状态缓存，但图标可能刷新不及时。我一般用 “Shell”，实测在 5000 文件规模的项目里依然流畅。

第二种，调整右键菜单的 “TortoiseGit → Settings → Icon Overlays → Number of overlays” 里的显示数量，或者使用系统自带的 “显示覆盖图标”修复方案清理图标缓存。如果两个方法都不生效，重启资源管理器进程通常能解决。

6. 实操心得与避坑清单

6.1 我踩过坑后总结的几条习惯

用了这么久的 TortoiseGit，我最想拿出来说的几条习惯，都是拿实际教训换来的。

第一条，提交信息永远写清楚“为什么”，而不是只写“改了什么”。比如“优化登录流程”就不如“调整登录接口参数，增加验证码过期时间”。理由很简单：三个月后你再回来看日志，当时的上下文早就忘了，提交信息是唯一可靠的线索。TortoiseGit 的日志界面还支持按提交信息搜索，信息写差了搜都没法搜。

第二条，提交前用“显示日志”检查一下历史，尤其是准备推送之前。我有一次准备推送到共享分支，突然想起自己之前在一个fix分支上提交过调试代码，当时忘了切回主分支。幸好推送前扫了一眼日志，看到那个分支上的提交不在预期历史里，及时中止了推送，避免了一次污染主干的事故。

第三条，.gitignore一定是“先有后提交”，而不是“提交后再补”。很多项目一开始没加.gitignore，导致node_modules或bin目录进了历史，后续每人克隆一次都要下载一堆无用的依赖文件。仓库被拖慢以后，清理历史又变成大工程。这一步的成本最低，收益最高。

6.2 给新手的工作流建议

如果你是第一次在团队中用 Git，我强烈建议建立一套最小可用工作流，不要一开始就追求复杂的分支策略，先把流程跑通。

我的推荐是这样：

1. 从远程仓库 “克隆” 到本机，而不是自己初始化。这就是 TortoiseGit 里的 “Git 克隆” 功能，填入远程地址即可。
2. 每次改代码前，先 “拉取” 一次远程更新。
3. 一个功能或一个修复对应一个分支，分支名用语义清晰的短语，比如fix-login-timeout。
4. 完成一个功能后，提交到本地分支，推送到远程同名分支。
5. 再通过网页端的 Pull Request 或团队约定的方式合并到主分支。

这套流程的核心优势在于：主分支始终处于相对稳定状态，每个人的工作在独立分支上进行，冲突被限制在各自分支的合并阶段。TortoiseGit 在切换到分支、创建分支、合并分支这些操作上都有图形化入口，多在这里点点鼠标，你对 Git 的理解会比单纯背命令快得多。

最后再分享一个实际操作中的体会：不要害怕在 GUI 工具里打开 “显示命令行” 或日志输出窗口。TortoiseGit 会把每一条 GUI 操作翻译成对应的 Git 命令显示出来，这反而是学习命令行的最佳途径。我一开始也是先点按钮做操作，看它背后的命令，然后把命令记下来，慢慢地，离了鼠标也能自己在命令行里完成常用的提交推送流程。工具是给人用的，能帮你把事做对就是好工具。