（十二）fetch、pull 与 push 的方向

1. 先取得远程状态，再决定合入方式

假设两位同伴都从提交 P 开始。乙推送了新提交 Q，甲本地的 main 仍在 P。甲执行：

# 下载新的提交与引用信息，本地 main 和工作目录暂时不动。
git fetch origin
git log --oneline --graph --decorate --all -10
git status -sb
# 查看远程比本地多的提交，以及两份文件快照之间的差异。
git log --oneline main..origin/main
git diff main origin/main
# 本地 main 没有分叉时，把它快进到已取回的远程位置。
git merge --ff-only origin/main

fetch 之后 origin/main 从 P 更新到 Q，main 仍为 P；最后一次 merge 才让 main 与工作目录跟到 Q。git status 的 ahead、behind 数字来自本机已有的远程跟踪信息，刚才还没 fetch 时可能看不到同伴的新提交。

# 当前 main 已设置上游时，把取得信息和只接受快进的整合放在一次操作中。
git pull --ff-only

pull 包含 fetch，再按所选方式整合到当前分支。它不是“把云端文件直接覆盖下来”。--ff-only 在已经分叉时停止，保留两边原来的状态，便于接着查看差异。pull

2. 从一次推送被拒绝理解分叉

甲在 P 后增加 A，乙在 P 后增加 B 并先推送。此时远程是 P → B，甲是 P → A。甲直接 push 会遇到 non-fast-forward，因为远程 B 不包含在甲将要推送的历史里。

# 先取回 B，再看本地 A 与远程 B 的位置。
git fetch origin
git log --oneline --graph --decorate --all -10
# 在当前 main 把 B 合入，保留双方提交；需要时按冲突流程解决。
git merge origin/main -m "合并同伴更新"
python check_reading.py
git push

合并结果同时包含 A 与 B，推送才能把远程前进到这个结果。推送失败的原因也可能是仓库地址、认证或分支权限；根据错误内容分别检查，不能把所有失败都当成“需要强制推送”。