git merge or rebase - vastly different master

Question

I had been working on a feature branch for some time now and when I try to merge to master, I notice the master has changes significantly, with some files in my branch have been moved to different folders on master and I have new files in my feature branch too.

I understand that I have two options, either to merge or rebase, but appreciate any input as to what would be the easiest option.

The branch I am working on is exclusive to me, so no problem re-writing history but master is obviously used by others and I am worried polluting it with history of changes from my feature branch

appreciate the step by step guide of this process as I am new to GIT and do not want to mess up things for others.

thanks

"I am worried polluting it with history of changes from my feature branch" This will only happen if you merge your feature branch into master. You should merge the other direction: master into your feature branch. Or alternatively rebase your feature branch on top of master. — Code-Apprentice, Feb 17 '16 at 00:36
ok thanks . so if I merge master into my feature branch, all the previous commits on master will be included in feature and that will be combined to one merge commit when the feature is merged to master ? is this correct ? — lollah mullah, Feb 17 '16 at 00:43
also the commands are git checkout feature and git merge master followed by conflict resolution and git add / git commit / git push — lollah mullah, Feb 17 '16 at 00:43

Massey101 · Answer 1 · 2016-02-17T01:02:18.707

1

Your best bet when your are working on a branch that is exclusive to you is to rebase. This will also allow you to deal with conflicts one change at a time and result in a cleaner history. The only reason you might not want to do that is if you have a company/team policy of doing no-ff merges on master. The process is this:

git checkout <feature>
git rebase master
...
    *potentially resolve conflicts*
    git add .
    git rebase --continue
    *repeat*
...
git checkout master
git merge <feature>

Advantages:

Cleaner history (no merge commits)
Deal with conflicts one commit at a time

Disadvantages:

Cannot rebase a branch that others are working on
On large projects having only merge commits on master can actually be cleaner. ie: merge feature 1, merge hotfix 2, merge feature 3.

However, in this case of Disadvantage 2 you could still rebase your changes and do a merge with --no-ff, that way you still get Advantage 2.

edited Feb 17 '16 at 01:02

answered Feb 17 '16 at 00:49

Massey101

346
1
9

1

You should probably include a step for the inevitable conflict resolution. – Code-Apprentice Feb 17 '16 at 00:50
but what are the adv and disadv... the differences are massive and I need safest and easiest option.. – lollah mullah Feb 17 '16 at 00:53
The only disadvantage is that you can't rebase a branch that other people are using + the aforementioned no-ff merges (but that only applies to big projects) – Massey101 Feb 17 '16 at 00:54

score 0 · Answer 2 · answered Feb 17 '16 at 02:31

FWIW, my vote would be to merge instead of rebase. It makes it clear which commits contributed to your feature. Also, if you screw it up, you only have to revert one commit (the merge commit) to undo it. Plus, you are bound to have conflicts, and having a single merge commit to examine makes it easy to see if the conflicts are resolved correctly.

git merge or rebase - vastly different master

2 Answers2