Question

它总是在工作中发生，有人意外地将某些东西提交到主人而不是预期的功能分支，然后该人试图解决它，只是让更改突然消失。我搜索得很厚实，没有文件可以说明为什么会这样，或者如何纠正这种情况。

以下是重现的步骤：

$ git init
$ echo hello world > testfile
$ git add testfile
$ git commit -m 'init'
$ git branch A
$ echo abc >> testfile
$ git commit -am 'append abc'
$ git revert HEAD --no-edit
$ git checkout A
$ echo fff > secondfile
$ git add secondfile
$ git commit -m 'Add second file'
$ git cherry-pick master^

此时git的历史记录如下：

$ git log --oneline --all --graph --decorate
* ac6f9b4 (HEAD -> A) append abc
* 54be952 Add second file
| * 9ba1f16 (master) Revert "append abc"
| * ef7c8d6 append abc
|/  
* 65a885d init

注意当我在主服务器上重新分支A时会发生什么：

$ git rebase master
$ git log --oneline --all --graph --decorate
* 9d08739 (HEAD -> A) Add second file
* 9ba1f16 (master) Revert "append abc"
* ef7c8d6 append abc
* 65a885d init

在A的头部，提交ac6f9b4的提交发生了什么？它去了哪里？为什么不重新申请？

虽然这只是一个小例子，最后只丢失了一个提交，但有时我们最终会从一个长提交链的中间丢失几个提交，然后它们看起来几乎看不见：（

Answer 1

Rebase不会重新应用已在新基础中应用的提交 - 此处为append abc更改。它已经在主历史中了。这通常是正确的，git没有评论这样做。在随后的回复中，它至少值得一提。

要查看您重新定位的内容是否已经成为新基本历史记录（master，此处）的一部分，

git log --oneline --cherry ...master

并查找= - 标记的提交。这些是master中的提交，与你的分支中的提交相匹配; rebase不会重新申请。为master...交换...master以查看当地的等效内容。

如果你想要一个有效的盲法基础，第一次切割是

git checkout -B A master
git cherry-pick ..A@{1}      # < added the very important `..` by edit

只是将A移动到主人身上然后挑选你留下的所有东西。要忽略合并（你可能应该这样做），将--no-merges添加到樱桃选择中，当你问樱桃选择系列时它会将整个集合传递给git rev-list，这样你就可以使用机械直接：

git cherry-pick --no-merges ..A@{1}  # just learned now that cherry-pick takes this

缺少git提交

1 个答案: