CODEWITHSUNDEEP
gitbranching-and-merging
Vytautas
Vytautas

Reputation: 462

In Git, after merging back and forth, why aren't the branches at the same point?

We have been doing a project with Git according to what I understand to be a pretty standard branching model, described here: http://nvie.com/posts/a-successful-git-branching-model/

We have started with "master" and branched "develop" from it. There were lots of commits to "develop", and then we branched "release-1" from "develop". There were some commits to "release-1", then we merged "release-1" to "master", and again merged "release-1" to "develop". Then we deleted "release-1".

Now I would expect "master" and "develop" branches to be at the same point. And they do have the same files, but according to branch graph they have completely different histories, with the only common point being the very first commit in the repository.

So two questions:

1) Why don't they have the same history / why aren't they at the same point?

2) How can we fix it? Should we force merge "develop" to "master" or "master" to "develop"?

Upvotes: 2

Views: 1763

Answers (2)

LeGEC
LeGEC

Reputation: 51830

It is normal behavior for git to create different commits on different actions :

A commit keeps track of a bunch of information : its parents, its author, its creation date, its committer and last commit date.

If any of these informations are different, git will create two distinct commits.

For example : when merging release-1 into master, and then release-1 into develop

  • if the starting point for master and develop was not the exact same commit, the two merge commits will not have the same parents ;

  • unless you run both commands at the speed of light, they will not have the same timestamp.

The content of the files in a commit is called its tree.

git also keeps a hash of the content of a commit, which you can view using :

git rev-parse master^{tree}
git rev-parse develop^{tree}

You can confirm that the two commits have the exact same contents by looking at their tree hashes.

If you want to have develop and master point at the same commit, you can hard set develop to master :

git branch -f develop master

In your merging process, you could have reached the same state by :

  1. merging release-1 into master

  2. tell git to "fast forward" develop to master :

    git checkout develop
git merge --ff-only master

    with git merge --ff-only :

    • git will first check if master's history contains the full history of develop,
    • if it does, it will move develop to master (instead of creating a new commit),
    • otherwise, it will print a warning and leave develop unmodified.

Upvotes: 2

Chris
Chris

Reputation: 8656

As LeGec says, a commit is generated from a various information including the author, committer, parent commit, and more that should make it unique/identifieable.

From your description it sounds like this is your situation:

Master  | M1 -------------------------> M2 (merge commit)
--------    \                          /
Release |    \                R1 -> R2
--------      \              /         \ 
Develop |      D1 -> D2 -> D3 --------> D4 (merge commit)

As you've described in your case, the files within M2 and D4 will be the same, however their parent commits, and the time at which they were created, will be different.

That is unlikely to cause you issues as your work will continue on develop and you can happily follow the release workflow next time. Since you aren't committing on master independently, you shouldn't run into merge conflicts.

If you wished to "fix it", that is give them a common commit, you could merge master into develop, but it won't really gain you anything except an additional merge commit.

Master  | M1 -------------------------> M2 (merge commit)
--------    \                          /   \ 
Release |    \                R1 -> R2      \
--------      \              /         \     \
Develop |      D1 -> D2 -> D3 --------> D4 -> D5 (merge commit)

Note, this is assuming you are not performing fast forward merges.

Upvotes: 5

Related Questions