1

I've redacted the image below for privacy reason, but basically I have two branches that I am trying to get on the same commit. The commit with the tag 4.3.1.11 is on a different branch than then one with the tag 4.3.1.13. I've tried merging 4.3.1.11 into 4.3.1.13 but nothing changes.

I'm simply trying to get both branches on the same commit.

How do I do this. I know similar questions have been asked, but I do not see a scenario like mine that has been answered.

enter image description here

John
  • 1,310
  • 3
  • 32
  • 58
  • Take a look at merge-strategies (ours/theirs) – Jonathan.Brink Mar 30 '16 at 19:34
  • what happened to this question? – John Mar 30 '16 at 19:35
  • The question doesn't make a lot of sense. In git, a branch (a branch name, anyway) is just a pointer to a commit. If you want two branch names to point to the *same* commit, you just make two branch names that point to the same commit. See http://stackoverflow.com/q/25068543/1256452 – torek Mar 30 '16 at 21:12
  • Actually the question makes a lot of sense. See answer below. This question had many comments between me and @Johnathan.Brink which are no longer here. I don't know what happened to all of the comments. – John Mar 31 '16 at 13:51

3 Answers3

0

You simply have to merge the changes of you 2 branches.

# Checkout the branch you want to merge the code into
git checkout branchA

# now merge the code form the other branch into this branch:
git merge branchB

Now branchB will contain all the code of branch A as well.

CodeWizard
  • 128,036
  • 21
  • 144
  • 167
0

To move the pointer of a branch to a different commit simply use:

git branch -f <branch name> <commit number>

from: Git: move branch pointer to different commit without checkout

Community
  • 1
  • 1
John
  • 1,310
  • 3
  • 32
  • 58
0

There may be a confusion with the terms Merge and Commit. In git, a commit, is simply a delta, between 2 changes in context. A Merge is a symbolic commit, which represents a single entity, that combines the branches of 2 parents.

That's different that to revision systems like SVN, where a merge is actually a thing. In git, it's safer to consider it a strategy.

So if you have a point in the repo A and another point B, they will, via some path, connect to each other (unless they're on 2 separate orphaned branches). In telling git to create a point C, which may be considered as an extension to the branch A or B, but which is a symbolic merging of either A into B or B into A, git will consider all the differences along the path, back up the parentage of A and B, until it finds a shared parent.

So if O-A and O-B the path to create O-A-C (where C is your merge) considers B-O-A as the path.

That's confusing because you might consider O-B as what you want to merge, and have forgotten about O-A. But it's logical.

In your example, if 4.3.1.11 is A, origin/develop is B and 4.3.1.13 is G, you can see your branch tree is simply A-B-C-D-E-F-G. So to go from A to G, you simply advance along the tree (you can fast forward).

To put that another way, G contains A already, it just has the deltas B-G already applied, so clearly the net effect of a strategy, is git to say 'nothing to do'.

In your example 4.3.1.11 and 4.3.1.13 are tags, so by definition shouldn't move. As you commented in your answer, you can use git branch -f to move a branch pointer to a new commit, but that's not a merge. You could also use git revert to remove a commit (which asks git to create an inverse commit, and add that to the chain)

sibaz
  • 1,242
  • 14
  • 26