我的同事做了一系列粗心的拉/推操作。他最终陷入了他的本地提交失踪的境地
我使用git reflog
恢复了他的提交。但我无法弄清楚为什么他的行动会导致这种情况。有人可以点灯吗?
请参阅下面的git reflog
输出和评论:
#######
# reflog is in reverse manner, most recent operation first
# test is like our "develop" branch, MTX-65 is the feature branch
# Both are remote-tracking
#######
39261b7 (HEAD -> MTX-65, origin/feature/MTX-65) HEAD@{0}: checkout: moving from test to MTX-65
7f66c72 (test) HEAD@{1}: checkout: moving from MTX-65 to test
39261b7 (HEAD -> MTX-65, origin/feature/MTX-65) HEAD@{2}: pull: Fast-forward
d51c1be HEAD@{3}: rebase finished: returning to refs/heads/MTX-65
d51c1be HEAD@{4}: rebase: Add Notification
c33d31f HEAD@{5}: pull --tags -r origin feature/MTX-65: checkout c33d31f4d0109396dea6d6bb78f47ba56097e4ac
#######
# This is the key commit that got lost
# It's not in `git log` out any more
#######
a6a7a7e HEAD@{6}: commit (merge): Warning message
3c8113c HEAD@{7}: commit (amend): Add Notification
7f551e4 HEAD@{8}: commit: Add Notification
96bcf99 HEAD@{9}: pull --tags -r origin feature/MTX-65: Fast-forward
b79bee0 HEAD@{10}: commit: personal & institution page
3cfb1aa HEAD@{11}: commit: Institution:
7f66c72 (test) HEAD@{12}: checkout: moving from test to MTX-65
7f66c72 (test) HEAD@{13}: merge MTX-65: Fast-forward
0733fd2 HEAD@{14}: checkout: moving from MTX-65 to test
7f66c72 (test) HEAD@{15}: commit (merge): Merge test
ebfaeea HEAD@{16}: checkout: moving from test to MTX-65
0733fd2 HEAD@{17}: pull: Fast-forward
1043c35 HEAD@{18}: checkout: moving from MTX-65 to test
#######
# This is a commit that still exists after the disaster
#######
ebfaeea HEAD@{19}: commit: institution 认证信息
我们来看看a6a7a7e HEAD@{6}: commit (merge): Warning message
。
commit (merge)
表示合并遭遇冲突。解决冲突后,您的同事会将默认提交消息更改为Warning message
。默认消息类似于Merge made by the 'recursive' strategy
。
然后你的同事跑git pull --tags -r origin feature/MTX-65
。使用-r
,在取出完成后使用git rebase
而不是git merge
。
正如manual所说,
默认情况下,rebase将简单地从todo列表中删除合并提交,并将重新提交的提交放入单个线性分支中。
关于哪个更好,git merge
或git rebase
有很多争论。 git rebase
的一个优点是我们可以用它以方便的方式创建线性历史。按照设计,默认情况下会删除合并提交,尽管git rebase
在某些情况下提供-r
和-p
以保留它们。
在git rebase
期间,预计冲突将再次发生。从理论上讲,如果你的同事以与之前的git merge
相同的方式解决这些变化,那么这些变化就不会丢失。您可以尝试使用git log --reflog -S <keywords> -p
来查找包含关键字的更改丢失的提交。