合并后提交ID保持不变？ [英] Do the commit ids remain same after a merge?

问题描述

我的团队使用git和Bitbucket进行版本控制。

我之前创建了一个从我的资源库的某个分支到其中一个分支的合并请求团队的主要存储库。

这个拉取请求被接受了，我的分支被合并了。

昨天我添加了一些更改到我的存储库中的同一分支。当我尝试向团队存储库中的同一分支创建请求时，我收到了一些合并冲突的通知。

我查看了团队分支的提交日志，即使提交消息，作者（我）&日期相同，远程分支中的提交ID不同。

这里有什么问题？

我的印象是，即使在合并提交ID后仍然保留。

其他可能导致这种情况？

PS
我读过 cherry-pick 可以更改提交id。任何想法？

解决方案

合并既不保留也不保存commit-IDs。合并进行新的提交（假设你以避免快进操作的方式进行提交）。

即，给出一系列单独的提交，我会用单个字母来标注：

  A  -  B  -  C 
 \ 
 D 
  

提交 C （这可能确实是ID 6da748a ... ）已经提交 B 它的父项，并提交 D （可能实际上是 740c281 ... ）也具有提交 B 作为其父项。为了合并这两个提交，git必须用两个父母创建一个新提交：

  A  -  B -  C  -  M 
 \ / 
 D 
  

这个新的提交 M 与每个其他提交都有不同的ID，但提交 D 完全不变，因此仍然有相同的ID（ 740c281 ... ）。

许多人试图避免进行这种相对简单的合并。他们不是在工作（提交 C ）和工作（提交 D >）并进行新的合并提交，而是复制你的提交信息（包括作者和日期），并对 B 做出与 C 相同的更改>。这个操作实际上被称为樱桃采摘（也称为rebasing），但它会产生一个新的，不同的提交，我们可以称之为 D'不同的提交ID：

  A  -  B  -  C  -  D'
  pre> 
 
 
原来的 D 和这个新的 D'是 D'已经提交 C 作为它的父类，而不是提交 >乙。 （在正常情况下，它也有不同的树内容，因为您的 B   -  < -  c $ c> D 如版本 C 所示，它们可能与 B 中的某些地方不同。）
 
 
 
提交 D'不是 merge 提交，但是。 （合并提交是至少有两个父提交的任何提交，使用 git log --graph 或 gitk 或某些）
 
 
如果你的工作被重新组装（或挑选）到上游，并且你获取然后尝试合并上游的git有时（但不总是）能够检测到重复并自动清理。当它不能自动检测重复时，你几乎总是会遇到各种合并冲突：git会让你试图改变一些代码（在你的提交<上面的例子中提供了 D ），和他们试图改变相同的代码，但以一种稍微不同的方式（在他们的提交 D'在上面）。出于这个原因，将别人的代码重新绑定通常不被认为是非常礼貌的：上游会倾向于要求你自己重新绑定代码（虽然它对你来说仍然是私有的），然后他们可以将其包含为快进（合并-free）添加到其存储库中。
 
 
 
（这样，您也可以自己对rebase操作进行任何更改，例如，如果修复了版本中的错误 D ，它们也在 C 中修正，但你和他们采取了不同的方法，你可以解决这个冲突 - 可能因为你知道你做了什么，为什么你这样做，以及你的新功能是否依赖于你的修正版的版本。）
 
My team uses git and Bitbucket for version control.

I had previously created a Pull Request from one of the branches of my repository to one of the branches of the team's main repository.

This pull request was accepted and my branch was merged in.

Yesterday I added some changes to the same branch in my repository. When I tried to create a pull request to the same branch on team's repository, I was notified of some merge conflicts.

I viewed the commit log of the team's branch and realized that although the commit message, author(me) & date were same, the commit id was different in the remote branch.

What could be the problem here?

I was under the impression that even after merge commit ids are preserved.

Could something else be causing this?

P.S.
I have read that cherry-pick can change commit ids. Any thoughts?
解决方案
Merges neither preserve, nor fail to preserve, commit-IDs.  Merges make new commits (assuming you do them in such a way as to avoid a "fast forward" operation, anyway).

That is, given a sequence of individual commits that I will label with single letters:
A - B - C
      \
        D
commit C (which might perhaps really be ID 6da748a...) has commit B its parent, and commit D (perhaps actually 740c281...) also has commit B as its parent.  To merge these two commits, git must create a new commit with two parents:
A - B - C - M
      \   /
        D
This new commit M has a different ID from every other commit, but commit D is completely unchanged and therefore still has its same ID (740c281...).

Many people try to avoid making this kind of relatively-trivial merge.  Instead of taking their work (commit C) and your work (commit D) and making a new merge commit, they make a copy of your commit message—including author and date—and make the same changes to C that you made to B.  This operation is indeed called "cherry picking" (and also "rebasing"), but it makes a new, different commit, which we might call D', with a new, different commit-ID:
A - B - C - D'
The most obvious difference between your original D and this new D' is that D' has commit C as its parent, rather than commit B.  (It also has different tree contents, in normal cases, since your B-to-D changes were applied to files as seen in version C, which are likely different in some places from those in B.)

Commit D' is not a merge commit, however.  (A merge commit is any commit with at least two parent commits.  Use git log --graph or gitk or some other graphical viewer to see the commit graph more directly.)

If your work is rebased (or cherry-picked) into an upstream, and you fetch and then attempt to merge the upstream, git will sometimes, but not always, be able to detect the duplication and clean up automatically.  When it cannot auto-detect the duplication, you will almost always get various merge conflicts: git sees you trying to change some code (in your commit D in the above example), and them trying to change the same code, but in a slightly different way (in their commit D' in the above).  For this reason, it's generally not considered very polite to rebase someone else's code: instead, upstreams tend to ask you to rebase your code yourself (while it's still private to you) and then they can include it as a "fast forward" (merge-free) addition to their repository.

(This way you can also make any changes required by the rebase operation yourself.  For instance, if you fixed a bug in your version D that they also fixed in their C, but you and they took different approaches, you can resolve this conflict—possibly more easily than they can since you know what you did and why you did it that way, and whether your new feature depends on your version of the fix.)

                        
这篇关于合并后提交ID保持不变？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！