简体   繁体   English

合并后文件的git commit中的更改消失

[英]Change in a git commit of a file disappears after merge

I was developing in a feature branch. 我在功能分支中进行开发。 At that moment I'd made some other changes which are already merged into develop branch through PR in github and I needed those changes in my feature branch. 那时,我做了一些其他更改,这些更改已通过github中的PR合并到developer分支中,而我需要在我的功能分支中进行这些更改。 So I decided to merge develop branch into my feature branch. 因此,我决定将开发分支合并到功能分支中。 I'd deleted some code in a file and committed in the feature branch. 我已删除文件中的一些代码并提交到功能分支中。 After merging develop into the feature branch, I found that the change of deletion code in the commit of the file disappeared and the deleted part was added back due to the merge operation. 将development合并到feature分支后,我发现文件提交中删除代码的更改消失了,并且由于合并操作而将被删除的部分重新添加回去。 I would like to ask: under what circumstances does this happen? 我想问:在什么情况下会发生这种情况? Thanks! 谢谢!

UPDATED: 更新:

I use github to view the history. 我使用github查看历史记录。 Here is the example: This is the history of agent.go at the commit 80d82ee in the feature branch OWL-1697 . 这里是例子:这是历史agent.go在提交80d82ee在特征分支OWL-1697 This is the whole history of this file in feature branch OWL-1697 . 这是功能分支OWL-1697中此文件的全部历史记录 After the merge operation, the change of 80d82ee for this file disappeared. 合并操作后,此文件的80d82ee更改消失。

I would not recommend using GitHub to view commit and file history. 我不建议使用GitHub查看提交和文件历史记录。 (GitHub may have some nice and/or fancy way to view these, but as a very causal user of GitHub, I do not know of one. The command line tools have extensive flags, although you must be something of a Git expert to know which to use, and when.) (GitHub可能有一些不错的和/或理想的方式来查看它们,但是作为GitHub的因果用户,我不知道一个。命令行工具具有广泛的标志,尽管您必须是Git专家才能知道以及何时使用。)

TL;DR summary of why the merge went wrong TL; DR合并失败原因的摘要

After you work through the text below, pay particular attention to these last few lines of the git log output: 在阅读完以下文本之后,请特别注意git log输出的最后几行:

* | | | | | 80d82eef [OWL-1730][common][nqm-mng] Code refactoring
* | | | | | 2438360a [OWL-1667][common][nqm-mng] From `hbs` to `nqm-mng`
| |_|/ / /  
|/| | | |   
* | | | | b598349a Merge pull request #295 from masato25/OWL-1724

In commit 2438360a , you added some lines, and then in commit 80d82eef , you took them out again. 在提交2438360a ,添加了一些行,然后在提交80d82eef ,再次将它们取出。

However, you put the same added lines in via commit d04492d9 : 但是,您通过提交d04492d9相同的添加行d04492d9

| | * | d04492d9 [OWL-1667][common][nqm-mng] From `hbs` to `nqm-mng`

a bit higher up. 高一点。 You did this on the same day as the added lines in 2438360a . 您与2438360a添加的行在同一天进行了此2438360a You took the lines out, in 80d82eef , much later ... but in a different branch . 您后来在80d82eef中将线路拔出了……但是在另一个分支中 In topological order , you took the change out almost immediately after you put it in ... while also leaving the change in a separate branch. 按照拓扑顺序 ,将更改放入后几乎立即将其取出...,同时还将更改留在单独的分支中。 You then brought those into another branch via e1d369d0 , which you brought into another branch, and so on until you brought them right back into the branch you thought you had taken them out of. 然后,您通过e1d369d0将它们带入另一个分支, e1d369d0其带入另一个分支,依此类推,直到将它们带回到您认为已将它们取出的分支中。

Viewing the commit graph 查看提交图

If I clone your repository and use git log --all --decorate --oneline --graph to view it, I see this, in part, which includes commit 80d82eef (at the bottom): 如果我克隆您的存储库并使用git log --all --decorate --oneline --graph进行查看,我会部分地看到这一点,其中包括commit 80d82eef (在底部):

* aeecad13 (origin/OWL-1697) [OWL-1730][nqm-mng] Update debug message
* f0797f8e [OWL-1730][nqm-mng] Fix the proble from merge
* 5aaba93b [OWL-1730][nqm-mng] Drop gin's "gopkg.in" paths

[mass snip]

