Git远程操作核心指南：从仓库连接到冲突解决-代码聚汇网

Git远程操作核心指南：从仓库连接到冲突解决

遇见高中生·2026-09-02·阅读 22 GEO检测（免费）

Git远程操作远程仓库Git pull

|难度：普通|阅读约 42 分钟

我见过太多开发者，Git 用了好几年，日常操作却始终停留在"add、commit、push 三板斧"：代码能推到远程仓库，就觉得 Git 已经会了。直到某天遇到协作冲突、push 被拒绝、分支对不上、远程仓库地址要迁移，才发现自己对 Git 远程操作的理解千疮百孔。这篇文章不打算教你背命令，而是想从"Git 远程到底在做什么"说起，把连接远程仓库、拉取、推送、分支跟踪、免密配置、报错排查这些事彻底讲透，让每个命令背后都有清晰的逻辑可依。适合刚接触 Git 不久的新手，也适合想补齐远程操作体系的老手。

先说点实际的。Git 的远程操作，本质上就是一个"本地仓库和另一个仓库（托管在 GitHub、Gitee、GitLab 或自建服务器）之间的数据同步问题"。本地和远程是两个各自独立的仓库，每一次 push 是把本地新的提交发送过去，每一次 pull / fetch 是把远程新的提交拿回来，而一切问题的根源——冲突、丢失、覆盖——几乎都出在"合并"这个环节上。搞清楚了这一点，你会发现自己不再需要死记硬背命令，而是能自然推断出该用什么操作。

1. 远程仓库的本质：它不是备份，而是协作枢纽

很多新手把远程仓库当"网盘备份"用，这其实是一个需要纠正的底层认知。远程仓库并不是本地仓库的简单镜像，它是团队协作过程中的一个共识节点，承载的核心价值是"同步与整合"，而非"存储与备份"。

1.1 remote 到底是什么：通讯录里的联系人

在 Git 中，git remote 管理的是"远程仓库的地址别名"。你可以把 origin 理解成手机通讯录里的一个联系人名字，它背后对应着的是一串真实的 URL（可以是 HTTPS 地址，也可以是 SSH 地址）。为什么非要搞个别名？因为真实地址既长又容易变，团队协作中大部分时间你根本不需要关心对方仓库长什么样，只需要一个统一的名字来指代"我们所有人都从这儿拉代码、往这儿推代码"的地方，于是约定俗成地把第一个远程仓库命名为 origin（意思是源头）。

用命令查看当前仓库配置了哪些远程地址：

bash复制git remote -v

如果克隆过仓库，你大概率会看到类似这样的输出：

bash复制origin  https://github.com/username/repo.git (fetch)
origin  https://github.com/username/repo.git (push)

注意这里出现了两行：fetch 和 push 各一行。绝大部分情况下这两行地址相同，但 Git 本身允许它们不同——比如你只从 A 地址拉取代码，却推到 B 地址，这种场景在开源贡献者身上很常见：从原仓库 clone，然后 push 到自己的 fork 仓库。

1.2 本地分支和远程分支：两个互不相干的世界

一定要理解一个容易被忽略的点：远程分支在本地视野里是以 origin/main、origin/feature/test 这样的"远程追踪分支"形式存在的。它不是你本地真实的 main 分支，而是 Git 在本地保存的一个"远程仓库状态的快照记忆"。

举个例子。你执行：

bash复制git fetch origin

这行命令做的事情，是去远程仓库把最新的提交、分支、标签信息下载到本地，并更新本地的 origin/main 这条"记忆指针"。但它完全不会动你本地正在工作的 main 分支。也就是说，fetch 只是去"看了一眼"远程的最新状态，还没发生真正的合并。

而本地分支的 main 和你看到的 origin/main，它们虽然没有血缘关系，却通过"上游分支（upstream）"建立了逻辑关联。平时我们用 git status 时看到的那行 "Your branch is ahead of 'origin/main' by 2 commits"，表达的就是你本地的 main 比远程 origin/main 多了两个提交的进度。

