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

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?

Solution

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.