企业官网建设流程全解析

1. 先搞清楚 pull 到底做了什么事：一次拉取背后其实是两步动作

很多人在日常开发中每天都在用git pull，但直到出了冲突或者把代码拉丢，才意识到自己对这个命令的理解停留在“把远程代码拉下来”这个层面。老实说，我见过不少工作了两三年的工程师，被问到“git pull和执行git fetch再git merge有什么本质区别”时，依然答不上来。

1.1 fetch 与 merge：pull 是一个组合命令

git pull的本质是git fetch加git merge的合成操作。fetch负责从远程仓库下载最新的提交记录和文件变更，但它只更新一个叫“远程跟踪分支”（remote-tracking branch）的东西，比如origin/main，不会动你当前工作区里任何一个文件。真正把你当前分支和远程分支合并起来的，是后一步的merge。

我用一个生活化的类比来解释：git fetch相当于快递员把邻居送来的新家具搬到了你家门口，货物已经属于你了，但还没摆进客厅；git merge才是把家具搬进客厅、拆掉包装、摆到正确位置的那步操作。git pull则是一句话：“把快递搬进来，顺便摆好。”

这个区分非常关键，因为很多诡异问题都出在“我只想看看远程改了什么，结果工作区直接变了”上。如果你只想了解远程仓库的最新状态，但不打算立刻合并到当前分支，那就应该单独执行git fetch，然后通过git log origin/main查看远程分支上的提交，想清楚再决定要不要合并。

1.2 远程跟踪分支：pull 的“参照物”从哪来

要理解 pull，绕不开“远程跟踪分支”这个概念。当你在本地执行git clone时，Git 会为远程仓库的每个分支创建一个只读的跟踪指针，命名通常是origin/main、origin/dev这种。每次执行git fetch或git pull，Git 会拿着远程仓库的最新提交更新这些指针，但不会直接改变你本地分支。

你可以把它想象成一张“远程仓库的照片”。照片每隔一段时间会更新，但照片本身不等于你手里的实物。本地分支（比如main）和远程跟踪分支（origin/main）是两个独立的引用，git merge做的工作就是把这两个引用的历史合并到同一条时间线上。

很多人容易混淆的是：git pull不带参数时，它到底拉哪个分支？答案取决于当前分支是否设置了“上游分支”。如果你是用git clone拉下来的仓库，克隆时会自动把本地main和远程origin/main绑定；如果你是自己git init再手动添加远程，那必须显式指定：

git pull origin main

这样才能让 Git 知道“远程仓库的 main 分支”和“当前本地分支”的关系。这也是为什么新手在新建仓库里执行git pull时会看到类似There is no tracking information for the current branch的提示——它不是在报错，只是在告诉你“你还没说清楚要拉谁”。

1.3 fetch 和 pull 到底什么时候该拆开用

学 Git 最忌讳记了一堆命令但不知道使用场景。这里我直接给出一张对比表，方便你按实际需求对号入座：

我个人的习惯是：在多人协作分支上，先git fetch再看git log，确认远程没有自己不能接受的提交（比如有人 force push 覆盖了历史），再决定是git merge还是git rebase。直接git pull虽然方便，但相当于把你的命运交给了 Git 自动合并策略，一旦遇上冲突，处理起来往往比想象中麻烦。

2. 动手前的准备：安装 Git、配置密钥，以及让 GitHub 和 Gitee 双平台共存

工欲善其事，必先利其器。玩转 pull 的前提是你得先有一个能正常访问远程仓库、并且提交作者信息正确的环境。这个环节看着简单，但搜索热词里“git安装及配置教程”、“git配置gitee密钥”常年霸榜，说明很多人恰恰是在起点上跌了跟头。

2.1 安装 Git 并完成基础配置，别把用户信息漏掉

Git 的安装本身没什么技术含量：Windows 用户去官网下载安装包，安装时一路 Next，唯一需要注意的是在“Adjusting your PATH environment”这一步选第二项 “Use Git from the Windows Command Prompt”，这样你在 cmd 和 PowerShell 里都能直接敲git命令；macOS 用户可以直接brew install git，也可以让系统在首次使用 Git 时自动安装命令行工具；Linux 用户则根据发行版用apt install git或yum install git即可。

安装完成后的第一件事是设置全局用户信息，这一步不做，后续所有提交都会报错或者变成匿名提交：

git config --global user.name "Your Name" git config --global user.email "your_email@example.com"