这里有一个非常常见的困惑：为什么有时本地显示 "ahead of 'origin/main' by 2 commits"，但 git push 后却报错？因为远程仓库可能已经被其他人 push 过新代码，你上次 fetch 时的记忆（origin/main）已经过时了，而本地在 push 时才会真正检查远程当前的状态。所以，"本地领先远程 2 个提交"只是基于你上一次 fetch 时的快照，不代表 push 一定成功。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 连接远程仓库：从 clone 到 remote add 的完整姿势

连接远程仓库有两种路径：一种是全新项目，本地已经有一堆代码，需要和远程空仓库建立关联；另一种是已在远程存在的项目，直接 clone 到本地。两种场景的操作方式截然不同，但很多新手会在第二种场景里用第一种思路，导致出问题。

2.1 全新项目关联远程仓库：核心三连

假如你在 Gitee 上建了一个空仓库，本地 D:\projects\my-app 下已经写了不少代码，想把它们推到远程。这一步的关键不是 git push，而是先建立"本地与远程的关联信息"。

bash复制# 在本地项目目录下执行
git init
git add .
git commit -m "init project"
git remote add origin https://gitee.com/username/my-app.git
git push -u origin main

逐行拆解一下里面的关键点。git remote add origin 是给远程地址起一个别名，前面说过，这只是写了一行配置记录，真正干活的是最后的 git push。而 -u 参数（--set-upstream 的简写）特别值得强调，它会在推送的同时，让本地分支 main 记住自己的上游是 origin/main。这个"记住"的动作至关重要，因为一旦记好，下次你直接敲 git push 或 git pull，Git 就知道该跟谁通信，无需再带仓库名和分支名。

2.2 clone 到底帮你做了什么：三个隐藏产出

很多人习惯用 git clone <url> 一把梭，却没意识到 clone 帮我们省掉了多少事。它不只是"把代码下载下来"，它同时完成了三件后续关联操作：

自动把远程仓库命名为 origin（默认远程名）
自动创建一个本地分支 main（或 master），并与 origin/main 建立上游跟踪关系
自动把远程仓库的所有分支状态记录到了本地（可在 git branch -r 看到）

你可以做个简单验证：clone 完成之后，直接执行 git status，通常能看到：

bash复制On branch main
Your branch is up to date with 'origin/main'.

"up to date" 这个词就来自于 clone 阶段自动建立的上游跟踪关系。所以新手完全不需要在 clone 之后再手动 add remote、也不需要手动 push -u，系统已经全部帮你铺好了路。

2.3 远程地址变更：set-url 修改而不是删了重加

切换远程地址是日常很常见的需求：仓库从 GitHub 迁移到了 Gitee、HTTP 换成 SSH、团队换了一个新的 GitLab 服务域名。面对这种情况，有些人的第一反应是：

bash复制git remote remove origin
git remote add origin <new-url>

这确实能解决问题，但如果你已经在本地配置了裸仓库的多个远程引用，或者有脚本依赖 origin 的配置，这种"删了重加"的方式很容易留下隐性问题。更优雅的做法是：

bash复制git remote set-url origin https://gitee.com/username/my-app.git
git remote -v   # 确认修改生效

set-url 只修改地址记录，不会动分支的上游跟踪关系，也不会强制清理本地已有的远程追踪分支，对整个仓库目前的状态影响最小。这也是它取代"删旧加新"成为最被推荐方案的原因。

3. fetch 与 pull：拉取过程的底层差别与选择逻辑

远程操作里最容易让人懵的就是 git pull 和 git fetch 的区别。很多人凭直觉认为 pull 等于"把远程代码下载下来"，所以 pull 就够了、fetch 是多余的。这个认知不算全错，但它掩盖了 pull 内部的复杂机制，以及这个机制带来的潜在风险。

3.1 fetch 只做一件事：更新"远程状态的本地拉面"