* | | | d2d4debd [OWL-1730][nqm-mng] Tests
* | | | e1037c28 [OWL-1730][nqm-mng] Queue service
* | | |   a847d783 Merge branch 'OWL-1677' into OWL-1697
|\ \ \ \  
| * \ \ \   ea916618 Merge branch 'develop' into OWL-1677
| |\ \ \ \  
| | |/ / /  
| * | | | 056a7442 [OWL-1677] Refactoring testing to usage of Ginkgo
| * | | | 800c3f09 [OWL-1677] Add utilities for testing by Ginkgo framework
| * | | |   85deb914 Merge branch 'develop' into OWL-1677
| |\ \ \ \  
| * | | | | c830da0f [OWL-1677] Fix tests
| * | | | | 14d8571c [OWL-1677] Refactoring test to Ginkgo
| * | | | | 8538306f [OWL-1677] Re-write testing to Ginkgo framework
* | | | | | 906741cd [OWL-1730][nqm-mng] Rename types and methods
* | | | | | 80d82eef [OWL-1730][common][nqm-mng] Code refactoring

We can see that the commit is in fact still there, not deleted by the merge. 我们可以看到提交实际上仍然存在,未被合并删除。

Finding commits that affect a file: --full-history 查找影响文件的提交:-- --full-history

Now, the file you care about here is named modules/nqm-mng/restful/agent.go in commit 80d82eef . 现在,您在此处关心的文件在commit 80d82eef被命名为modules/nqm-mng/restful/agent.go 80d82eef As we can see from the --decorate otuput, a branch name that leads here is origin/OWL-1697 . --decorate otuput中可以看到,在--decorate领先的分支名称是origin/OWL-1697 The commits that modify this particular file , however, are a bit tricky to find. 但是,修改此特定文件的提交很难找到。

The first bit of magic to know is to use --full-history when restricting git log to path names (I suspect there is no way to get GitHub to do this). 首先要知道的魔术是在将git log限制为路径名时使用--full-history (我怀疑没有办法让GitHub做到这一点)。 The reason is that if a merge has undone something you wanted done, Git's "history simplification", which removes commits that don't contribute to the final version of the source, makes it impossible to find out which merge removed that contribution. 原因是,如果合并撤消了您想完成的工作,则Git的“历史简化”功能将删除对最终版本 没有贡献的提交,从而无法找出哪个合并删除了该贡献。

The second bit of magic to know is that when looking at merge commits, we may want -m to make Git "split" the merge into the two halves. 要知道的第二点魔术是,当查看合并提交时,我们可能希望-m使Git将合并“拆分”成两半。

I also use --topo-order to force Git to show commits in a topologically sensible order (usually not necessary, but generally a good idea here). 我还使用--topo-order强制Git以拓扑上合理的顺序显示提交(通常不是必需的,但是这里通常是个好主意)。

Who did what 谁做了什么

We might take a look at precisely what 80d82eef does to the file of interest at this point: 现在,我们可能会准确地看一下80d82eef对感兴趣的文件执行的操作:

$ git show 80d82eef -- modules/nqm-mng/restful/agent.go
commit 80d82eef9606800c094858ac0d60f27ef9ad1307
Author: chyeh <chyeh@cepave.com>
Date:   Fri May 19 11:34:09 2017 +0800

    [OWL-1730][common][nqm-mng] Code refactoring

    Move some code from `common/` to `modules/nqm-mng/` as the preparation
    of the following development.

diff --git a/modules/nqm-mng/restful/agent.go b/modules/nqm-mng/restful/agent.go
index 3ba34901..f21afd05 100644
--- a/modules/nqm-mng/restful/agent.go
+++ b/modules/nqm-mng/restful/agent.go
@@ -124,10 +124,3 @@ func clearCachedTargetsOfAgentById(
        r := commonNqmDb.DeleteCachedTargetsOfAgentById(q.AgentID)
        return mvc.JsonOutputOrNotFound(r)
 }
-
-func nqmAgentHeartbeat(
-       req *commonNqmModel.AgentHeartbeatRequest,
-) mvc.OutputBody {
-       r := commonNqmDb.AgentHeartbeat(req)
-       return mvc.JsonOutputBody(r)
-}

