- 已经会基本提交和分支操作的开发者
- 想理解命令边界与风险的人
Command Reference
git push 教程
说明 git push 如何发布本地分支、建立上游跟踪关系，以及怎样判断一次 push 是安全发布还是高风险改写。
- 知道工作区、暂存区、提交的基本关系
- 能读懂 `git status` 和简单历史图
- 误把本地整理命令用到共享历史
- 在没确认恢复路径前直接继续改写历史
一句话理解
git push 会把本地的引用和对象发送到远端，让其他人或其他系统看到新的历史。
一旦 push，原本只是你本地的历史，就可能进入评审、CI、部署或别人的分支基线。所以 push 的风险往往来自协作影响，而不只是命令本身。
它真正改变了什么
很多人谈 push 时，只想到：
- 认证有没有过
- 命令能不能成功
更重要的问题其实是：
我现在要更新的是哪一个共享引用？
这决定了一次 push 是：
- 普通发布个人功能分支
- 更新评审分支
- 还是在高风险地改写共享历史
常见写法
git push origin main
git push -u origin feature/login
git push --force-with-lease
git push origin main：更新指定远端分支git push -u origin feature/login：首次发布并建立上游跟踪关系git push --force-with-lease：仅在远端仍处于你预期状态时，才允许重写
-u 为什么有价值
第一次发布分支时设好 upstream，后面这些命令都会更顺：
git pushgit pullgit status
尤其是功能分支较多时，它能减少很多机械成本。
更稳的 push 前检查
在 push 前，至少先问自己：
- 目标远端和目标分支写对了吗？
- 这个分支是个人分支、评审分支，还是共享主分支？
- 这次是在发布新提交，还是在改写旧历史？
- 本地历史和工作区状态是不是已经如你所想？
一个很实用的预检查是：
git status
git log --oneline --graph --decorate -8
git remote -v
为什么更推荐 --force-with-lease
确实存在需要重写远端历史的情况：
- 整理自己的功能分支
- 在 merge 前清理 review 分支历史
- 修正一条刚 push 错但别人还没基于它工作的记录
但裸 --force 完全不管远端这段时间有没有发生变化。
--force-with-lease 更安全，因为它表达的是：
“只有远端还停在我预期的位置时，才允许我改写它。”
只要真的需要改写已发布历史，--force-with-lease 应该是第一反应。裸 --force 应该是极少数特例。
图例理解
本地分支头远端分支头远端策略
已发布的提交更新后的上游引用被保护策略拒绝
push 最重要的问题不是“是否成功”，而是“我发布出去的历史是不是正是我想发布的那段”。
常见错误
- 因为默认叫
origin就没再确认目标远端 - 本地历史还很乱，就太早 push 到远端
- 同事已经基于这个分支开发了，仍然去改写它
- 用 force 掩盖本地分支整理不到位的问题
只要目标分支已经被同事、CI 或部署使用，push 就不再只是你的本地动作，而是团队协作的一部分。
跟着做一遍
目标是区分“第一次发布”“普通更新”和“历史改写”三种完全不同的 push 语义。
git switch -c lab/push-demo # 先创建一到两个本地提交动手试
- 在一个实验分支上运行 `git push -u origin lab/push-demo`。
- 观察 `git status`，看 upstream 关系如何变化。
- 再新增一个提交，重新执行 `git push`。
- 然后思考：如果你在第二次 push 前重写了本地历史，会发生什么变化？
- 你会理解首次发布和后续更新的区别。
- 会看到 upstream 关系如何让日常同步更顺。
- 也会更容易判断什么时候一次 push 已经变成“改写远端历史”的决定。
- 多远端场景下，push 前要确认 remote 和 branch。
- 如果 push 被拒绝，先判断是认证、保护策略还是 non-fast-forward。
- 不要用 force 掩盖本地历史还没整理清楚的问题。