假设我正在分支A上工作,并且合并了分支B的一些更改。 分支B有一个名为setup.sh的文件,我在分支A上工作,修改setup.sh文件并提交,然后在分支A的其他文件上执行3次不同的提交。
现在,我意识到我不应该在setup.sh文件中进行更改。我想恢复到setup.sh的分支B版本。显而易见的解决方案是git checkout和git commit,但是它显示了我在git blame中修改的文件。我不要那个。知道如何进行吗?
答案 0 :(得分:1)
要将还原为文件的特定版本,必须进行一个新提交,其中包含该文件的该版本(以及与其他所有文件的版本一样,与其他任何提交一样)。
显而易见的解决方案是git checkout和git commit,但它显示了我在git blame中修改过的文件。
情况将一直如此,因为git blame
根据每个快照之间的差异分配文件中每一行的所有权。也就是说,我们得到了以下事实:
... <-F <-G <-H <--branch
其中分支名称branch
告诉Git last 提交是提交H
,而提交H
告诉Git 上一个 commit是commit G
,commit G
告诉Git先前的提交是commit F
,依此类推。 git blame
的工作是从提交H
中提取文件,然后从提交G
中提取相同文件。线匹配的地方,所有权从H
到G
,但是我们还没有完成。如果行不匹配,则所有权位于H
。
现在,如果我们在G
,git blame
将从提交G
中提取文件,并再次从提交F
中提取文件。这两行匹配时,所有权移回F
,而在不匹配的地方,所有权保持在G
。
一旦我们到达F
,Git将从F
的父级提取文件,并重复整个过程。
最终,每行都有一个分配的提交,这就是您在行左侧看到的内容。
这意味着无论您如何将文件还原到旧提交,都是您恢复文件,git blame
会在那里停止。要继续进行下去,您必须运行第二个git blame
,其内容为从我提交之前开始,向后看您一直使用的方式,现在git blame
会将行分配给较早的提交。 Git从末尾开始并向后工作,如果您希望它从您的提交之前的结尾开始,您只需从此处开始,而不是从当前提交开始(或当前工作树副本,大多数情况下这才是我们真正开始git blame
的地方)。