Now we can run this rather long command (I've broken it into two lines for display purposes): 现在我们可以运行这个相当长的命令(出于显示目的,我将其分为两行):

$ git log --full-history -m -p --topo-order \
    origin/OWL-1697 -- modules/nqm-mng/restful/agent.go

Note the three extra options (full history, merge split, and topological order). 请注意三个额外的选项(完整历史记录,合并拆分和拓扑顺序)。

The output is long so I won't quote it all, but the commits displayed are: 输出很长,所以我不会全部引用,但是显示的提交是:

  • f0797f8e1e2e5a41db30225f4e72dc987b055ac8 , in which you re-delete the lines brought back by the failed merge; f0797f8e1e2e5a41db30225f4e72dc987b055ac8 ,在其中您重新删除由于合并失败而返回的行;
  • 7e00e309f0ed5750f6b7b052e77431ec4797d601 (vs its first parent d2d4debd ), which re- adds the lines you did not want); 7e00e309f0ed5750f6b7b052e77431ec4797d601 (相对于其第一个父项d2d4debd ),它重新添加了您不需要的行。
  • 648a324e1333814968a09e4b0277fc0774b4fce6 (vs its first parent 447ac685 ), which affects just an import line; 648a324e1333814968a09e4b0277fc0774b4fce6 (相对于其第一个父项447ac685 ),这仅影响import行;
  • ccbad82029c50040250a48180caeacfcc57044bd (vs its second parent da0dcde6 ), which also re-adds the lines you did not want; ccbad82029c50040250a48180caeacfcc57044bd (相对于其第二个父级da0dcde6 ),它还会重新添加您不想要的行;
  • dfa34ab98170d62e1bb6d624c2d09f9e4e7e0b57 (vs its second parent 5571dc2c ); dfa34ab98170d62e1bb6d624c2d09f9e4e7e0b57 (与其第二个父代5571dc2c );
  • 219347a6f1649ccfee8e69b481e3166d8d310fe0 (vs its second parent 1a60e4aa ); 219347a6f1649ccfee8e69b481e3166d8d310fe0 (与其第二个父级1a60e4aa );
  • b11d41be75700c450280a4a5e0edb12381045303 (vs its second parent 28176808 ); b11d41be75700c450280a4a5e0edb12381045303 (与其第二个父级28176808 );
  • 8f5a0e242fd7c7ded6cdcc4517c33c793b96f8ea (vs its second parent 5178acdb ); 8f5a0e242fd7c7ded6cdcc4517c33c793b96f8ea (与其第二个父级5178acdb );
  • e1d369d06a49846f39661642bdfb7c0c81a86b8e (vs its first parent 8b1d4f0f ); e1d369d06a49846f39661642bdfb7c0c81a86b8e (与其第一个父级8b1d4f0f );
  • d04492d986fdf1257cb93a5524f2501e767bd564 : this is an ordinary commit that you made on 2 May, in which you added the lines you do not want; d04492d986fdf1257cb93a5524f2501e767bd564 :这是您在5月2日所做的普通提交,在其中添加了不需要的行;
  • 80d82eef9606800c094858ac0d60f27ef9ad1307 : this is the ordinary commit you made on 19 May, in which you deleted the lines you do not want; 80d82eef9606800c094858ac0d60f27ef9ad1307 :这是您在5月19日所做的普通提交,在其中删除了不需要的行;
  • 2438360a653e5c158b366f313bf771db4f294147 : this is an ordinary commit that you made on 2 May, in which you added the lines you do not want; 2438360a653e5c158b366f313bf771db4f294147 :这是您在5月2日所做的普通提交,在其中添加了不需要的行;
  • and then numerous irrelevant commits that do not affect the lines you care about, all predating these changes. 然后许多不相关的提交都不会影响您关心的行,而这些提交都早于这些更改。

Putting these in context 将这些放在上下文中

Depending on how you do your merges, the "most interesting" ones tend to be the first parent ones. 根据您的合并方式,“最有趣”的合并往往是第一个父合并。 This is the case above. 上面就是这种情况。

It's also a good idea to look at the merge base of the merge that brought back the changes you did not want. 查看合并带来了不需要的更改的合并基础也是一个好主意。 To do this, we need to run git merge-base on the two hash IDs of the two parents of that merge. 为此,我们需要在该git merge-base的两个父级的两个哈希ID上运行git merge-base As a reminder, that merge's hash ID is 7e00e309 (or 7e00e309f0ed5750f6b7b052e77431ec4797d601 in full). 提醒一下,合并的哈希ID为7e00e309 (或完整的7e00e309f0ed5750f6b7b052e77431ec4797d601 )。 So let's run git merge-base on the two parents: 因此,让我们在两个父对象上运行git merge-base

$ git merge-base --all 7e00e309^1 7e00e309^2
b598349a0ba6d6901ef812440746e2dc633c4cdc

Commits "below" this point tend not to be of interest. 承诺“低于”这一点往往不会引起人们的兴趣。

We can now use: 我们现在可以使用:

git log --decorate --oneline --graph origin/OWL-1697