回到前面说的远程追踪分支概念。git fetch origin 的本质动作是：连接到远程仓库，把它最新的提交、分支、标签全部下载下来，然后更新本地的 origin/main 等远程追踪分支引用。它不碰任何工作区文件，不触发任何合并，你的本地代码一行都不会变。

这个特性带来了一个最佳实践：如果你想"只看看远程改了什么，不想马上影响本地代码"，就执行 git fetch origin，然后用下面的命令查看对比：

bash复制git log --oneline main..origin/main      # 查看远程有而本地没有的提交
git diff main origin/main                # 查看具体差异

你完全可以在不打扰自己工作区的状态下，冷静决定"这次远程改动我到底要不要合并进来"。这种"先观察、后决定"的能力，是纯用 pull 的人体会不到的。

3.2 pull = fetch + merge：一次命令背后的两个步骤

git pull origin main 会告诉你"它内部其实做了两步，先是 fetch 更新了 origin/main，然后把 origin/main 合并到了当前的 main 分支"。默认的合并方式是 merge，但如果远程历史和你本地历史已经分叉，merge 就有很大概率产生一条额外的合并提交，把提交历史搞得又乱又绕。

这正是"pull 很方便，但要小心用"的原因。它可能在你没注意的情况下，把你正在实现的半成品代码和远程的改动搅在一起，甚至引入冲突。

如果你更希望本地历史保持线性整洁，Git 提供了变基式的拉取方式：

bash复制git pull --rebase origin main

这条命令同样会 fetch，但合并机制不同：它会把本地尚未推送的提交"摘下来"放在一边，先把远程的新提交接到当前分支上，然后再把本地的提交逐个"重放"到这个新的顶端上。更准确的对比见表：

操作	步骤	历史形态	适用场景
`git pull`	fetch + merge	可能产生 merge commit	改动少、历史分叉不严重，或团队不介意合并提交
`git pull --rebase`	fetch + rebase	线性、无多余的合并提交	个人开发、代码审查严格、希望历史干净的团队

不过要提醒一点：--rebase 虽然好用，但它会重写本地提交的基础，如果本地分支已经 push 过并且被别人拉取过，尤其禁止随便 rebase，因为这会让你和别人的历史分道扬镳，造成严重的协作混乱。

3.3 拉取全部远程分支：fetch 的完整形态

默认的 git fetch origin 只会拉取当前仓库配置的远程引用。但如果你刚加入一个项目，想一次性看看远程到底有哪些分支，可以用：

bash复制git fetch --all
git branch -r   # 查看所有远程分支列表

这里要说清楚：git fetch --all 拉取的是本地已配置的多个远程（如果你有超过一个远程），并且会更新所有的远程追踪分支。但注意，它不会自动为每个远程分支创建对应的本地分支。远程分支要变成你能在上面改代码的本地分支，需要执行：

bash复制git checkout -b feature/order origin/feature/order

或更简单的版本（不同 Git 版本的语法有差异）：

bash复制git switch -c feature/order origin/feature/order

这条命令会基于远程分支创建本地分支，并立刻建立跟踪关系。搞清楚"远程分支"和"本地分支"是两套对象，很多分支操作上的迷惑就能解开。

4. push 推送实战：从首次推送到冲突处理

推送是远程操作里最让人紧张的一步，因为它的结果直接影响团队共享仓库。很多报错和焦虑都发生在 push 环节，尤其是"non-fast-forward"和"conflict"这两类问题。这一章我们逐个拆解。

4.1 首次推送：-u 参数不只是省事

第一次把本地分支推到远程时，推荐用：

bash复制git push -u origin main

这里的 -u 是 --set-upstream 的简写。它的作用我们在第 2 节提过，但这里值得再展开一下："上游跟踪关系"到底救了什么命的？

一个真实场景：你在本地创建了一个新分支 feature/login，写完代码后第一次 push。如果只执行：

bash复制git push origin feature/login

