36

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?

David Wesby
  • 539
  • 1
  • 9
  • 19
Arnold Roa
  • 7,335
  • 5
  • 50
  • 69
  • 1
    Related: http://stackoverflow.com/questions/26024586/git-i-want-to-merge-a-branch-to-master-but-continue-working-on-the-branch – jub0bs Apr 21 '15 at 13:47

2 Answers2

24

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.

Gábor Angyal
  • 2,225
  • 17
  • 27
  • Is it bad practice to merge master into feature branch instead of rebasing? – Chaudhry Junaid Aug 12 '15 at 20:22
  • I prefer not rebasing, so +1 for this answer. – Basil Musa Aug 17 '16 at 12:06
  • 5
    Basil, why you prefer to not rebase? – Arnold Roa Nov 24 '16 at 18:42
  • 2
    Merging master/dev into feature and merge back feature into master/dev is a project killing. By doing this you take responsibility in your branch by committing these changes from master/dev to your branch. And then, when merging back your are "applying" your work + this commit from master/dev that you are not supposed to have. I found personally this method to be a bad practice and can lead to loss of code. If you are the only one working on your branch, then just rebase, or worth case scenario create a temp branch to cherry pick your branch's commit and the reset your branch on it. – Oleg G. Mar 04 '20 at 22:38
  • 1
    @OlegG. I guess we need to distinguish two cases here: Merging master into feature and then directly merging the feature branch back into master (preferrably through a pull request, possibly including deletion of the branch) is perfectly safe and provides a fully traceable history as opposed to rebase (sometimes you are forced to provide that). However, merging master into a feature branch somewhere in the middle, or several times can easily cause troubles when merging back to master, possibly with accidental loss of code as you said. – Tim Meyer May 18 '21 at 13:58
13

To keep a branch always up-to-date with master 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.

rbento
  • 9,919
  • 3
  • 61
  • 61
  • 6
    Both test1 and test2 are tracked (with all his commits) by a remote repository, I've heard that is not good to idea to do rebase for branches that have commits on remote repositories? – Arnold Roa Apr 21 '15 at 14:03
  • 2
    Yes, unless you do all of this before pushing, which is the idea. No problems with it at all. Try with a small project and see if it fits you. – rbento Apr 21 '15 at 14:10
  • I've had some strange experience with get rebase today. Imagine, I have version 1 in the master branch, then in feature branch I sequentially upgrade the app to v2, 3 and then 4 (that's where it stays in the HEAD of feature branch). Now, I'm doing git rebase master, get conflict (say, on "upgrade from v1 to v2" commit) and what do I see?? "Incoming change: v2" (okey). "Current change: v4"… WUT? What should I do here? I expected all my feature-branch commits be rolled back to the "branching point", then moving to master's current HEAD and re-aplying feature commits on top of it… – pilat Aug 19 '20 at 12:12
  • @pilat I see, maybe this link would help illustrate and clarify better on scenarios with which you may identify with: https://git-scm.com/book/en/v2/Git-Branching-Rebasing – rbento Aug 19 '20 at 22:17