to view all of these in their complete context, although matching up the hash IDs is quite difficult and painful. 要在完整的上下文中查看所有这些,尽管匹配哈希ID十分困难且痛苦。 Or, we can run: 或者,我们可以运行:

git log --decorate --oneline --graph origin/OWL-1697 \
    --full-history -- modules/nqm-mng/restful/agent.go

to strip this display down to just commits that touch that file, when compared to any of their parent commits. 与任何父提交相比,将显示内容简化为仅触摸该文件的提交。 The result is still quite long, but is now follow-able. 结果仍然很长,但是现在是可以追踪的。 Let's follow it down to the merge base, ie, the commit starting with b598349a : 让我们将其跟踪到合并基础,即以b598349a开头的提交:

* f0797f8e [OWL-1730][nqm-mng] Fix the proble from merge
*   7e00e309 Merge branch 'develop' into OWL-1697
|\  
| *   648a324e Merge pull request #306 from Cepave/OWL-1771
| |\  
| | * 4d722f8d [OWL-1771] Change `gin`'s import paths
| * |   447ac685 Merge branch 'roby-testing' into develop
| |\ \  
| * | | ee1daba9 Merge pull request #305 from masato25/OWL-1674_ma
| | |/  
| |/|   
| * |   ccbad820 Merge pull request #303 from masato25/OWL-1740
| |\ \  
| * \ \   69a9ee6e Merge pull request #302 from masato25/OWL-1765
| |\ \ \  
| | * \ \   9e9d1a55 Merge branch 'develop' into OWL-1765
| | |\ \ \  
| | |/ / /  
| |/| / /   
| | |/ /    
| * | |   dfa34ab9 Merge pull request #300 from masato25/OWL-1740
| |\ \ \  
| | |/ /  
| * | |   219347a6 Merge pull request #301 from masato25/OWL-1755
| |\ \ \  
| | |/ /  
| * | |   b11d41be Merge pull request #299 from masato25/OWL-1755
| |\ \ \  
| | |/ /  
| | | /   
| | |/    
| |/|     
| * |   8f5a0e24 Merge pull request #298 from humorless/OWL-1644-c
| |\ \  
| * \ \   e1d369d0 Merge pull request #286 from Cepave/OWL-1667
| |\ \ \  
| | |/ /  
| |/| |   
| | * | d04492d9 [OWL-1667][common][nqm-mng] From `hbs` to `nqm-mng`
| * | |   8b1d4f0f Merge pull request #297 from hitripod/develop
| |\ \ \  
| * | | | 05e45dc8 Merge pull request #296 from masato25/OWL-1765
| | |_|/  
| |/| |   
* | | |   a847d783 Merge branch 'OWL-1677' into OWL-1697
|\ \ \ \  
| * \ \ \   ea916618 Merge branch 'develop' into OWL-1677
| |\ \ \ \  
| | |/ / /  
| |\ \ \ \  
| | |/ / /  
| * | | |   85deb914 Merge branch 'develop' into OWL-1677
| |\ \ \ \  
* | | | | | 80d82eef [OWL-1730][common][nqm-mng] Code refactoring
* | | | | | 2438360a [OWL-1667][common][nqm-mng] From `hbs` to `nqm-mng`
| |_|/ / /  
|/| | | |   
* | | | | b598349a Merge pull request #295 from masato25/OWL-1724
| |_|/ /  
[snip]

This output contains all the reasons why your merge went wrong. 此输出包含合并错误的所有原因。 As far as Git is concerned, adding and then immediately removing those lines, in commits 2438360a and 80d82eef , was quite irrelevant. 就Git而言,在commit 2438360a80d82eef添加然后立即删除这些行是完全无关的。 What mattered was the independent and never-undone adding of those same lines in d04492d9 . 重要的是在d04492d9对这些相同的行进行了独立且从未取消的添加。 That's the source of the change brought in by a series of merges, and ultimately brought in by merge 7e00e309 . 这就是由一系列合并带来的更改的源头,并最终由合并7e00e309带来了。 All Git could tell is that those lines were supposed to be there, because they were added by one "side" of the merge, and the other side did nothing to the file! Git只能说这些行应该在那儿,因为它们是在合并的“一侧”添加的,而另一侧对文件没有任何作用!

Since your file changes which you made in feature branch is not yet committed, while merging you probably stashed them. 由于您尚未在功能分支中进行的文件更改尚未提交,因此合并时可能将其保存了。 so while merge in operation those changes added back. 因此,在合并操作时,这些更改会重新添加。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM