How do you rebase the current branch's changes on top of changes being merged in?

Question

Okay. If I'm on a branch (say working), and I want to merge in the changes from another branch (say master), then I run the command git-merge master while on the working branch, and the changes get merged in without rebasing the history at all. If I run git-rebase master, then the changes in master are rebased to be put on the top of my working branch. But what if I want to merge in the changes from master but rebase my changes in working to be on top? How do I do that? Can it be done?

I could run git-rebase working on my master branch to put my changes on top in the master branch, but I'd like to be able to do that in my working branch, and I have no idea how. The closest that I can think of doing is creating a new branch from master and then rebase working's changes on top of that, but then I'd have a new branch instead of altering the working branch.

Solution 1

You've got what rebase does backwards. git rebase master does what you're asking for — takes the changes on the current branch (since its divergence from master) and replays them on top of master, then sets the head of the current branch to be the head of that new history. It doesn't replay the changes from master on top of the current branch.

Solution 2

Another way to look at it is to consider git rebase master as:

Rebase the current branch on top of master

Here , 'master' is the upstream branch, and that explain why, during a rebase, ours and theirs are reversed.

Comments

[hobbs]

@Jonathan it's cool. This is a little bit of a tricky topic. By the way, git rebase working would move master's changes (after the point that working branched off) to be on top of the working branch — but that's not a very sensible thing to do to master :)

[AVIDeveloper]

That also explains why LOCAL and REMOTE are reversed. Thanks.

[VonC]

@AVIDeveloper on LOCAL and REMOTE, you can also read stackoverflow.com/a/3052118/6309

[AVIDeveloper]

@@VonC: Thanks. Yep, after spending an afternoon mumbling to myself "REMOTE is my branch.. LOCAL is not mine", it all sunk in. Honestly, I would've preferred seeing the branch names (or abbrev. SHA) instead of REMOTE/LOCAL/ours/theirs/mine. My thoughts are the same regarding the git difftool's horrible left/right. Kinda off topic, but for difftool I stick to git-meld and enjoy names like 'working-dir', 'stash@{0}', as so on.

[JavaSa]

@VonC: Can you explain how can it be that after we do: git checkout branch_to_update git rebase master I get in git log the commits of master on top of local branch, instead the opposite?

[VonC]

@JavaSa That is strange, unless the rebase was not properly completed? You might need to ask a separate question with more details in it.

[Carmine Tambascia]

The problem arise regarding conflicts(file in which have different line conflicting, or code that has been modified in both branch), so resolve them is the most tricky part, as you will need to decide what keep for each file, this is especially true for large changes

[VonC]

@CarmineTambascia I agree. git rerere, but ultimately, it is a project management/communication issue, which will help minimize concurrent development on a common file.