我试图合并两个不同的分支,但git告诉我,一切都是最新的 [英] I'm trying to merge two different branches, but git tells me that everything is up-to-date

查看:406
本文介绍了我试图合并两个不同的分支,但git告诉我,一切都是最新的的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是git noob,我知道我在这里错过了一些基本的东西。我有三个分支:master,feature1和feature2。没有两个分支是相同的,但是从一个分支合并到另一个分支的任何尝试都会导致最新消息。正如你可以想象的,我已经完成了feature1和feature2的工作,现在我只是想将这个工作合并到我的主人。



这是我目前的工作图表看起来像:

  * c719e79 master 
| \
| * 3f38259 feature2
| * 4e2af8c
| * a6ee18c
| * 2339052
| * 2e31d49
| * 2586659
| * 8b4a194
| * 56200c1
| * 97598e3
| * c28bc8d
| * 68b2e2f
| * 1ad4ad8
| * 3d5f4ad
| * 83435ca
| * 4049428
| * 581134a
| * 6e5aa2d
* | 2c88093
| /
* 3130ec9 feature1
* 54a5311 INITIAL COMMIT

任何想法?






更新



VonC - 解释有道理,但我的git回购仍然没有。当我切换到我的主分支,然后运行$ git diff --stat feature2,我得到以下输出:

  $ git diff --stat feature2 
File1 | 2 + -
File2 | 6 +++ ---
File3 | 4 ++ -
File4 | 2 + -
File5 | 2 + -
5个文件已更改,8个插入(+),8个删除( - )

如果我为feature1运行相同的命令,我会得到更长的文件列表。所以...我仍然告诉我我是最新的,但每个分支中的文件都不同。






更新2



@Scott - 好的,我认为您的回应有助于澄清我的问题。我知道合并会不是使所有分支都相同,但只会更新我所在的分支。不过,看起来我的提交已经失序了,或者什么。换句话说,feature2分支上存在我想要出现在我的主分支上的更改。 Git必须认为我主分支上的文件版本是正确的(不管是什么意思)。当我认为目前在master上的变化是最新和最大的变化时,我该如何让Git将feature2分支上的差异提交给我的主分支?






UPDATE 3(final)



嗯,我非常感谢你们所有试图帮助我的人。我想出了一个解决它的方法,但我从未真正知道如何去做我想到的事情。



在考虑了一些你的想法之后评论,我做了rebase。提交历史记录的图表与您所期望的一样是一条直线。然而,这个麻烦并没有消失:我的feature2分支在一次提交之后在master的后面,但它包含的代码实际上使它成为最新和最伟大代码的分支。尝试合并分支没有做任何事情。最后,我决定从我的feature2分支创建一个新的分支,并将其称为最新。所以我想,最后,我很感谢分支git的容易程度。但很明显,我错过了一些东西......



再次感谢所有人。

解决方案

在分支master上,我使用git merge feature1和git merge feature2


IMO发生了所谓的FF(快进) - Merge。



来自MAN- Page



git合并定义:
$ b


git-merge - 将两个或更多的开发历史结合在一起


发生了什么:


FAST-FORWARD MERGE

通常,当前分支头是指定提交的祖先。这是最常见的情况,特别是>从git pull中调用时:您正在跟踪上游存储库,您没有提交本地更改,>现在您想要更新到较新的上游修订版。在这种情况下,不需要新的提交来存储>组合历史;相反,HEAD(连同索引)被更新为指向指定的提交
,而不创建额外的合并提交。

这种行为可以被抑制与--no-ff选项一起使用。


Source-Link

Excursion:Additional有关分支机构的信息

由于分支机构不过是指向提交的指针AND feature1 / feature2 master 的祖先(如前所述),没有理由'复制'提交(并因此提交'历史)。将 master -branch(-pointer)重新指向上次提交的性能更高。



为什么master-branch-pointer不在 3f38259 commit中?



I 'm不太清楚,但我想:

  git merge feature1 

具有默认打开的自动提交选项(显式: - commit )。所以创建一个提交。此外,在 master -branch中有 2c88093 提交,但不在功能2中提交 -branch,避免将主分支指针放到 3f38259特征2 承诺产生类似于

  3f38259 feature2 master(*)

如果您要将 master 重新指向 3f38259 显式地分支,你会'失去'历史上的 2c88093 提交。


I'm a git noob, and I know I'm missing something fundamental here. I've got three branches: master, feature1 and feature2. No two branch is identical, yet any attempt to merge from one branch to the other results in an "up-to-date" message. As you can imagine, I've done my work on feature1 and feature2, and now I just want to merge that work back into my master.

Here is what my current graph looks like:

*   c719e79 master
|\  
| * 3f38259 feature2
| * 4e2af8c
| * a6ee18c
| * 2339052
| * 2e31d49
| * 2586659
| * 8b4a194
| * 56200c1
| * 97598e3
| * c28bc8d
| * 68b2e2f
| * 1ad4ad8
| * 3d5f4ad
| * 83435ca
| * 4049428
| * 581134a
| * 6e5aa2d
* | 2c88093
|/  
* 3130ec9 feature1
* 54a5311 INITIAL COMMIT

Any ideas?


UPDATE

VonC - the explanation makes sense, but my git repo still doesn't. When I switch over to my master branch and then run "$ git diff --stat feature2", I get the following output:

$git diff --stat feature2
File1      |    2 +-
File2      |    6 +++---
File3      |    4 ++--
File4      |    2 +-
File5      |    2 +-
5 files changed, 8 insertions(+), 8 deletions(-)

I get an even longer list of files if I run the same command for feature1. So... I still have it telling me that I'm up-to-date, but the files in each branch are different.


UPDATE 2

@Scott - Okay, I think your response has helped clarify my problem a little. I understand that merging will not make all the branches identical, but will simply update the branch that I'm on.

However, it appears that my commits have gotten "out of order", or something. In other words, there are changes that exist on the feature2 branch that I want to appear on my master branch. Git must think that version of the files on my master branch are the "right" ones (whatever that means). How do I get Git to commit the differences on feature2 branch to my master branch when it thinks that the changes currently on master are the latest and greatest?


UPDATE 3 (final)

Well, I'm very grateful to all of you who tried to help me out. I figured out a work-around that solved it just as well, but I never actually figured out how to do what I had in mind.

After thinking through some of your comments, I did a rebase. The graph of the commit history was a straight line like you would expect. The trouble didn't go away, though: my feature2 branch was behind master by one commit, but it contained code that actually made it the branch with the "latest and greatest" code. Trying to merge the branches did nothing. Finally, I just decided to create a new branch off of my feature2 branch and called that "latest". So I guess, in the end, I'm grateful for how easy it is to branch with git. But it's clear that I'm missing something...

Thanks again, everyone.

解决方案

While on branch master, I'm using git merge feature1 and git merge feature2

What happened was IMO a so-called FF(Fast-Forward)-Merge.

From the MAN-Page:

git merge definition:

git-merge - Join two or more development histories together

What has happened:

FAST-FORWARD MERGE

Often the current branch head is an ancestor of the named commit. This is the most common case especially > when invoked from git pull: you are tracking an upstream repository, you have committed no local changes, > and now you want to update to a newer upstream revision. In this case, a new commit is not needed to store > the combined history; instead, the HEAD (along with the index) is updated to point at the named commit, without creating an extra merge commit.

This behavior can be suppressed with the --no-ff option.

(Source-Link)

Excursion: Additional information about branches

As branches are nothing more than just pointers to commits AND feature1 / feature2 are ancestors of master (as mentioned before), there is no reason to 'copy' the commits (and therefore the commits' history). It's more performant to just re-point the master-branch(-pointer) to the last commit.

Why is the master-branch-pointer then not on the 3f38259 commit?

I'm not quite sure here, but I think:

git merge feature1

has the auto-commit-option (explicit: --commit) turned on per default. So a commit is created. Plus, there is the 2c88093 commit in the master-branch, but not in the feature2-branch, which avoids putting the master-branch-pointer just to the 3f38259 feature2 commit to produce something like

3f38259 feature2 master(*)

If you would re-point your master to the 3f38259 branch explicitly , you would 'lose' the 2c88093 commit in your history.

这篇关于我试图合并两个不同的分支,但git告诉我,一切都是最新的的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