推送本身能成功，但之后你执行 git status 时看不到本地分支和远程分支的关联状态，执行 git pull 时也会提示"当前分支没有跟踪的远程分支"。而用了 -u 之后，Git 会记住 feature/login 的上游是 origin/feature/login，之后你敲 git push、git pull 都不用再指定分知名，直接默认与上游分支发生关系。省下的不光是几个字符的输入，更是那些"我明明 push 了为什么还提示 no tracking information"的困惑。

4.2 push 被拒绝：non-fast-forward 的本质

push 最常见的报错是 ! [rejected] main -> main (non-fast-forward)。很多人看到就慌了，以为是自己的代码有问题。其实它的含义非常简单：远程仓库的 main 分支已经有你本地没有的新提交，而你的本地提交不是基于远程最新的提交发展出来的。也就是说，"你推上去的代码起点"和"远程当前代码的起点"不在同一条直线上，Git 拒绝直接覆盖或合并。

这种情形发生的原因几乎只有一个——你在本地提交代码之前没有先拉取远程的新改动，或者你拉取的时间点之后，别人又 push 了新代码。

解决办法有两类：

稳妥路线：先拉取远端改动，解决可能的冲突后再推送

bash复制git pull --rebase origin main
# 如果产生冲突，先解决文件冲突，然后：
git add .
git rebase --continue
git push origin main

拉取的意义在于让本地的提交"对齐"远程新的基线。用 --rebase 而不是默认 merge 的原因，是为了避免产生不必要的合并提交，让本地历史在推送前保持线性。

冒险路线：强行覆盖远端（不推荐常规使用）

bash复制git push --force origin main

--force 能强制把本地历史覆盖到远程。这句话有一个巨大的隐患：如果远程有别人刚提交的代码，你的强推会让这些提交从远程仓库中消失。这是一件破坏性极强、几乎无法撤销的事情。在团队协作的共享分支上，请绝对不要随便执行。

如果你真的遇到了"本地已经 rebase 或整理过历史，导致 push 历史与远程不一致，但内容上又确实应该以本地为准"的场景，更稳妥的做法是用 --force-with-lease：

bash复制git push --force-with-lease origin main

--force-with-lease 会在强推之前先检查远程有没有被别人更新过。只有当远程的引用状态与你上次 fetch 时的记忆一致时，它才允许覆盖；否则会拒绝，避免你把别人新 push 的提交一把抹掉。可以说它是"有安全带的强推"，是 rebase 之后推送操作的正确打开方式。

4.3 push 冲突细节：文件冲突与推送拒绝的区别

很多人一看到"conflict"就紧张，其实要分清楚两类冲突：

推送被拒绝（rejected）：远程和本地历史分歧，尚未进入合并阶段，这是"步骤层面"的冲突。
文件冲突（conflict）：拉取或合并代码时，同一个文件的同一块区域被两个人改了，这是"内容层面"的冲突。

文件冲突解决的核心过程是：打开冲突文件，搜索 <<<<<<<、=======、>>>>>>> 标记，保留需要的部分，然后 git add 标记为已解决，再执行 git rebase --continue 或 git merge --continue。这个过程中最容易犯错的是——慌乱中使用 git add . 把所有文件都标记为解决，却没有弄清楚每个冲突部位到底该留哪段。建议案是：小冲突直接手工编辑，中大型冲突用可视化合并工具（VS Code 自带合并编辑器，或 git mergetool 配置外部工具），清晰看到"我的改动、他们的改动、最终结果"三栏。

5. 远程分支管理：查看、跟踪、清理与协作约定

远程分支操作是最能体现一个开发者 Git 熟练程度的地方。很多人只会在网页端点"新建分支"和"删除分支"，对命令行的远程分支操作一脸茫然。这一章把远程分支的生命周期打透。

5.1 查看远程分支：三个命令各司其职

