Question

我们有时候github中的文件会恢复到以前的版本。我们只有一个主分支。我们可以看到提交历史记录中的更改，它是该文件发生的最后一次更改，但在Github中查看文件并从客户端工具中提取/提取显示旧版本。

一种可能的症状是，通常我在查看存储库级别的每次提交时都会看到这种情况

<table>
  <tr>
    <td>Commit</td>
    <td>Parent</td>     
  </tr>
  <tr>
    <td>2</td>
    <td>1</td>     
  </tr>
  <tr>
    <td>3</td>
    <td>2</td>     
  </tr>
  <tr>
    <td>4</td>
    <td>3</td>     
  </tr>
  <tr>
    <td>5</td>
    <td>4</td>     
  </tr>
</table>

但是，如果文件丢失了更改，它看起来像这样：

<table>
  <tr>
    <td>Commit</td>
    <td>Parent</td>     
  </tr>
  <tr>
    <td>2</td>
    <td>1</td>     
  </tr>
  <tr>
    <td>3</td>
    <td>2</td>     
  </tr>
  <tr>
    <td>4</td>
    <td>2</td>     
  </tr>
  <tr>
    <td>5</td>
    <td>4</td>     
  </tr>
</table>

提交3中的更改已经消失。

Answer 1

所以这里是我打赌在这里发生的事情：提交5将3和4都作为父项（即它是合并提交），或者提交5的某些后代是合并提交，其父项之一是提交3.如果是这种情况，则会发生以下情况：提交1和2都在服务器上和每个人的本地存储库中。有人提交3并推送到服务器。其他人（没有从服务器拉出）进行提交4和5（可能更多）。如果他们试图推动，他们会得到一个“快速前进”＃34;错误，因为他们的回购已经过时了。错误表明他们拉，所以他们这样做。现在，pull是一个提取和合并，但在这种情况下，合并导致冲突，因此它不会自动提交。该人解决了合并冲突，但在提交合并通知之前发现有变化（完全与冲突无关），他们没有做出改变。这些是即将丢失的提交3的更改。该人撤消这些更改，提交，然后推动。

你没有看到这个＆＃34;拙劣的合并＆＃34;当您查看有问题文件的历史记录时，如果该文件与该提交的不同，则默认情况下git不包括文件历史记录中的合并提交。的父母。在这种情况下，该文件与提交3不同（因为在提交3中完成的更改已撤消），但与另一个父项没有区别。要在历史记录中包含此混淆合并，请使用git log <filename> --full-history。

最重要的是，必须让存储库的所有用户都知道，在提交合并时，他们必须提交所有分阶段的更改，即使他们没有进行这些更改，因为这些是应该从＆＃34;其他＆＃34;中合并的更改科。

Answer 2

在git存储库中发生这种情况的唯一方法是通过强制推送。从第二个图中可以看出，提交4依赖于提交2.这可能发生了什么：

1<-2<-3

这是原始的回购（请注意，git只会指向他们的父级，而不是他们的子级）。然后有人做了提交4和5，但是，他们有一个旧版本的回购，他们只有提交1和2.然后，当他们强制推送到远程仓库时，你最终得到：

1<-2<-3
    \-4<-5

提交3仍然存在于reflog中，但没有指向它的分支。通过禁用强制推送可以修复，但真正的问题是没有正确使用git的团队问题。

你说你只有一个分支（主），这是一个不正确的工作流程的指标。查看git flow并与您的成员讨论强制推动的危险。 github使用的模型也是分布式的，其中每个成员都有自己的存储库，而其他成员没有写访问权限。在此模型中，代码通过拉取请求共享。这也可能有所帮助。

祝你好运！

如何在没有提交的情况下在Git / Github中更改文件

2 个答案: