I'm trying to merge two different branches, but git tells me everything is up to date
I am a git noob and I know I am missing something fundamental here. I have three branches: master, feature1 and feature2. Neither branch is identical, but any attempt to merge from one branch to the other results in an "updated" message. As you can imagine, I've done my work on feature1 and feature2 and now I just want to merge this work with my master.
This 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 - explanation makes sense, but my git repository still doesn't work. When I switch 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 on function1. So ... I am still told that I am up to date, but the files in each branch are different.
UPDATE 2
@Scott - Ok I think your answer helped clarify my problem a little. I understand that the merge will not make all branches the same, but will just update the branch I am included in.
However, it looks like my commits got "out of order" or something. In other words, there are changes that exist on the feature2 branch that I want to display on my master branch. git should think that the version of the files on my master branch is "correct" (whatever that means). How do I get git to commit the differences in feature2 on my master branch when it thinks the changes currently on master are the most recent and largest?
UPDATE 3 (final)
Ok, I am very grateful to all of you who tried to help me. I realized it was just as good, but I never really figured out how to do what I had in mind.
After thinking through some of your comments, I rearranged it. The commit history graph was straight, as you would expect. The problem didn't go away though: my feature2 branch was master by one commit, but contained the code that actually made it a "latest and greatest" code branch. Attempting to merge the branches did nothing. Finally, I just decided to create a new branch of my feature2 branch and called it "latest". So I think in the end I am grateful for how easy it is to jump into with git. But it is clear that I am missing something ...
Thanks again.
source to share
"Already updated" means that one branch is the ancestor of another, all changes from one branch are already in the other.
From the git merge
man page :
If all named commits are already ancestors of HEAD, it
git merge
will come out early with the message "Already updated".
Here HEAD from feature1
is an ancestor master
( master
has new work from feature1
HEAD).
Thus, git merge feature1
will result in the message "Already updated".
As for feature2
, your graph shows that it was merged at some point in the master
.
Trying to repeat the merge will also result in "Already updated".
source to share
While on the master branch I am using git merge function1 and git merge function2
What happened is IMO - the so called FF (Fast-Forward) -Merge.
From MAN-Page:
git merge definition:
git -merge - Join two or more development stories together
What happened:
FAST-FORWARD MERGE
Often, the current branch of a branch is the ancestor of a named commit. This is the most common case, especially when called from git pull: you are tracking an upstream repository, you are not committing local changes,> and now you want to upgrade to a newer upstream version. In this case, a new collection is not required to store> the combined history; instead, the HEAD (along with the index) is updated to point to the named commit, without creating an additional merge.
This behavior can be suppressed with the -no-ff option.
( Source-Link )
Guided Tour: Additional Information on Branches
Since branches are nothing more than just commit pointers AND feature1
/ feature2
are ancestors master
(as mentioned earlier), there is no reason to "copy" commits (and thus commit history). It is more efficient to just reassign master
-branch (-pointer) to the last commit.
Why is master-branch-pointer rather than 3f38259
commit?
I'm not really sure here, but I think:
git merge feature1
has an auto-commit (explicit :) --commit
option enabled by default. This creates a commit. Also, there is a 2c88093
commit in master
-branch, but not in feature2
-branch, which allows you not to put the master
-branch pointer just in the command 3f38259 feature2
to create something like
3f38259 feature2 master(*)
If you have explicitly pointed your branch master
to a branch 3f38259
, you will lose a commit 2c88093
in your history.
source to share
The problem is you expect feature1 and feature2 branches and masters to change when you merge them. However, the merge only affects the branch you are currently on. If you want all three branches to point to the same commit snapshot, you can run
$ git checkout feature1 $ git merge master $ git checkout feature2 $ git merge master
This will update feature1 and then feature2 to where the master is, and you won't get any merge conflicts as they are both the direct ancestors of the master.
The important point is that when you merge a branch into another branch, it only changes the branch you are on (the one you merge with), not the branch you merge into. In other words, if you are currently on your "master" branch and you have merged into "feature1", it updates "master" but not "feature1".
source to share
You can checkout the branch master
, make sure all your changes are committed, then try
git pull . feature1 feature2
But I'm not really a git expert, so I couldn't tell exactly what this would do. I mean, I know it should combine feature1
and feature2
in master
, but I can't guarantee that it will combine them exactly the way you want.
I would suggest backing up your storage first, just in case. Although, I suppose you could always git reset --hard HEAD^
after that if something goes wrong.
source to share