bash复制git branch -r          # 列出所有远程追踪分支（远程分支在本地视野里的状态）
git branch -a          # 同时显示本地分支和远程追踪分支
git branch -vv         # 显示每个本地分支对应的"上游分支"及进度关系

git branch -vv 的输出很直观，每行会类似：

bash复制  feature/login  3f2c1a4 [origin/feature/login] 完成登录模块
  main           6b1d2e5 [origin/main] init project

方括号里的 origin/feature/login 就是本地分支所跟踪的上游分支。如果一个本地分支后面什么都没有，说明它没有设置上游——这种情况通常是手动用 git branch feat-temp 创建、从未 push 过的分支。

5.2 新建远程分支：本地 create + push 两步走

远程分支不是直接在远程"凭空生成"的，它的正确创建流程是先本地建分支，然后推送到远程。这也是"远程只是仓库不是开发环境"理念的体现。

bash复制git checkout -b feature/payment
# ... 写代码、提交 ...
git push -u origin feature/payment

push 成功后，远程仓库才会出现一个叫 feature/payment 的分支。如果你希望推送时直接指定不同的远程分支名（例如本地叫 dev，远程想叫 develop），可以：

bash复制git push origin dev:develop

这种 本地分支名:远程分支名 的语法非常强大，不只是推分支，还可以推 tags、删除远程分支（用空本地分支名）。但日常团队协作中，建议保持同名，避免"远程分支叫 A、本地分支叫 B"这种不必要的认知负担。

5.3 删除远程分支：能清早清，但要分清场景

删除远程分支的做法：

bash复制git push origin --delete feature/payment

这条命令对应的较老写法是 git push origin :feature/payment，含义就是把"空的本地分支名"推送到远程分支，等于让远程分支被清空。建议记住 --delete 这个更语义化的版本，可读性高得多。

删除远程分支是需要谨慎的操作。在团队的长期开发中，主干分支（main / master / develop）不应该被随便删除；等功能分支合并进主分支后，删除远程功能分支是降低仓库混乱度、保持分支列表整洁的好习惯。但删除前请确认分支没有被其他人还在使用，否则会导致别人本地"孤儿分支"堆积的问题。

5.4 本地删除的远程分支：远端消失后，本地怎么清理

一个高频场景：同事删除了远程分支 feature/old，但你的本地仍保留着 origin/feature/old 的远程追踪分支记录，执行 git branch -a 还能看到它。这不是 Git"幽灵分支"，只是因为本地的远程追踪引用还没有被同步清理。

要清理远程分支的"本地残留引用"，执行：

bash复制git remote prune origin

它会把远程已不存在的分支对应的本地跟踪引用删除掉。如果你每次 fetch 后想更省事地自动清理，可以用：

bash复制git fetch --prune origin

--prune 会在拉取的同时清理远程已经消失的追踪引用。团队成员多、分支迭代快的项目里，建议把 git fetch --prune 内化为日常习惯，不然本地会积累一堆过期的远程分支记忆，干扰真正的分支判断。

6. SSH 免密配置与远程操作报错排查手册

远程操作到了实际落地的时刻，最常见的痛点是"免密登录"。尤其是 HTTPS 方式 push 时每次都要输用户名密码，或者公司自建 GitLab 证书报错。问的多了，我把这块高频问题和解决方案整理成了一个完整的排查链路。

6.1 为什么选择 SSH：从密码验证到密钥对验证

HTTPS 克隆项目最简单，但每次 push 都要认证身份。虽然 Git 可以缓存凭据（Windows 上用的是 manager-core），但每一次在新机器上配置、每一次公司内部系统接入，都会遇到各种凭据管理器的配置问题。SSH 方式则用一对密钥（公钥和私钥）代替了每次输入密码，更安全也更省事。

理解 SSH 的原理其实只用一句话：你在本地生成一对密钥，公钥交给远程服务器（GitHub/GitLab/Gitee 的 SSH Keys 设置页面里添加），私钥留在本地；push 时服务器通过公钥确认你的身份是真的。

