提交显示在历史记录中,更改不在文件中,也不显示在单个文件提交历史记录中

Mad*_*bat 10 git merge github

我刚刚和git有一个非常奇怪的问题.昨天我推了一个提交,之后有几个人推了推.现在我可以在github上看到我在历史记录中的提交,但是我所做的更改不在文件的HEAD修订版中,如果我查看单个文件的历史记录,我的提交不会显示.我的队友告诉我,他们所做的只是经常拉动和推动.与我更改的文件没有冲突.如果有人使用强制推动,我希望我的承诺完全消失.如果有人搞砸了合并冲突,我希望合并提交撤消我的更改并反映在文件的提交历史记录中.但不知怎的,情况也不是这样.简化:

  • 我更改了file.txt并生成了提交ABCD
  • 我把ABCD推到了github
  • 其他人推送其他提交,不影响file.txt
  • 如果我在github上查看存储库提交,我会看到我的提交,我可以提取更改差异
  • 如果我在github上查看file.txt的最新版本,我的更改就不存在了
  • 如果我查看file.txt的提交历史记录,ABCD没有显示,那么该文件的最后一次提交就是ABCD之前的提交.

这样的事情怎么样?

编辑:在评论中的每个讨论中,这是我的提交图的一部分

* | 8c1d372 ...
* |   98dbad7 Merge branch 'master'
|\ \  
| * | 8d64a09 ...
| * | 12beb68 ...
| * |   1c94b6d Merge branch 'master'
| |\ \  
| | * | 80b6285 ...
| | * | 9781fad ...
| | * | f12fc90 ...
| | * | 61411fa ...
| | * | 291333b ...
| * | | aeee93f ...
| |/ /  
| * |   bcfbf65 Merge branch 'master'

我失踪的承诺是9781fad.如果我结账8c1d372,我的更改就会消失.然而,我之后的任何提交都不会影响我更改的文件.

tor*_*rek 11

实际答案(而不是超长评论).

这是图形位,再加上我自己的注释:

* | 8c1d372 ...        <-- lacks desired changes
* |   98dbad7 Merge branch 'master'     <-- ? (interesting #1)
|\ \  
| * | 8d64a09 ...
| * | 12beb68 ...
| * |   1c94b6d Merge branch 'master'   <-- ? (interesting #2)
| |\ \  
| | * | 80b6285 ...    <-- probably also has desired changes
| | * | 9781fad ...    <-- is commit that makes desired changes
| | * | f12fc90 ...
| | * | 61411fa ...
| | * | 291333b ...
| * | | aeee93f ...
| |/ /  
| * |   bcfbf65 Merge branch 'master'
Run Code Online (Sandbox Code Playgroud)

由于没有人明确地恢复你的更改,并且他们是一个文件没有其他人应该编辑,几乎可以肯定,谁丢失你的更改,通过做一个糟糕的合并这样做.

有两个有趣的合并,我已经标记过了.#1,commit 98dbad7,有两个父母:一个我们看不到(在图的底部),一个我们可以,8d64a09.git log从这一点开始,A 将显示这两个历史. git show 98dbad7:path/to/file将显示附加到合并提交的文件的版本(即,无论谁做了合并,表示该文件的正确版本).如果这是错误的版本 - 如果该文件缺少所需的更改 - 则合并本身变坏或输入错误.据推测,父母 - 这个底线不应该有变化,所以在这一点上我们应该跟随另一个父母,即8d64a09.

您可以git show 8d64a09:path/to/file查看该版本是否包含或缺少您的更改.如果您的更改在那里,那么98dbad7删除它们的是提交.如果您的更改不在那里,我们应该继续.

为了完整性,我们可以看一下12beb68,但它可能不是罪魁祸首.这是一个父母的普通提交1c94b6d.

Commit 1c94b6d是我们第二次有趣的合并.与任何合并一样,它有两个(或更多,但通常是两个)父母.这次我们可以看到两者,它们都是提交80b6285aeee93f.

提交80b6285可能有更改,因为它是一个普通提交其母公司9781fad,你的改动提交.并且提交aeee93f将不会有您的更改,因为它来自合并方面,嗯,没有您的更改.:-)你可以git show 80b6285:path/to/file只检查那个提交的人是不是秘密地(而不是公开地)将它们还原,然后git show 1c94b6d:path/to/file观察是否这个有趣的 - 合并 - #2放弃了你的改变.

很可能这些合并中的一个放弃了您的更改. 为什么仍然是一个有趣的问题,但必须由进行合并的人来回答.他们做了一些事情 - 也许是结账,也许是合并的标志 - 在合并期间放弃了你的变化.找出哪个合并删除了更改,并与谁做了什么,以找出他们做了什么放弃了他们.

获得更改

将更改带回来真的很容易:只使用git cherry-pick,为您运行差异,然后将该差异应用于当前提交.所以,你会回来到master,简单git cherry-pick 9781fad.这将diff 9781fad^(9781fad's的父级,这是f12fc90)9781fad-a差异显示您的更改 - 并将它们应用于当前提交并进行新提交,重新使用原始消息.(如果你的提交会影响多个文件并且只应该将更改带回一个文件,那么它需要更多的工作,但假设它是一个文件,这是一个简单的修复.你仍然需要确保没有人撤消它但是,未来的合并.)

  • 看起来98dbad7是删除了我的更改的合并。从那以后,我与其他受影响的人一样再次提交了我的更改。当我执行git show 98dbad7时,我可以看到更改已还原。令我感到困扰的是,即使该文件受合并影响,为什么不记录该文件不包含合并提交? (2认同)