Should I merge master into a branch, and then merge back into master?

Question

I have the following branches:

• master
• test1, which was created from master
• test2, which was also created from master.

I've done multiple commits on the test1 branch, and also, since I created the test1 branch, I've created multiple commits on master.

There are also commits on test2, which I intend to merge back into master later.

The thing right now is that I need my changes from master, and if possible, from test2 on test1.

I want to know if I can merge master into test1, so I get the commits from master on test, and after I finish my feature on test1, merge that again to master. Is that possible? Or it will raise conflicts?

Is it possible to merge also test2 into test1, then merge test2 into master, and, finally, merge test1 into master?

Will Git understand that some commits are already merged into the branch that is being merged?

Answer 1

I want to know if I can merge MASTER into TEST1, so I get the commits from master on test, and after I finish my feature on test1, merge that again to MASTER. is that possible? or it will raise conflicts?

That exactly how it is done. You may get conflict when you merge master into test1, that you have to resolve manually. After that you should be able to merge test1 into master without conflicts.

If thats possible, is possible to merge also test2 into test1, next merge test2 into master, and next merge test1 into master?

It is possible, but not advisable. Instead merge master into test2, then test2 back to master. (The same what you have done to test1.)

After this all your changes should be in master.

Will git understand that some commits are already merged into the branch that is being merged?

Yes, unlike SVN, Git is aware of such commits.

Answer 2

To be always up to date with and raise no conflicts when merging back to it you could do the following:

git checkout test1 git rebase master 

At this point you will be up to date with master and have your commits on test1 on top of it.

rebase would do the following:

• Pick all commits on test1 after a point it differs from master and put in a temporary area.
• Pick all commits from master after the point it differs from test1 and bring them to test1. At this point both branches are up-to-date.
• Then it will pick up test1 commits from the temporary area and apply them on top of test1. At this point test1 will be up-to-date with master and have its commits on top. When it happens, any conflict that may exist will show up, and you can resolve them.

After this, merging back to master will be a fast-forward.

git checkout master git merge test1 

What I like about this approach is the following:

• It's simple.
• Makes easy keep up-to-date with branches.
• Eliminates merge commits, because conflicts are resolved upon rebase.

I've applied this for quite some time, and it seems to fit what you're trying to accomplish.

A visual explanation of how rebasing works may also be helpful.