你的场景
- 本地仓库最初是从“别人的仓库 A”拉下来的（clone）。
- 之后你把默认远程改成了“你自己的仓库 B”（例如改了 origin 到你的 repo）。
- 现在“别人的仓库 A”有了新提交，你想先把这些更新合并到本地，再推到你自己的仓库 B。
这就是典型的“上游同步”流程：为上游仓库添加一个额外远程 upstream，然后定期合并/变基，再推送到自己的仓库。
一次配置，长期使用的标准做法
假设：
- 你自己的仓库（你有推送权限）作为 origin
- 别人的原始仓库作为 upstream
- 主分支为 main（如果是 master 或其他，请相应替换）
- 添加上游远程
git remote add upstream <别人的仓库A的URL>- 验证：
git remote -v应该看到 origin 和 upstream 两个远程
- 获取上游更新
git fetch upstream
- 在你的目标分支上同步上游
- 切到你的本地主分支：
git switch main
- 同步方式二选一：
- 合并（保留合并节点）
git merge upstream/main
- 变基（历史线性，常用于保持整洁）
git rebase upstream/main
- 合并（保留合并节点）
- 解决冲突（若有）
- 按文件解决冲突后：
- 变基流程：
git add <file>→git rebase --continue - 合并流程：
git add <file>→git commit完成合并提交
- 变基流程：
- 推送到你的仓库（origin）
- 若是合并：
git push origin main - 若是变基（改写了历史）：
- 首次需要安全强推：
git push --force-with-lease origin main
- 首次需要安全强推：
你的功能/改动分支也要跟上游？
如果你的改动在其他分支上，比如 feat/x：
- 先让 main 跟上游对齐（见上面步骤）。
- 再把
feat/x基于更新后的 main 同步：- 合并方式：
git switch feat/xgit merge main
- 变基方式（线性）：
git switch feat/xgit rebase main
- 合并方式：
- 解决冲突后推送到你的仓库：
- 合并：
git push origin feat/x - 变基：
git push --force-with-lease origin feat/x
- 合并：
常见问题与建议
- 避免“unrelated histories”
- 确保 upstream 指向的就是当初克隆的那个源仓库；不要把完全无关的仓库当作 upstream。
- 避免覆盖他人更新
- 强推请使用
--force-with-lease，避免误覆盖远端新提交。
- 强推请使用
- 拉取策略一致
- 喜欢线性历史：设置
git config --global pull.rebase true - 需要自动暂存未提交改动再变基：
git config --global rebase.autoStash true
- 喜欢线性历史：设置
一键回顾（常用命令串）
- 首次配置上游
git remote add upstream <上游URL>
- 每次同步更新
git fetch upstreamgit switch main- 变基版：
git rebase upstream/main；或 合并版：git merge upstream/main - 推送到自己的仓库：变基用
git push --force-with-lease, 合并用git push
如果你把 git remote -v 和分支名发我（main/master），我可以给你可直接粘贴的具体命令。