为什么git将一个分支合并到自己？ [英] Why does git merge a branch into itself?

问题描述

今天早上我醒了，看看我的一个开发团队的私人存储库在BitBucket上的提交历史。我看到了这一点：

匿名已提交 fcde879 MERGE

合并分支'develop'of https：// bitbucket.org/abc/xyz 进行开发

这是，呃，有点不寻常。我的猜测是，这是从没有正确配置git的新机器中推出的。不过，我不确定它为什么这样做。在BitBucket中，它显示了两个单独的散列作为提交父项，但它没有其他提交的view raw commit选项。

  sidious @ DS-1：/ path / to / repo $ git log -1 --format = raw 
 tree 2931d14f48e61eaf0bbe0660af5b5dd76c07f063 
 parent 6bb38dee681df7620ffa42b6790641a7873166f2 
 parent f59c82e19e3e79310a53e273bab78139c49ff063 
 author root< root @ somemachine> 1437069530 +0000 
提交者根< root @ somemachine> 1437069530 +0000 
 
合并https://bitbucket.org/abc/xyz的分支'develop'开发
  

就我所知，6bb父母在开发分支上，而f59父母似乎来自不同的分支。这很难说出是怎么回事。

我搜索了但找不到答案，我需要回到研究中，因此我提出了我的查询这里：为什么git合并一个分支到自己？或者，为什么这个命名法被用作提交信息？

解决方案

这种情况并不罕见。

关键在于被合并的分支是不同的：它是远程仓库的 develop 分支被合并到开发者本地（工作） develop 分支。

在开发人员的本地存储库中有两个不同的分支：

• develop =他/她目前正在处理的分支。新的提交到这里。


• origin / develop =这实质上是一个当前存储库保存的关于在远程服务器上开发分支。当您执行 fetch 或 pull 时，它会通过远程更改进行更新，并且在成功完成 push 。

现在，当您执行 git pull ，发生两件事情。这是因为 git pull 本质上是其他两个git操作的别名： fetch 和 merge ：



• fetch - 带来所有新的提交如果有的话）从远程存储库传输到本地 origin / develop 分支。 $ c> - 接受新的提交并将它们应用到本地工作开发分支。这可能以两种方式之一发生：
  
  
  
  
  • 如果本地工作分支不包含发散历史（远程不知道的新提交），则它只是提前发展开发分支指针，这样做指向 origin / develop 中的最新提交。这被称为快速合并。
  如果开发人员有一些他自己的新提交，它们不存在于远程回购中，并且因此而不是在 origin / develop 分支中，然后进行常规合并，这意味着有一个新的提交，包含两个分支的更改。默认情况下，git将这些消息分配给这样的提交：将https://bitbucket.org/abc/xyz的开发合并到开发。
  
  
  
  
  

  所以，这种情况是非常普遍的。

  
  
  

  现在，如果这种情况经常发生，并且您不希望看到非常复杂的提交历史记录图表，其中包含我们正在讨论的提交的提交，请尝试查看使用 rebase 代替合并。

  
  
  

  您可以通过两种方式（从远程服务器获取更改时）执行此操作：
  
  

  
  
  • git fetch; git rebase
  
  
  • git pull --rebase
  
  
  
  

  I awoke this morning and looked at the commit history of one of my dev team's private repositories on BitBucket. I saw this:

  Anonymous committed fcde879 MERGE

  Merge branch 'develop' of https://bitbucket.org/abc/xyz into develop

  This is, uh, somewhat unusual. My guess was that this was pushed from a new machine that didn't have git configured properly. Still, I was not sure why it was doing this. On BitBucket, it shows two separate hashes as the commit parents, but it does not have the "view raw commit" option of other commits.

  I checked out that branch, pulled, and looked at the log manually.

  sidious@DS-1:/path/to/repo$ git log -1 --format=raw
  tree 2931d14f48e61eaf0bbe0660af5b5dd76c07f063
  parent 6bb38dee681df7620ffa42b6790641a7873166f2
  parent f59c82e19e3e79310a53e273bab78139c49ff063
  author root <root@somemachine> 1437069530 +0000
  committer root <root@somemachine> 1437069530 +0000
  
  Merge branch 'develop' of https://bitbucket.org/abc/xyz into develop
  

  As far as I can tell, the 6bb parent is on the develop branch and the f59 parent appears to be from a different branch. It is kinda hard to tell what is going on.

  I searched but could not find an answer, and I need to get back to the grind, thus I posit my query here: why is git merging a branch into itself? Or, rather, why is this nomenclature being used as the commit message?

  解决方案

  This scenario is not unusual.

  The key here is that the branches being merged are different: it's the remote repository's develop branch being merged into the developer's local (working) develop branch.

  In the developer's local repository there are two distinct branches:

  • develop = The branch he/she is currently working on. The new commits go here.
  • origin/develop = This is essentially a snapshot that the current repository holds about the state of the develop branch on the remote server. It gets updated with the remote changes when you do fetch or pull, and with the local changes after a successful push.

  Now, when you do git pull, two things happen. This is because git pull is essentially an alias for other two git operations: fetch and merge:

  • fetch - brings all new commits (if any) from the remote repository to the local origin/develop branch.
  • merge - takes the new commits and applies them to the local working develop branch. This can happen in one of two ways:
    • if the local working branch does not contain divergent history (new commits that the remote does not know about), then it simply advances the develop branch pointer ahead, do that it points to the latest commit in origin/develop. This is known as a fast-forward merge.
    • if the developer has some new commits of his own that are not present in the remote repo, and, therefore not in the origin/develop branch, then a regular merge is done, meaning that there's a new commit, containing the changes from both branches. By default, git assigns messages like these to such commits: Merge branch 'develop' of https://bitbucket.org/abc/xyz into develop.

  So, the scenario is a pretty common one.

  Now, if this happens very often and you don't like to see very complex commit history graphs containing commits like the one we're talking about, try looking into using rebase instead of merge.

  You can do this two ways (when getting the changes from the remote server):

  • git fetch; git rebase
  • git pull --rebase

  这篇关于为什么git将一个分支合并到自己？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！