为什么git合并后git从日志中丢失提交? [英] Why does git lose a commit from log after merge?

问题描述

我正在尝试将开发分支合并到master.但这似乎撤消了在master中所做的提交，以致于该特定提交不再出现在文件的git log中.

I'm trying to merge a development branch into master. But it seems to undo a commit that was made in master, to the extent that the particular commit no longer appears in the file's git log.

当我在master分支上时，可以看到在7月14日提交2d1b9af

When I'm on the master branch, I can see commit 2d1b9af on Jul 14

c:\src>git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

c:\src>git log server\Fitnesse\FitNesseRoot\APITest\content.txt
commit 88a68b11b273b98531ae686b85b5733b86706bda
Author: charles
Date:   Fri Jul 15 00:56:44 2016 +0000

    XX-338 Add IsDeleted to Place table

commit 2d1b9afdabd7fbbf970d697bd0c15957a8fd288a
Author: charles
Date:   Thu Jul 14 23:15:28 2016 +0000

    fix FitNesse test which are broken by renaming

commit f1616fed48bb15c1c120cfe016e571f49aae6244
Author: charles
Date:   Tue Jun 21 11:04:53 2016 +1200

    modify fitNesse Test for new API changes.

然后我合并到我的大分支中.

Then I merge in my large branch.

c:\src>git merge origin/myLargeBranch
Removing server/Database/355_UnitTest.sql
Merge made by the 'recursive' strategy.
 .../packages.config                                |   2 +-
 .../Utilities/Extensions/StringExtensions.cs       |  10 +
 .../Utilities/Throttle.cs                          |  45 ++++

 [ ... etc ]

 .../FitNesseRoot/APITest/content.txt         |  37 +--
 128 files changed, 3705 insertions(+), 481 deletions(-)
 create mode 100644 [ ... ] 

c:\src>git status
On branch master
Your branch is ahead of 'origin/master' by 32 commits.
  (use "git push" to publish your local commits)
nothing to commit, working directory clean

我在这里注意到它会更改我正在查看的文件.自从上了分支以来，我还没有真正修改过该文件.这可能与我的问题有关，但并不是我要问的.

I note here that it alters the file I'm looking at. I haven't actually modified this file since I took the branch. This may be related to my issue, but it's not specifically what I'm asking about.

现在对我来说重要的是，他从7月14日开始的承诺已不在我的日志中:

What's important to me right now, is that he commit from 14 July isn't in my log any more:

c:\src>git log server\Fitnesse\FitNesseRoot\APITest\content.txt
commit f1616fed48bb15c1c120cfe016e571f49aae6244
Author: charles
Date:   Tue Jun 21 11:04:53 2016 +1200

    modify fitNesse Test for new API changes.

commit 16b7beb9d1045f5fe7354c0fdbe637a49bb48ce0
Author: charles
Date:   Tue May 10 10:54:13 2016 +1200

所以，我有点担心要最后得到错误的代码.这是一个令人担忧的问题.

So I'm a little concerned about getting the wrong code in the end. This is a bit of a worry.

但是我真的更担心git现在没有在日志中显示曾经进行过更改.

But I'm really much more worried that git is now not showing in it's log that the changes were ever made.

我想念什么?

更新 @ tim-biegeleisen发表评论后，我已经跟踪了实际的提交，但仍然感到困惑.

Update After comments from @tim-biegeleisen I've tracked down the actual commit, but am still as confused.

罪魁祸首似乎是从master到我的开发分支的合并:

The culprit appears to be a merge from master onto my development branch:

c:\src>git show b5637f9
commit b5637f9a65e415f1b415fad99c9e7a4e6b46ab1a
Merge: cb8ed90 6b5c0e1
Author: GregH <GregH@GREGH-LT001>
Date:   Tue Jul 26 04:25:40 2016 +0000

    Merge from master
[ ... ] 

cb8 ...是我的分支机构

cb8... is my branch:

c:\src>git checkout cb8ed90
Previous HEAD position was 6b5c0e1... PR 93: Merge DeletePlace to master
HEAD is now at cb8ed90... Added tests for apple messages


c:\src>git log server\Fitnesse\FitNesseRoot\APITest\content.txt
commit f1616fed48bb15c1c120cfe016e571f49aae6244
Author: charles
Date:   Tue Jun 21 11:04:53 2016 +1200

6b5 ...是大师

6b5... is master

c:\src>git checkout 6b5c0e1
Previous HEAD position was cb8ed90... Added tests for apple messages
HEAD is now at 6b5c0e1... PR 93: Merge DeletePlace to master

c:\src>git log server\Fitnesse\FitNesseRoot\APITest\content.txt
commit 88a68b11b273b98531ae686b85b5733b86706bda
Author: charles
Date:   Fri Jul 15 00:56:44 2016 +0000

