重命名分支后新建同名分支，为何出现原分支的提交？

这种情况其实挺常见的，大概率是你创建新emcee分支时不小心基于旧emcee_old分支（或和旧分支有历史关联的节点）初始化的，而非完全从develop的目标节点干净拉取。下面给你一步步排查和解决的方案：

第一步：确认分支的历史关联 #

先运行这条命令，用图形化方式对比三个分支的提交链，直观查看新emcee是否和emcee_old有历史交集：

git log --oneline --graph emcee develop emcee_old

如果新emcee的提交链里混着emcee_old的记录，那就能确定是创建分支时的基础选错了。

第二步：重新创建干净的emcee分支（无本地修改时） #

如果新emcee还没推送到远程，或者远程修改可以覆盖，直接重建是最省事的：

1. 先切换到安全分支（比如develop）：

git checkout develop

2. 删除本地有问题的emcee分支：

git branch -D emcee

3. 从develop的目标节点创建新分支（用最新节点就写develop，指定旧节点就替换成对应commit哈希）：

git checkout -b emcee <目标commit哈希或develop>

这样创建的分支只会包含develop目标节点及之前的提交，不会带emcee_old的历史。

第三步：保留本地修改后重建分支 #

要是你已经在新emcee上做了修改不想丢，可以先暂存修改再操作：

1. 暂存当前分支的所有修改：

git stash

2. 按照第二步的流程删除旧emcee分支，创建干净的新分支
3. 恢复暂存的修改到新分支：

git stash pop

之后解决可能出现的冲突，提交即可。

第四步：同步远程分支（已推送远程时） #

如果已经把问题分支推到远程，还要同步远程端：

1. 本地处理好干净的emcee分支后，强制推送到远程（注意：会覆盖远程分支，先确认团队没人在上面做修改）：

git push origin emcee --force

2. 通知团队成员更新本地分支：

git fetch origin
git checkout emcee
git reset --hard origin/emcee

为啥会出现这种“奇怪”现象？ #

Git的分支本质是提交链的指针，创建分支时如果没明确指定基础分支/节点，Git会默认用当前所在分支的最新提交作为基础。比如你重命名emcee为emcee_old后，可能还停留在emcee_old分支上，直接运行git checkout -b emcee，新分支自然就继承了旧分支的所有历史——这就是.gitignore会出现旧提交记录的原因，它本来就是旧分支历史里的文件。

内容的提问来源于stack exchange，提问作者Gabriel