Git学习日志——为什么你的分支会莫名出现别的分支的提交
笔者之前做项目的时候，曾经被CR道：你的这次提交混入了之前的其他bug fix的提交了，处理一下。当你在 Git 里看到「我没 merge、没 rebase，为什么分支里却出现了别处的 commit？」时，你并不孤单。这个问题既常见又容易修复 —— 关键是理解：分支就是一个指针，永远从当前的HEAD开始。
TL;DR
**新分支从当前HEAD创建；如果 HEAD 本身包含了别的分支的提交，新分支也会带上它们。**一个最简单的办法就是如果没有特殊要求，永远从最新的基准线拉分支出来
直观理解
想象 Git 是家谱：每个 commit 是“一个人”，分支是“出生地点”。你在哪里出生（HEAD），你的整个家族链就是什么。
如果你以为你在“爸爸（main）”那儿出生，但实际上你在“叔叔（dev）”那儿开始——那当然会“带着叔叔的血统”。
ASCII 图示（示例）：
A --- B --- C --- D (main) \ E --- F (dev) \ G --- H (feature) <-- 从 dev 或 D 创建，可能带 E/F/D常见原因（为什么会出现别的 commit，且你可能没察觉）
- 创建分支时 HEAD 在错误分支/commit（最常见）
- 忘记
git switch main，直接git switch -c feature。
- 忘记
- 你执行过
git pull（默认是 fetch + merge），把远端的 commit 合入了本地分支。 - 你在某分支做了提交、amend 或 reset，改变历史后又开分支（历史改写导致“看起来是前面的提交”）。
- 本地 main 落后于 origin/main，你从本地落后的 main 开分支。
- 分支 fast-forward 或被别人合并到 main，然后你从该分支再开分支。
- IDE/工具的自动操作（auto stash / auto rebase / auto merge）在背后帮你做了改写/合并。
关键结论：完全可以不触发显式
merge/rebase，也能把别处的 commit 带过来 —— 因为你站在包含它们的位置开了分支。
如何复现（在本地做实验，理解会更深刻）
把下面脚本复制到临时目录运行（或逐条执行），每个场景都有注释。
场景 A：在错误分支上创建新分支（最常见）
gitinit demo-mix&&cddemo-mixechoA>file&&gitadd.&&gitcommit -m"A"echoB>file&&gitcommit -am"B"gitbranch devgitswitch devechoC>file&&gitcommit -am"C"# dev 上有 C# 忘记切回 main，直接创建 featuregitswitch -c featuregitlog --oneline --graph --decorate# 你会看到 C 出现在 feature 上场景 B：本地 main 落后，从落后版本开分支
# 模拟远端和本地（简化版）# 在远程仓库里已有额外 commit（这里直接在本地把 main 往前 reset 来模拟）gitswitch mainechoX>file&&gitcommit -am"X"# 假设远端比本地多了 C、D（现实中是别的协作产生的）# 你没拉取就开分支gitswitch -c feature-from-old-main# 以后 pull/fetch 时你会发现远端的 C/D 跑进来并改变预期场景 C：amend / reset 后开分支（历史改写导致）
gitswitch -c branch1echoB>file&&gitcommit -am"B"gitcommit --amend -m"B (amended)"# 改写 branch1 历史gitswitch maingitswitch -c featuregitlog --oneline --graph# 可能看到被 amended 的提交出现在 feature修复方法（按场景分：选择最适合你的）
警告（重要）：任何改写历史的操作（
reset --hard,rebase,push --force）在共享分支上必须小心。改写别人可能基于的历史会引起冲突。已 push 的改动要在团队里协调后再强推。
场景：我想保留自己的提交，把多出的其他提交去掉
工具：git rebase --onto（最干净）
假设你当前分支feature历史如下，你要把 F,G,H 接到 C 后面（去掉 D、E）：
A - B - C - D - E (main) \ F - G - H (feature)命令（假设你知道正确基点C的 hash 或分支名）：
gitswitch featuregitrebase --onto<C><D>feature# 例如： git rebase --onto C D feature效果：把 F/G/H“剪”下来，接到 C 后面。
场景：分支很短，想简单处理 —— 重新创建并 cherry-pick
gitswitch maingitpull --ff-onlygitswitch -c feature-cleangitcherry-pick<hash-of-your-commit-1>gitcherry-pick<hash-of-your-commit-2># 如果冲突，按提示解决适合更改不多时用，最保守。
场景：刚做了 merge，但还没 push，想撤销 merge
# 回到 merge 之前的 commit（确保你知道要回退到哪个）gitreset --hard<commit-before-merge>仅当未 push 到远端或确定没人依赖时使用。
场景：已经 push 到远端，需要删除特定提交（慎用）
- 使用
git rebase -i <base>在本地把多余的 commitdrop掉。 - 强推到远端（通知团队）：
gitpush --force-with-lease origin feature--force-with-lease比--force更安全，它会在远端有人更新时拒绝强推。
场景：不知道基点或不确定，先看历史
gitlog --graph --oneline --decorate --allgitreflog# 查看最近 HEAD/checkout 的历史，帮助找到正确点那怎么做就不会遇到这类麻烦呢？
把这 5 步写在贴纸上，每次开分支都按顺序来：
# 推荐的 5 步严格开分支流程gitswitch maingitfetch --allgitpull --ff-onlygitstatus# 确认 On branch main & working tree cleangitswitch -c feature/xxx额外规则（强化）
- 在团队中统一约定：feature 分支必须从最新的 main 创建；CI 检查分支基点（可选）。
- 避免在还没推到远端的分支上使用
commit --amend,rebase -i（或在改写历史前通知团队）。 - 已 push 的公共分支不要强制改写历史；私人分支可以随意改写。
快速备忘 Cheat-Sheet（常用命令与用途）
检查历史（图形化）
gitlog --graph --oneline --decorate --all找到最近 HEAD 操作
gitreflog从正确基点把你的提交剪到新位置（去掉中间的别的 commit）
gitrebase --onto<new-base><old-base><branch>交互式清理提交（drop / squash / reorder）
gitrebase -i<base>重新从正确基点 cherry-pick（最保守）
gitswitch maingitpull --ff-onlygitswitch -c feature-cleangitcherry-pick<commit1><commit2>...撤销最近一次合并（如果未 push）
gitreset --hard<commit-before-merge>强推（仅在协调后）
gitpush --force-with-lease origin feature
故障排查清单（当你遇到“莫名 commit”时照着做）
- 先别慌，别立刻
push --force。 git log --graph --oneline --decorate --all，看是哪条线把那些 commit 带进来的。git reflog看最近你都做了哪些 checkout / reset / amend。- 确认是否有人在远端把某个分支合并到 main（
git fetch+git log origin/main）。 - 根据你的目标（保留你 commit / 重新建分支 / 回退 merge）选择上面的修复方法。
- 如果要改写远端历史，先告知团队并使用
--force-with-lease。