6.2 生成 SSH 密钥并配置多账号的完整套路

生成密钥：

bash复制ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

注意这里的 -C 只是一个注释标签，方便你认出这是哪台机器、哪个平台用的密钥。默认会生成 ~/.ssh/id_rsa（私钥）和 ~/.ssh/id_rsa.pub（公钥）。公钥内容需要完整复制，粘贴到 Gitee / GitHub / GitLab 的 SSH 公钥设置页面中。

验证是否连通：

bash复制ssh -T git@gitee.com

能看到 "Hi xxx! You've successfully authenticated" 就代表配置成功。

这里有个高频需求：一个人在公司 GitLab 和个人 GitHub 各有账号，如何在一台机器上共存在两对密钥？方案是：生成不同名字的密钥文件，并在 ~/.ssh/config 里配置 Host 别名。

bash复制# 生成不同平台的密钥
ssh-keygen -t rsa -b 4096 -C "work@example.com" -f ~/.ssh/id_rsa_work
ssh-keygen -t rsa -b 4096 -C "personal@example.com" -f ~/.ssh/id_rsa_personal

然后在 ~/.ssh/config 中写入：

bash复制Host gitee.com
  HostName gitee.com
  User git
  IdentityFile ~/.ssh/id_rsa_personal

Host gitlab.work.com
  HostName gitlab.work.com
  User git
  IdentityFile ~/.ssh/id_rsa_work

现在远程地址里 git@gitlab.work.com:team/project.git 这种形式的仓库，会自动通过 ~/.ssh/id_rsa_work 认证；git@gitee.com:username/repo.git 则会用个人密钥。这就是"多账号共存"最常见也最标准的方案。

6.3 常见报错排查：证书错误、认不出 git、clone 失败

很多人的远程操作不是败在 Git 命令上，而是败在环境配置和网络相关的问题上。下面是几个我高频遇见的"远程操作疑难杂症"，按出现频率排序：

问题一：Git 不是内部或外部命令（Windows）

系统提示 git : 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。这通常意味着 Git 没有安装，或者安装后没有加入 PATH 环境变量。

排查思路：重新运行 Git 安装包，在安装步骤中选择"Add to PATH"选项；或者手动把 Git 的安装目录（如 C:\Program Files\Git\cmd）加入系统环境变量 Path。装完新开一个终端窗口再试 git --version，因为环境变量修改后需要重启终端才生效。

问题二：unable to access ... error setting certificate file: d:/git/mingw64/etc/ssl/certs/ca-bundle.crt

这种报错常见于公司自建 GitLab、或 Git 安装路径有中文/空格、或证书文件损坏。报错信息里的 d:/git/mingw64/etc/ssl/certs/ca-bundle.crt 是 Git for Windows 内置的 CA 证书包路径。解决办法是重新运行 Git 安装程序修复安装，确保安装路径不包含中文和特殊字符；或者如果你能确定目标是内部信任的服务，可以用 Git 配置绕过 SSL 验证（注意仅限内网环境，不推荐公网随意关闭验证）：

bash复制git config --global http.sslVerify false

这条配置只应在特定网络环境下临时使用，公网环境建议保持默认值。

问题三：clone 时被要求输入密码但始终失败

如果你 clone 的是私有仓库，URL 是用 HTTPS 格式的，那么每次操作需要输入账号密码。如果密码中包含 @ 或特殊字符，URL 需要做转义；或者直接修改远程地址切换到 SSH 方式，一劳永逸：

bash复制git remote set-url origin git@gitee.com:username/repo.git

问题四：ssh: connect to host github.com port 22: Connection refused

某些网络环境下 22 端口被限制，SSH 连不上。可以尝试改用 SSH over 443 端口——在 ~/.ssh/config 里给 github.com 添加端口配置：

bash复制Host github.com
  HostName ssh.github.com
  Port 443
  User git

6.4 恢复已删除或误操作文件的远程操作配合

