git merge 应切到目标分支，如将 feature 合入 develop 需先 checkout develop 再 merge feature；误在 feature 上 merge develop 会反向污染历史，可用 git reset --hard HEAD~1 回退（未推送时）。
git merge 时该切到哪个分支
同步的本质是把一个分支的提交“应用”到另一个分支上，git merge 操作永远发生在**目标分支**上。比如要把 feature/login 的改动同步进 develop，你必须先 git checkout develop（或 git switch develop），再执行 git merge feature/login。
常见错误是人在 feature/login 分支却执行 git merge develop，结果是把 develop 合进了功能分支——这通常不是你想要的同步方向，反而可能污染功能分支的提交历史。
- 想“把 A 同步给 B” → 切到 B，再
merge A - IDEA 里右键 Merge，弹窗选的是“要合并进来的分支”，不是“当前分支”
- 如果误操作了，可以用
git reset --hard HEAD~1回退最后一次合并（仅限未推送）
同步前要不要先 git pull？
要看目标分支是否关联了远程跟踪分支。如果你在 develop 上执行 git merge feature/login，而 develop 已通过 git push -u origin develop 建立了跟踪关系，那它本地可能已落后远程 —— 此时直接 merge，会导致你的本地 develop 缺少别人刚合入的提交，后续 git push 会失败（提示需要先 pull）。
更稳妥的做法是：在切换到目标分支后，先 git fetch origin 查看差异，再决定是否 git merge origin/develop 或 git rebase origin/develop 同步远程最新状态。
- 用
git branch -vv看当前分支是否显示[origin/xxx]，有才是已跟踪 -
git status -uno能快速告诉你本地分支比远程多/少几个 commit - 不建议无脑
git pull，它会自动 merge，可能引入你不想要的中间提交
用 git rebase 还是 git merge 同步
两者都能把提交搬过去，但效果完全不同：merge 保留原始提交时间线，生成一个合并提交；rebase 是把你的提交“重放”到目标分支最新提交之后，历史变成线性。
团队协作中，对共享分支（如 develop、main）应只用 merge；rebase 适合在你自己的功能分支上整理提交，或者在 push 前把本地分支“拉直”。一旦你的分支已推送到远程并被他人基于它开发，就绝对不要 rebase 后强制推送（git push --force-with-lease）。
- 同步到公共分支 → 用
git merge - 同步自己分支并想保持干净历史 → 可用
git rebase，但确保没人基于你旧提交工作 -
rebase后如果遇到冲突，解决后用git add . && git rebase --continue，不是commit
同步后为什么 git push 失败？
最常见原因是远程分支已有新提交，而你的本地没有包含它们。Git 拒绝非快进（non-fast-forward）推送，防止覆盖他人工作。
此时不能直接 --force，先 git fetch origin，再判断：如果只是远程多了几个无关提交，可 git merge origin/develop；如果想保持线性，且确认安全，才考虑 git rebase origin/develop。
- 错误信息通常是
! [rejected] develop -> develop (non-fast-forward) -
git log --oneline --graph --all --decorate能直观看出分支分叉情况 - 多人同时向同一分支推送时，这个失败是正常保护机制，不是操作失误
git branch -vv 和 git log --graph。 
