1. 我们有一个主分支,其中一位同事不小心添加了一系列提交(称之为
A B C
),这些提交本应属于一个新功能。
2. 我发现了这个问题,并告诉他将这些提交移动到一个新分支中,但是保留其他不相关的提交。我给他发送了这个问题,并告诉他按照回答进行操作:git:如何将分支的根节点向后移动两个提交。
3. 几天后,当新功能分支准备好后,我将其合并到主分支。
4. 在解决合并中的所有冲突后,我提交了更改......
5. ......然后我发现那些第一次提交(A B C
)已经消失了。
6. 我问我的同事,他说“他认为”他使用链接中提到的方法移动了这些更改(基本上:检查最后一个公共提交,然后使用git cherry-pick
只选择我们想要的提交),但他记不清了。
7. 我检查了仓库的历史记录,A B C
在功能分支的开头确实存在。它们似乎已经成功地从主分支迁移。鉴于上述情况,有人可以解释为什么git丢失了这些更改吗?(我的个人理论是,git某种程度上“记住”了我们撤消的提交
A B C
,因此当它们来自新的功能分支时,git决定不合并它们。编辑:很抱歉,如果这个解释听起来像是“神奇的思维”,但我还是无从下手。如果我是对的,欢迎任何试图用更技术性的术语来表达这个解释)。很抱歉不能提供更多详细信息,但我没有亲自在仓库中进行这些更改,因此无法给出确切的细节。
A - B - C - D - E - F master
\
\- G - H new feature branch
我们希望将B和C移动到新的功能分支。
因此,他发送给我的git reflog
在这里。提交5acb457
对应于上面图表中的“提交A”:
4629c88 HEAD@{59}: commit: blah
f93f3d3 HEAD@{60}: commit: blah
57b0ea7 HEAD@{61}: checkout: moving from master to feature_branch
4b39fbf HEAD@{62}: commit: Added bugfix F again
4fa21f2 HEAD@{63}: commit: undid checkouts that were in the wrong branch
1c8b2f9 HEAD@{64}: reset: moving to origin/master
5acb457 HEAD@{65}: checkout: moving from 5acb4576eca4b44e0a7574eea19cca067c039dc5 to master
5acb457 HEAD@{66}: checkout: moving from master to 5acb4576eca4b44e0a7574eea19cca067c039dc5
1c8b2f9 HEAD@{67}: checkout: moving from 1c8b2f9bf54ca1d80472c08f3ce7d9028a757985 to master
1c8b2f9 HEAD@{68}: rebase: checkout master
5acb457 HEAD@{69}: checkout: moving from master to 5acb4576eca4b44e0a7574eea19cca067c039dc5
1c8b2f9 HEAD@{70}: checkout: moving from 5acb4576eca4b44e0a7574eea19cca067c039dc5 to master
5acb457 HEAD@{71}: checkout: moving from master to 5acb4576eca4b44e0a7574eea19cca067c039dc5
1c8b2f9 HEAD@{72}: merge origin/master: Fast-forward
5acb457 HEAD@{73}: checkout: moving from master to master
5acb457 HEAD@{74}: checkout: moving from 5acb4576eca4b44e0a7574eea19cca067c039dc5 to master
5acb457 HEAD@{75}: checkout: moving from undo_branch to 5acb4576eca4b44e0a7574eea19cca067c039dc5
5acb457 HEAD@{76}: checkout: moving from master to undo_branch
1c8b2f9 HEAD@{77}: checkout: moving from undo_branch to master
525dbce HEAD@{78}: cherry-pick: Bugfix F
a1a5028 HEAD@{79}: cherry-pick: Bugfix E
32f8968 HEAD@{80}: cherry-pick: Feature C
8b003cb HEAD@{81}: cherry-pick: Feature B
5acb457 HEAD@{82}: checkout: moving from 5acb4576eca4b44e0a7574eea19cca067c039dc5 to undo_branch
5acb457 HEAD@{83}: checkout: moving from master to 5acb4576eca4b44e0a7574eea19cca067c039dc5
1c8b2f9 HEAD@{84}: checkout: moving from 1c8b2f9bf54ca1d80472c08f3ce7d9028a757985 to master
1c8b2f9 HEAD@{85}: pull origin HEAD:master: Fast-forward
5acb457 HEAD@{86}: checkout: moving from master to 5acb4576eca4b44e0a7574eea19cca067c039dc5
5acb457 HEAD@{87}: reset: moving to 5acb4576eca4b44e0a7574eea19cca067c039dc5
1c8b2f9 HEAD@{88}: merge origin/master: Fast-forward
5acb457 HEAD@{89}: reset: moving to 5acb4576eca4b44e0a7574eea19cca067c039dc5
1c8b2f9 HEAD@{90}: checkout: moving from 5acb4576eca4b44e0a7574eea19cca067c039dc5 to master
5acb457 HEAD@{91}: checkout: moving from master to 5acb4576eca4b44e0a7574eea19cca067c039dc5
1c8b2f9 HEAD@{92}: merge origin/master: Merge made by the 'recursive' strategy.
7b912cd HEAD@{93}: checkout: moving from 7b912cdf33843d28dd4a7b28b37b5edbe11cf3b9 to master
7b912cd HEAD@{94}: cherry-pick: Bugfix F
df7a9cd HEAD@{95}: cherry-pick: Bugfix E
d4d0e41 HEAD@{96}: cherry-pick: Feature C
701c8cc HEAD@{97}: cherry-pick: Feature B
5acb457 HEAD@{98}: checkout: moving from master to 5acb4576eca4b44e0a7574eea19cca067c039dc5
22ecc3a HEAD@{99}: checkout: moving from 5acb4576eca4b44e0a7574eea19cca067c039dc5 to master
5acb457 HEAD@{100}: checkout: moving from master to 5acb4576eca4b44e0a7574eea19cca067c039dc5
22ecc3a HEAD@{101}: commit: bugfix E
3b568bc HEAD@{102}: checkout: moving from feature_branch to master
57b0ea7 HEAD@{103}: commit: blah
152c5b9 HEAD@{104}: checkout: moving from master to feature_branch
3b568bc HEAD@{105}: commit: bugfix D
fe3bbce HEAD@{106}: checkout: moving from feature_branch to master
152c5b9 HEAD@{107}: commit: blah
2318ebc HEAD@{108}: commit: blah
cc5ea32 HEAD@{109}: commit: blah
a5c2303 HEAD@{110}: commit: blah
544a99a HEAD@{111}: commit: blah
299f86a HEAD@{112}: commit: Feature G
fe3bbce HEAD@{113}: checkout: moving from master to feature_branch
fe3bbce HEAD@{114}: commit: Feature C
3852e71 HEAD@{115}: commit: Feature B
5acb457 HEAD@{116}: merge origin/master: Fast-forward
有人能理解连续四个 cherry-pick
吗?我怀疑他并没有真正执行 git cherry-pick master~3
,特别是其中的 ~3
部分(当我第一次看到它时也让我感到困惑)。
git reflog
命令,就可以告诉你是否是这种情况...但如果是这样,那么特性分支中也不应该有A B C。如果你仍然拥有特性分支,你能检查一下吗? - user743382git reflog
来查看丢失的提交。这将给您提供一个带有提交哈希的提交历史记录。然后找到引用您想要获取的提交的行。 - pRaNaYgit checkout
合并提交时获得的树相关之外,历史记录中有哪些提交并不重要。 - torek