这两个配置写进的是你的提交作者信息，不是认证凭据。很多新手会混淆，总觉得改了 user.name 就能解决 pull 时的权限问题——实际上 pull 的认证靠的是 HTTPS 凭据或 SSH 密钥，和 user.name/user.email 完全是两套体系。

2.2 双平台 SSH 密钥共存：GitHub 和 Gitee 不打架的配置方案

国内开发者的一个典型场景是：公司代码托管在 Gitee，个人开源项目放在 GitHub，两边都要拉代码、推代码。这种时候最忌讳全网生成同一个密钥来回用，更忌讳把同一个密钥同时配到两个平台——虽然技术上也能用，但换机器、换平台时会非常混乱。

我的做法是让两个平台各用一把独立密钥。先分别生成：

ssh-keygen -t ed25519 -C "github@example.com" -f ~/.ssh/id_ed25519_github ssh-keygen -t ed25519 -C "gitee@example.com" -f ~/.ssh/id_ed25519_gitee

注意这里用-f参数指定了不同的文件名，两个密钥文件互不覆盖。生成之后，在~/.ssh/目录下新建一个config文件，内容如下：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github IdentitiesOnly yes Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_gitee IdentitiesOnly yes

然后分别把两个.pub公钥文件的内容粘贴到 GitHub 的 Settings -> SSH and GPG keys 和 Gitee 的个人设置 -> SSH 公钥里。最后用两个命令验证连通性：

ssh -T git@github.com ssh -T git@gitee.com

看到 “Hi xxx! You've successfully authenticated” 这类提示时，说明两边都通了。从这里开始，你从 GitHub 拉取的仓库和从 Gitee 拉取的仓库就会自动使用对应的密钥，不再需要反复认证。

2.3 clone 与 remote：pull 的前置条件取决于仓库连接是否建立

很多人忽略了：git pull本质上是在问“相对于哪个远程仓库、哪个分支”，所以仓库必须关联至少一个远程地址。git clone是最省事的路径，克隆完成后 Git 已经帮你把远程地址记录在origin这个远程别名下，你直接git pull就能用。

但如果你是在本地新建的仓库，就得多一步操作：

git remote add origin git@gitee.com:yourname/repo.git git pull origin main

这里我想重点分享一个双平台共存的实用技巧：同一个本地仓库可以同时挂 GitHub 和 Gitee 两个远程地址，用不同别名区分。比如你在 GitHub 上维护开源项目，同时希望 Gitee 上也有一份拷贝，可以这样设置：

git remote add github git@github.com:yourname/repo.git git remote add gitee git@gitee.com:yourname/repo.git

之后你想拉 GitHub 的更新就执行git pull github main，想拉 Gitee 的就执行git pull gitee main。你甚至可以在两边维护不同的分支策略，互不干扰。我自己的开源项目就是这么维护的：GitHub 作为主阵地，Gitee 作为国内访问较稳定的同步镜像，两边各拉各的，完全不冲突。

3. 高频场景实战：在 GitHub 和 Gitee 上拉代码的几种正确姿势

环境备好之后，真正实用的其实是那些每天都在重复的拉取场景。这一节我不会整一堆命令清单，而是把我在实际项目中验证过的高频操作挑出来，配合说明为什么这样用。

3.1 拉取默认分支：最基础但最容易忽略的差异

日常开发中最常见的命令就是直接执行：

git pull

这个命令的效果是：fetch 当前分支关联的远程跟踪分支，然后 merge 到本地分支。听起来很简单，但有一个隐藏细节——Gitee 仓库默认分支名可能是master，而 GitHub 从 2020 年开始新建仓库默认分支是main。如果你在 Gitee 克隆的仓库，本地默认分支通常是master；如果团队后来把默认分支改成了main，你原来的本地分支和远程分支的跟踪关系可能会失效。

遇到这种情况时，先看当前分支有没有“上游分支”：

git branch -vv

输出里带[origin/main]这类方括号内容的，就是已经绑定了上游的分支。如果没有任何方括号，就用下面的命令手动建立跟踪关系：

git branch --set-upstream-to=origin/main main

这一步做完，后续git pull才能清楚地知道该跟着谁走。

3.2 拉取指定远程分支：别每次都把整仓拉一遍

很多项目的合作流程是：每个功能开一个独立分支，开发完成后合并回主干。这时候如果你在本地也想跟踪一个远程分支，标准做法不是上来就git pull，而是先 fetch 再基于远程分支创建本地分支：

