在Git中尝试恢复时发生冲突 [英] Conflict while trying a revert in Git

问题描述

我正在学习git。
我有以下情况：
$ b $ 1）一个名为test.txt的文件
文件的初始内容：

 一行
  

I用这个内容提交文件。

2）我在文件中添加一行
文件的内容现在是：

 一行
两行
  

我用这个内容提交文件

3）在文件
中添加一行新文件现在的内容是： / p>

 一行
两行
三行
  

我用这个内容提交文件。

现在我想恢复第二次提交。
所以我的文件内容应该是

 一行
 
三行
  

但是当我运行时：
git revert commitid_2
我收到以下错误消息：

 错误：无法还原4d417ed ...两行
提示：在解决冲突之后，将校正路径标记为
 hint：用'git add <路径>'或'git rm <路径>'
提示：并用'git提交结果提交'
  

当我打开test.txt文件时：我看到内容被以下内容替换：

 <<<<<<< HEAD 
一行
两行
三行
 ======= 
一行
>>>>> >>父母的4d417ed ...两行
  

这是什么意思？
如何在保留commit 1和commit 3所做的更改的情况下，独自恢复由commit 2所做的更改？解决方案

以下是 git revert 所做的简化（希望不会过于简化）。你给它一个提交ID或者一个解析为提交ID的名字，在这种情况下，显然是 4d417ed - 并且它发现在该提交中改变了什么， diff - 将提交中的文件与提交之前的文件进行比较。那就是：

pre $ git diff 4d417ed ^ 4d417ed


差异为：

  diff --git a / test.txt b / test.txt 
 index [something] .. [something] 100644 
 --- a / test.txt 
 +++ b / test.txt 
 @@ -1 + 1,2 @@ 
一行
 +两行
  

（ index 和模式并不那么重要;关键在于它显示了旧版本和新版本，在统一差异中）。统一的差异显示，在所添加的行上面（仅）一行，，而下面没有行。

每次更改的每一侧都有额外的上下文行。这是一个更典型的统一差异块，我将一行代码移动了几行：

  @@ -12， 9 +12,9 @@ class Peer（object）：
 
 def _renew（self）：
 self._sock = socket.socket（socket.AF_INET，socket.SOCK_STREAM）
 + self._sock.setsockopt（socket.SOL_SOCKET，socket.SO_REUSEADDR，1）
 self._sock.bind（self._local_addr）
 self._sock.setblocking（False）
  -  self ._sock.setsockopt（socket.SOL_SOCKET，socket.SO_REUSEADDR，1）
 self._state ='bound'
 
 def is_open（self）：
  

查看 + 之前的三行，以及<$ c之后的三行$ C> - ？但是，对于 test.txt ，由于没有after上下文行，因此该文件必须在添加的行之后结束。没有三行之后的上下文意味着文件在此结束。 （而且，单行的before这一行告诉git-redundantly，这很明显来自行号 - 该文件在修改之前只有一行。）

在任何情况下，由于您正在执行 revert ，git现在尝试使用更改修补文件的当前版本如上所示。

要做一个正向补丁，git会希望该文件看起来像之前版本 - 也就是说，它会使用行号和上下文线，查找具有完全相同上下文的给定行号的最近行，并将其更改为之后。为了反转一个补丁，git希望看起来像之后，并且将它改变为看起来像之前。但是当前版本的文件在两行行之后有额外的东西。也就是说，上下文不匹配。如果文件在阅读两行行后结束，git会知道该怎么做：删除行两行。但是git不知道该怎么做，所以它会让修改后的文件和冲突标记一起手动解析。

如果将 merge.conflictstyle 到 diff3 ，git会在你的 test.txt中为你留下这个 file：

 一行
<<<<<<<<<<<<<<<<<<<<¥ HEAD 
两行
三行
 ||||||| 4d417ed ...添加一行
两行
 ======= 
>>>>>>>父母的4d417ed ...添加一行
  

有些人觉得这更容易阅读（尽管在这种情况下它并没有真正的帮助很多）。

（另外：我不确定你为什么不想要这个文件：

 一行
三行
  

中间没有空行，但这是一个完全不同的问题。）

I am learning git. I have the following scenario:

1) A file named test.txt the initial contents of the file :

one line

I commit the file with this content.

2) I add a new line to the file The contents of the file now is:

one line
two line

I commit the file with this content

3)I add a new line to the file The contents of the file now is:

one line
two line
three line

I commit the file with this content.

Now i want to revert the second commit. So the content of my file should be

one line

three line

but when i run : git revert commitid_2 I get the following error message:

error: could not revert 4d417ed... two line
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

When i open the test.txt file: i see the contents replaced by the following:

<<<<<<< HEAD
one line
two line
three line
=======
one line
>>>>>>> parent of 4d417ed... two line

What does this mean? How can i revert the changes made by commit 2 alone while keeping the changes made by commit 1 and commit 3 intact?

解决方案

Here's what git revert does, simplified (hopefully not oversimplified). You give it a commit ID, or a name that resolves to a commit ID—in this case, apparently that was 4d417ed—and it finds out what changed in that commit, by diff-ing the files in the commit with those in the commit just before it. That is:

git diff 4d417ed^ 4d417ed

The diff reads:

diff --git a/test.txt b/test.txt
index [something]..[something] 100644
--- a/test.txt
+++ b/test.txt
@@ -1 +1,2 @@
 one line
+two line

(the index and mode are not so important; the key is that this shows the old and new versions, in a "unified diff"). The unified diff shows that there was (only) one line above the added line, and no lines below it.

In a unified diff, there are extra "context" lines on either side of each change. Here's a more typical unified-diff chunk, where I moved one line of code up a few lines:

@@ -12,9 +12,9 @@ class Peer(object):

     def _renew(self):
         self._sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+        self._sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
         self._sock.bind(self._local_addr)
         self._sock.setblocking(False)
-        self._sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
         self._state = 'bound'

     def is_open(self):

See how there are three lines before the +, and three lines after the -? For test.txt, though, since there's no "after" context line, the file must have ended after the added line. The absence of the three lines of "after" context mean "file ended here". (And, the single "before" line tells git—redundantly, it's obvious from the line numbers—that the file had only one line "before" the change.)

In any case, since you're doing a revert, git now attempts to "reverse patch" the current version of the file, using the change shown above.

To do a "forward patch", git would expect the file to look like the "before" version—that is, it would use the line numbers and the context lines, finding the nearest lines to the given line numbers that have the exact same context, and change those to look like the "after". To reverse a patch, git expects the to look like the "after", and would change it to look like the "before". But the current version of the file has "extra stuff" after the line two line. That is, the context doesn't match. If the file ended after the line reading two line, git would know what to do: remove the line two line. But git doesn't know what to do, so it leaves the modified file, with conflict markers, for you to resolve manually.

If you set merge.conflictstyle to diff3, git will leave you with this in your test.txt file:

one line
<<<<<<< HEAD
two line
three line
||||||| 4d417ed... add a line
two line
=======
>>>>>>> parent of 4d417ed... add a line

Some people find this easier to read (though in this case it does not really help much).

(Aside: I'm not sure why you don't want the file to read:

one line
three line

with no blank line in between, either. But that's a completely different issue.)

这篇关于在Git中尝试恢复时发生冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！