远程仓库同步
远程命令用于把本地仓库和远程仓库连接起来，并同步对象与引用。最常见的远程名是 origin，但它只是本地配置名，不等于服务器本身。本页先提供命令参考，随后用 远程协作心智模型与离线实验 把概念串起来。
任何远程写操作前的安全门
git rev-parse --show-toplevel
git status --short --branch
git branch --show-current
git branch -vv
git remote
git log --oneline --decorate -5解释仓库根、当前分支、upstream、remote 名与待推提交后，才考虑 push 或 pull。git remote -v、.git/config 和完整 config 输出可能暴露错误嵌入 URL 的凭据；不要把 token 放进 URL，也不要把未脱敏输出粘贴到笔记、日志或工单。
git remote add <name> <url>
git remote add origin https://github.com/example/project.git用途：给当前本地仓库添加一个远程仓库地址。
先验证 remote 名：
git remote如必须检查 URL，可在本机运行 git remote get-url origin，先确认不含 userinfo、token 或私人服务器细节，再决定是否记录输出。
说明：
<name>通常叫origin，但也可以叫upstream或其他名字。- 一个仓库可以配置多个 remote。
git push origin main
git push origin main用途：把本地 main 分支推送到名为 origin 的远程仓库。
适用场景：
- 本地已有提交，需要同步到远程主分支。
- 第一次推送某个明确分支时，想指定 remote 和 branch。
注意：如果远程分支有你本地没有的提交，push 可能被拒绝，需要先 fetch/pull 再处理。
git push
git push用途：按当前仓库的 push 配置推送引用。常见 push.default=simple 下，裸 git push 会推当前分支到对应 upstream；push.default、remote.*.push 等配置可以改变推送集合，不能只凭记忆判断。
适用场景：
- 当前分支已经用
-u设置过跟踪关系。 - 日常开发中提交后同步当前分支。
检查 upstream：
git branch -vvgit push -u origin <name>
git push -u origin feature/demo用途：把当前或指定本地分支首次推送到远程，并设置 upstream。
适用场景：
- 新建功能分支后第一次推送。
- 希望以后直接用
git push和git pull。
示例：
git push -u origin docs/git-cheat-sheetgit push --force-with-lease
git push --force-with-lease origin feature/demo这是语法参考，不是初学练习。用途：在本地改写历史后，用带保护检查的方式强制推送。
适用场景：
- 本地 rebase、amend 或 squash 后，需要更新远程同名分支。
- 确认远程分支没有被其他人新增提交覆盖。
仍然是历史改写
--force-with-lease仍然是强推，不是并发安全保证。省略显式期望值时，它通常依赖本地 remote-tracking ref；IDE 或后台 fetch 可能更新该 ref，削弱保护。高风险场景要限定 remote、分支与期望对象 ID，并遵守团队流程；初学项目和共享主分支不练强推。
git push --tags
git push --tags用途：把本地 tag 推送到远程。
适用场景：
- 发布版本后创建了 tag，需要同步到远程。
常见补充：
git tag
git tag v1.0.0
git push origin v1.0.0如果只推一个 tag，优先显式写 tag 名，避免一次推送所有本地 tag。
git fetch origin
git fetch origin用途：从远程获取 main 的最新提交和引用信息，但不直接修改当前本地分支。
适用场景：
- 想先看看远程变了什么，再决定 merge 或 rebase。
- 不希望
pull自动修改当前工作分支。
后续检查：
git log --oneline HEAD..origin/main
git diff HEAD...origin/maingit pull --rebase
git pull --rebase用途：先 fetch 远程更新，再把当前本地提交 replay 到远程最新提交之上。
适用场景：
- 保持线性历史。
- 功能分支想跟上远程分支，同时避免生成 merge commit。
注意：
- rebase 期间可能产生冲突，需要解决后继续：
git rebase --continue如果发现基线或处理方向错误：
git rebase --abort明确选择 pull 的整合方式
git pull --ff-only
git pull --rebase
git pull --no-rebasegit pull 先 fetch，再按显式选项或配置整合：
--ff-only：只允许 fast-forward，历史已经分叉就拒绝。--rebase：把本地提交重新生成到已获取基线之上。--no-rebase：明确请求 merge。
Git 2.55 文档把“未选择整合方式”时的默认行为定义为 --ff-only，但仓库或用户配置可以选择 rebase、merge 或 squash。自动化和教学命令应显式写出意图，不要声称裸 pull 必然 merge。
注意：pull 的整合阶段会改当前分支和工作树。若只是查看远程变化，先用 git fetch 更稳。
认证与练习边界
Git for Windows 可配合 Git Credential Manager；不同托管平台可能使用 OAuth、PAT 或 SSH key。不要使用账户密码或 token 拼进 URL 的做法，按平台官方认证文档配置。本文中的 example/project.git 是虚构地址，不执行网络验证。
无需账户的完整练习见 远程协作与离线双克隆实验。它使用本地 bare remote 和两个临时 clone，不接触真实凭据或线上仓库。
参考资料
按 Git 2.55.0 官方文档核验，获取日期：2026-07-14。