git fetch origin git checkout -b feature-login origin/feature-login

这样做的好处是不需要把仓库里所有分支都拉下来，只针对你关心的那一条建立本地工作分支。本地分支创建好之后，后续的更新就可以直接用：

git pull

Git 会识别出当前本地分支的上游是origin/feature-login，从而精准拉取，不会误把主干上的东西拉进来。

如果你只是想临时看一眼某个远程分支的最新代码，不想切过去，更轻量的方案是：

git fetch origin feature-login git log origin/feature-login --oneline -10

看完再决定是否合并。这样操作既不会打扰你手头的本地分支，也不会产生多余的工作区变更。

3.3 pull --rebase 和 merge 式 pull：历史整洁性由这一步决定

git pull默认走 merge 策略，也就是 fetch 之后执行git merge，这会在本地提交历史里留下一个“合并提交”（merge commit）。在多人协作时，如果每个人都频繁 pull，主干分支的历史就会变得像蜘蛛网一样，全是交织的合并点，看起来非常吃力。

git pull --rebase则是把本地尚未推送的提交“摘下来”，暂时放在一旁，等远程分支的更新拉下来之后，再把本地提交逐个“重放”到远程分支的新顶端之上。这个过程不会产生额外的合并提交，历史会保持一条干净的线性。

我截个真实场景：假设你基于main分支做了三个本地提交，此时远程main上多了两个别人推上去的提交。这个操作：

git pull --rebase

会把你的三个提交先收起来，拉取远程两个新提交，然后依次把你的三个提交重新排到后面。最终的提交顺序是：远程提交1、远程提交2、你的提交1、你的提交2、你的提交3，没有多余的 merge commit。

什么时候该用--rebase？我的标准很简单：如果当前分支只有你自己在推，或者你已经确认没有别人在这个分支上工作，那就放心用 rebase 式 pull；如果是像main这种多人共管的分支，我更倾向于先git fetch看清楚，再决定用 merge 还是 rebase。这里要特别提醒，绝不要在公共分支上对已经推送过的提交执行 rebase，因为你重新排列的是公开历史，一旦强推覆盖，其他人会陷入历史不匹配的混乱。

3.4 本地有未提交修改时，pull 的三种处理方式

很多人被 pull 坑过，问题往往出自同一个源头：本地工作区还有未提交的修改时，直接git pull撞上了远程更新，轻则提示报错，重则文件内容被覆盖或冲突合并。

处理方式无非三种，按推荐程度排序：

第一种，先把改动提交到本地分支：

git add . git commit -m "工作区暂存：功能开发进行中" git pull

这是最稳妥的思路，让本地分支处于 clean 状态再进行合并，冲突范围可控。

第二种，用 stash 把修改暂存起来，拉取完成后再恢复：

git stash git pull git stash pop

适合手头改动还很零碎、不值得占一个提交记录的场景。stash pop时如果提示冲突，直接手动解决后git stash drop即可。要注意，git stash默认不带-u参数时不会暂存新增的未跟踪文件，如果你有新建的文件，需要换git stash -u。

第三种，不做任何处理直接 pull，让 Git 自行判断。只有当本地修改的文件和远程更新的文件完全不重叠时，这个方案才会顺利通过；一旦重叠，Git 会拒绝合并，并提示你需要先处理本地修改。这里我强烈建议不要选第三种，因为它的不确定性太大，而且在团队协作中很容易因为一个意外操作把自己绊住。

4. 从“拉不动”到“拉错了”：完整的问题排查链路

无论操作多熟练，git pull 出问题几乎是每个开发者必然经历的阶段。与其背一堆解决方案，不如建立一条清晰的排查思路：先看报错内容，再判断是本地环境问题、网络问题还是版本历史问题。

4.1 常见报错逐条拆解：fatal 系列与认证失败

搜索热词里 “fatal: not a git repository (or any of the parent directories): .git” 占据了很高的热度，可见这个报错拦住了大量新手。其实它说的是：当前位置不是 Git 仓库，而且向上回溯所有父目录也找不到.git目录。

遇到这个报错，先确认三件事：你是不是真的在一个仓库目录里？当前目录下有没有.git文件夹（可以用ls -a查看）？是不是在仓库的子目录中执行命令？Git 允许在仓库的任意子目录执行命令，因为它会向上回溯寻找.git，但如果你是在/tmp之类完全无关的目录里敲 git 命令，那必然报这个错。还有一种隐蔽场景：你把整个仓库压缩包拷到新环境解压，但拷贝时漏掉了隐藏的.git目录，这时候仓库就是个“空壳”，需要重新 clone 或者恢复 .git。