在合并之后，我丢失了7月14日至15日的提交.

And after the merge, I've lost the commits from 14 and 15 July.

c:\src>git checkout b5637f9
Previous HEAD position was 6b5c0e1... PR 93: Merge DeletePlace to master
HEAD is now at b5637f9... Merge from master

c:\src>git log server\Fitnesse\FitNesseRoot\APITest\content.txt
commit f1616fed48bb15c1c120cfe016e571f49aae6244
Author: charles
Date:   Tue Jun 21 11:04:53 2016 +1200

**更新:**由VonC建议，git log --all显示提交仍在历史记录中.

**Update: ** Suggested by VonC, git log --all shows the commits are still in the history.

没有--all时，与上面一样，显示6月21日的最新更新 git日志服务器\ Fitnesse \ FitNesseRoot \ APITest \ content.txt (没有必要重复).

Without --all, it's as above, showing latest update jun 21 git log server\Fitnesse\FitNesseRoot\APITest\content.txt (No point repeating it).

但是和 --all他们在一起:

c:\src>git log --all server\Fitnesse\FitNesseRoot\APITest\content.txt
commit 88a68b11b273b98531ae686b85b5733b86706bda
Author: charles
Date:   Fri Jul 15 00:56:44 2016 +0000

    XX-338 Add IsDeleted to Place table

commit 2d1b9afdabd7fbbf970d697bd0c15957a8fd288a
Author: charles
Date:   Thu Jul 14 23:15:28 2016 +0000

    fix FitNesse test which are broken by renaming

commit f1616fed48bb15c1c120cfe016e571f49aae6244
Author: charles
Date:   Tue Jun 21 11:04:53 2016 +1200

    modify fitNesse Test for new API changes.

那么在合并过程中如何撤消它们?

So how come they're undone during the merge?

推荐答案

从git log获得的输出实际上非常棘手.您可以触发许多陷阱.在这种情况下，您要命中的那个称为历史简化".引用自文档:

The output you get from git log is actually rather tricky. There are numerous traps you can trigger. The one you are hitting in this case is called "history simplification". Quoting from the documentation:

有时您只对历史的某些部分感兴趣，例如，修改特定< path>的提交.但是，简化历史记录"有两个部分，一个部分是选择提交，另一部分是如何进行提交，因为有多种策略可以简化历史记录.

Sometimes you are only interested in parts of the history, for example the commits modifying a particular <path>. But there are two parts of History Simplification, one part is selecting the commits and the other is how to do it, as there are various strategies to simplify the history.

以下选项选择要显示的提交:

The following options select the commits to be shown:

<paths>

致力于修改给定的< paths>被选中.

       Commits modifying the given <paths> are selected.

--simplify-by-decoration

选择了某个分支或标签所引用的提交.

      Commits that are referred by some branch or tag are selected.

请注意，可以显示额外的提交以提供有意义的历史记录.

Note that extra commits can be shown to give a meaningful history.

以下选项会影响简化的方式:

The following options affect the way the simplification is performed:

默认模式

将历史简化为最简单的历史，解释树的最终状态.最简单，因为如果最终结果相同(即合并具有相同内容的分支)，它将修剪一些侧分支

       Simplifies the history to the simplest history explaining the final state of the tree. Simplest because it prunes some side branches if the end result is the same (i.e. merging branches with the same content)

--full-history

与默认模式相同，但不修剪某些历史记录.

       Same as the default mode, but does not prune some history.

[snip]

在合并之前，Git会简化查看的历史记录，而无需查看合并的路径.

Before you merge, Git simplifies the history as viewed without looking down the path of the merge.

在合并之后，Git简化了在查看合并路径(或者更确切地说是两条路径")时所查看的历史记录.由于您使用的是默认模式，因此，如文档所述，Git可以修剪某些侧枝"(尽管没有更多关于 侧枝被修剪的足够详细信息，但还有更多详细信息在本节的稍后部分使用单词TREESAME:拼写不出来的事实是，TREESAME在剥离除列出的< paths>中的文件之外的每个文件之后都经过测试.

After you merge, Git simplifies the history as viewed while looking down the path (or rather, "both paths" as it were) of the merge. Since you are using the default mode, this allows Git to "prune some side branches", as the documentation says (without going into enough detail about just which side branches are being pruned, although there is more later in the section using the word TREESAME: not spelled out there is the fact that TREESAME is tested after stripping out every file except for those in your listed <paths>).

如果添加--full-history，则应该看到提交的结果.

If you add --full-history you should see your commits return.

请注意，如果您未指定某些路径，则不会打开历史记录简化功能，除非您添加一些特定的简化程序选项(在我摘录的部分中).

Note that history simplification is not turned on if you do not specify some path(s), unless you add some of the specific simplifier options (in the section I snipped).

这篇关于为什么git合并后git从日志中丢失提交?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！