views:

55

answers:

2

Hello,

As a integration test I would like to join several branches before merging them with my master.

All of them diverged from the master and make it's own way. It is a correct merging different branches with no direct-relationship (e.g. parent/child)??

Is there any good practise for rejoining branches??

Thanks in advance, Raul.

+1  A: 

If those branches come all from master, they do have a common ancestor

     y--y--y
    /
x--o--x--x--x--x--x--x
          \
           z--z--z

('o' being the common ancestor here)
In that case, a merge in an integration branch is a good approach (rebasing such long-lived branch would involve rewriting too much public history)

If the branches are truly separate, then a git grafts points could in theory allow for a common history: see How to merge two branches without a common ancestor?.
But that is not ideal, since the graft point is not committed.
A filter-branch might make the modification permanent, but that rewrite history.

VonC
I'd say this even more strongly: rejoining branches which have diverged from a common ancestor is not just good practice; it's *precisely* the purpose of `git-merge`.
Jefromi
A: 

If those branches come all from master, they do have a common ancestor.


But answering your question (but not your problem), it is possible to merge two histories without common ancestor, for example two different projects, using for example 'subtree' merge strategy of git merge.

To rebase one branch on top of the other that doesn't have common ancestor, you would need to use --root option to git rebase.

Jakub Narębski