另外一个高频报错是：

fatal: refusing to merge unrelated histories

这个报错本质上不是 permission 问题，而是历史问题。常见触发场景是：你用git init在本地初始化了新仓库，然后在 GitHub 或 Gitee 上创建了一个带 README 的远程仓库，接着执行git pull origin main，Git 发现两边来自完全不相干的历史，默认拒绝合并。解决方法是显式允许合并不相干历史：

git pull origin main --allow-unrelated-histories

但我更建议一开始就用git clone而不是git init后手动拉取，这样可以从根源上避免这个问题。

认证失败也非常常见。如果你用 HTTPS 方式 clone 仓库，pull 时提示 403 或 Authentication failed，大概率是在 Windows 凭据管理器或 macOS 钥匙串里保存了过期的账号密码。解决方法是打开系统凭据管理器删除旧条目，重新执行 pull 让 Git 弹出新的认证窗口；或者直接切换到 SSH 方式的 remote 地址，彻底告别密码认证：

git remote set-url origin git@gitee.com:yourname/repo.git

4.2 访问 GitHub 不太稳定时的务实降级方案

不得不承认一个现实：国内环境下访问 GitHub 的体验并不总是理想，流量高峰时 clone 和 pull 都可能速度很慢甚至超时。这一节我只说我在实际项目中验证过的、完全依托官方能力的处理手法，不涉及任何非常规通道。

第一个方案是走 SSH over HTTPS 端口。GitHub 官方提供了一种让 SSH 流量通过 443 端口传输的方式，很多公司网络只开放 HTTPS 端口，用这个方案可以有效绕开 22 端口限制。在~/.ssh/config里追加：

Host github.com HostName ssh.github.com Port 443 User git IdentityFile ~/.ssh/id_ed25519_github

改完再执行ssh -T git@github.com验证，看到成功提示后，git pull就走 443 端口了。

第二个方案是调整 Git 的 HTTP 低速率超时限制。默认情况下，如果网络长时间没有数据传输，Git 会等待但不做限制，导致慢到让你以为卡死了。可以设置一个相对合适的超时值：

git config --global http.lowSpeedLimit 1000 git config --global http.lowSpeedTime 60

意思是如果连续 60 秒速率低于 1000 字节/秒，立即判定超时并报错。这个设置的好处是让你尽早明确失败，而不是无限期挂起。

第三个方案是浅克隆。如果你只是要最新代码，不需要完整历史，clone 时加--depth 1，只拉取最近一次提交，传输量会小很多；后续需要更多历史时再用git fetch --unshallow补全。对大仓库来说，这个技巧在 Gitee 上同样有效。

第四个方案最务实：如果 GitHub 实在不稳定，而你的项目在 Gitee 上有镜像仓库，那就直接从 Gitee 拉取。复制远端仓库地址这种事不丢人，代码能顺利拿到手上才是目标。我通常的做法是在开源项目上双托管，pull 时优先选择网络体验更好的边。

4.3 冲突是怎么产生的：同一个文件的两个“真相”

当 pull 操作自动合并失败时，意味着远程分支和本地分支对同一个文件的同一部分做了不同的修改，Git 无法替你做出选择。这发生在git pull的 merge 阶段，报错信息通常类似：

Automatic merge failed; fix conflicts and then commit the result.

冲突的本质是同一文件出现了两个版本的历史。假设你和同事基于同一个提交各自改了config.js的第三行，你先提交到远程，他在本地也改了同一行再 pull，Git 就无法判断该保留谁的第三行。此时 Git 会在冲突文件里注入特殊的标记：

<<<<<<< HEAD 你的修改内容 ======= 远程分支的修改内容 >>>>>>> origin/main

<<<<<<< HEAD到=======之间是当前分支（HEAD）的内容，=======到>>>>>>> 分支名之间是来自远程分支的内容。你需要人工判断保留哪边，或者把两边内容都保留并整理成合理的格式。

4.4 解决冲突的操作步骤与工具选择

解决冲突的第一步是用git status找出所有冲突文件，Git 会用both modified: 文件名标出这些文件。然后逐文件打开，删除冲突标记，保留你需要的最终内容。改完之后：

git add 已修改的文件 git commit -m "解决 config.js 合并冲突"

注意，这里必须 commit，这相当于告诉 Git 冲突已经解决完毕，下一次 pull 才能继续。

工具选择上，轻量场景我推荐直接用 VS Code 自带的三路合并编辑器，它能清晰展示“当前更改”“传入更改”和“合并结果”三个面板；用 IDEA 做 Java/Kotlin 开发的人，则可以在 VCS 菜单里调出 Git 的 Merge 工具，效果同样直观。命令行党可以尝试git mergetool，配合 vimdiff 等外部工具，但交互效率通常不如图形化工具。

最后我想强调一个实战心得：冲突并不可怕，可怕的是带着情绪通宵解决冲突。预防永远优于治疗——经常 pull、小步提交、团队成员尽量不碰相同文件的相同区域，这三条纪律做到位，多数冲突根本不会发生。

5. 拉取之后的事情：回退、amend 与分支合并的联动

代码成功 pull 下来之后，事情往往没有结束。你可能会发现拉错了分支、提交信息写错了、或者需要把拉下来的改动和其他分支做整合。这些“善后”操作看似零散，但和 pull 的配合非常紧密。

5.1 一旦拉错版本，怎么回到想要的状态

最危险的场景是：你执行git pull后，工作区被更新成了你完全没想到的状态，或者你发现这次拉取引入了严重的坏代码，想回到之前的版本。这时需要分情况处理。

如果你只是想放弃本地所有未提交的修改，回到当前分支的最新提交，可以用：

git checkout -- .

这会丢弃工作区所有改动。但如果你连本地提交都想一起回溯，那就要动分支指针了。比如你希望本地main强制回到远程最新提交的位置：

git reset --hard origin/main

--hard的意思很明确：工作区、暂存区、分支指针全部重置。这条命令威力极大，执行前务必确认你没有任何需要保留的改动。我见过太多人在这条命令上栽跟头——一执行，所有未提交的辛辛苦苦写的代码就人间蒸发了。

更安全的方案是先把当前状态保存到一处再重置：

git branch backup-20250101 git reset --hard origin/main

这样即使重置后后悔，也能通过git checkout backup-20250101找回原来的分支状态。如果连分支都没来得及建，你还有最后一道保险：

git reflog

reflog 记录了你每一次 HEAD 移动的历史，即使你连续五次reset --hard，也能在 reflog 里找到每一次移动前的 commit hash，从而恢复之前的状态。这条命令堪称 Git 世界的“后悔药”，每个人在破坏性操作之前都应该记住它。

5.2 amend 修改提交信息：什么时候不影响已经拉取的内容

搜索热词里有 “git commit --amend怎么使用”，这个命令确实值得单独说，因为它和 pull 的联动逻辑非常微妙。git commit --amend的作用是修改最近一次提交的提交信息，或者把当前暂存区的改动并入最近一次提交：

git commit --amend -m "修改后的提交信息"

关键规则是：如果你最近一次提交还没有推送到远程，那 amend 是绝对安全的操作，它只是替换本地提交记录；但如果这个提交已经推到 GitHub 或 Gitee 上，并且同事已经基于它执行过 pull，那你 amend 之后本地历史就和远程不一致了，直接 push 会被拒绝，强推又会让别人的仓库陷入混乱。

我给出的实际建议是：本地开发中最后一次提交的 message 写错了，或者发现自己漏提交了一个文件，优先用 amend 补救；一旦推送过，就老老实实再补一个新提交，不要为了“历史好看”去重写共享历史。

5.3 多人协作的 pull 纪律：先 fetch、再 rebase、最后 push

最后分享一套我在团队里推行的 pull 操作纪律，这是多次事故换来的经验。规则只有三条：拉取前先确认工作区干净；优先 fetch 看清远程变更；推代码前先整合最新远程内容。

工作区干净与否，用git status一眼就能确认。如果不想提交又舍不得丢弃，git stash是临时救场的好工具。

git fetch之后再执行git log --oneline HEAD..origin/main，可以只看“远程有而本地没有”的提交，判断这些改动会不会影响你手头的工作。

推代码前先做一次整合，我推荐在私有功能分支上使用：

git pull --rebase origin main

这样能确保你的功能分支是在最新主干基础上开发的，后续向主干合入时冲突概率大大降低。整个过程其实就一句话：让 pull 成为你每个工作流节点上的习惯动作，而不是收尾时的一次性补救。把拉取动作拔到每天的频率，你会发现自己遇到的冲突越来越温和，代码集成越来越顺。