热搜里有关键词"我想把某几个文件恢复，不想更新，怎么处理"，这与远程操作也相关。从远程仓库恢复文件有两种常见场景：

还没 commit，只是想丢弃本地对某文件的修改：

bash复制git restore <file>

已经 commit 过、想从远程恢复某个文件的旧版本：

bash复制git fetch origin
git checkout origin/main -- path/to/file

这条命令会把远程 main 分支上的该文件内容覆盖到本地工作区，但不影响其他文件。它非常适合"某个文件被我改烂了，我就想把它恢复成远程的样子"的场景。恢复后记得重新提交一次，相当于生成了一个"恢复旧版本"的新提交。

7. 团队协作中的远程操作工作流建议

一个人用 Git 远距离操作，怎么爽怎么来都行。但团队协作中，远程操作的正确与否，直接关系到别人的开发体验和项目的整体稳定性。这一节总结几条"实战出真知"的协作规范，都是我踩过坑后沉淀的经验。

7.1 提交流程：先 pull --rebase，再 push

在多人协作的分支上，理想的推送前流程是：

bash复制git pull --rebase origin main
# 解决可能的冲突，测试代码可用
git push origin main

为什么强调先 rebase 再 push？因为 push 的本质是"把本地历史接到远程历史的顶部"。如果你不先拉取最新代码直接 push，极大概率遇到 non-fast-forward 拒绝。与其等 push 报错了再手忙脚乱地处理，不如在 push 前主动拉取对齐。这和"出门前检查天气预报"是一个道理，主动规避总比被动应对来得从容。

7.2 提交信息和分支命名约定：远程仓库可读性的根基

远程操作不只是命令问题，还有仓库可读性问题。一个功能分支在远程展示为 feat/user-login，另一个合并提交信息写着"fix bug"，这对于浏览历史的人来说，几乎等于没写。Git 提交信息是团队协作的公共日志，建议统一采用约定式提交规范：

bash复制feat: 为用户模块新增登录功能
fix: 修复订单列表分页失效问题
docs: 更新 README 部署说明
refactor: 重构远程克隆和认证流程

格式上是"类型 + 冒号 + 简短描述"。这样 git log --oneline 看到的信息就具备很强的可读性，远程 merge 记录里的提交也更易检索。

7.3 保护分支与 pull request：远程操作的最后一道防线

很多团队直接把 main 分支设为保护分支，禁止任何人直接 push，要求所有变更通过 Pull Request / Merge Request 合入。在这个工作流里，远程操作的核心已经不光是"怎么 push"，而是"怎么合理地发起并完成一次代码审查合入"。

对于参与开源项目的人，一个规范的远程提交流程是：

fork 主仓库到自己的账号
clone 自己的 fork 到本地
添加主仓库为第二个远程（一般命名为 upstream）：

bash复制git remote add upstream https://github.com/original/main-repo.git

日常从 upstream 拉取最新改动，提交到自己的 fork，最后在 Web 端发起 Pull Request

这个模型能最大程度避免"直接往主仓库乱推"引发的灾难，也是大型开源项目维持稳定性的基石。理解 remote add 可以添加多个远程，以及 fetch/pull 可以指定不同远程，这套上游-下游协作模式就自然通了。

我在实际带团队的过程中发现，大多数远程操作问题都不是命令复杂度的问题，而是对"本地分支和远程分支是两套独立对象"这个模型理解不到位的连锁反应。只要想清楚每一步操作分别在改本地对象还是远程对象，报错信息里的关键词（rejected、force、tracking、remote）就能瞬间定位到问题层面，修复也就自然手到擒来。

最后再分享一个小技巧：在不确定某个远程命令会带来什么影响时，先加 --dry-run 参数看看预期结果，或者用 git fetch 观察远程状态而不是直接 pull。多数远程事故，都是因为在完全没看远程状态的情况下贸然执行的。多的不说，记住一个原则——"远程操作前多看一眼，永远比操作后补救省事"。