git reflog 是唯一能查到“拉分支动作”的本地记录，需先切换到目标分支后执行 git reflog show --date=local | grep "moving from"，找到最早匹配 checkout: moving from X to Y 的行，其中 X 即源头分支，时间戳即拉取时刻；该记录仅本地存在、默认90天过期。
git reflog 是唯一能查到“拉分支动作”的本地记录
Git 本身不保存分支创建时的来源信息，git branch 或 git log 都无法还原“谁在什么时候从哪个分支拉出了当前分支”。唯一保留这个操作痕迹的，是本地的引用日志 reflog——它只存在你自己的仓库里，不会推送到远程，也不会被他人看到。
执行前必须先切换到目标分支，否则 reflog 查的是当前所在分支的历史：
git checkout your-branch-namegit reflog show --date=local | grep "moving from"
输出中类似 checkout: moving from main to your-branch-name 的行，就说明该分支是从 main 拉出来的；时间戳（如 Tue Jun 24 23:45:27 2025）就是拉取动作发生的时间。注意：如果中间执行过 git rebase 或 git merge，reflog 里可能有多条 moving from 记录，最靠近顶部（即最近一次）的那条才是真正的创建动作。
git merge-base 只能告诉你“共同祖先”，不是“源头分支”
很多人误用 git merge-base A B 来判断分支来源，但它返回的是两个分支的最近公共提交（LCA），不是创建点。比如：
- 你从
develop拉出feature/login，此时merge-base feature/login develop返回的就是那个拉取点 - 但之后如果
develop被更新、又git merge develop进feature/login，再运行merge-base就会返回一个更新后的提交，和最初拉取点不同 - 如果
feature/login还 cherry-pick 过其他分支的提交，merge-base更可能指向那个被 pick 的分支，而非原始来源
所以它适合判断“代码差异起点”，不适合回答“从哪拉的”。不要把它当分支血缘图谱用。
为什么 git log --first-parent 不可靠
git log --first-parent feature 看起来像能追溯主干路径，但它依赖合并时是否用了 --no-ff。现实中：
- 如果
git merge时没加--no-ff（默认 fast-forward），那次合并根本不会产生新 commit，--first-parent就直接跳过去了 - 如果团队习惯 squash merge 或 rebase merge，历史拓扑会被重写，
--first-parent走的路径就和实际分支创建逻辑完全脱钩 - 它对单次拉分支毫无帮助——拉分支本身不产生 commit，
log根本看不到那个动作
除非你明确控制了所有合并方式，并且只关心“主干演进”，否则别指望它告诉你分支出处。
reflog 有生命周期，不能长期依赖
reflog 默认只保留 90 天（core.refLogExpire 配置），或者 30 天未使用引用（core.refLogExpireUnreachable）。这意味着：
- 刚拉的分支，
reflog准确率接近 100% - 分支创建超过三个月，尤其如果期间没切换过、没提交过，那条
moving from记录很可能已被 Git 自动清理 -
git reflog expire --all手动触发清理后，就彻底没了
所以如果你需要长期可追溯的分支来源，唯一靠谱的做法是：拉分支时加规范 commit message（比如 [branch] create feature/x from develop@abc123），或靠 CI/CD 流水线自动记录元数据——Git 本身不提供这个能力，得靠外部约定补足。
