Does git merge reapply commits onto another commit?

Question

I'm 15 and have just started using source control systems to manage my code a little better, so I'm a little new to this stuff. Right now I have this repository:

[a]---[b]---[d]---[f] master
        \
         \
          [c]---[e]   develop

I want to wind up here:

[a]---[b]---[d]---[f]---[g]  master
        \               /
         \             /
          [c]---[e]---/      develop

where g is equivalent to performing commits [c] and [e] on [f]. This is git checkout master; git merge develop, right?

Answer 1

The picture you drew looks like the result of git merge, but your description of what you want to happen sounds like git rebase.

Borrowing from the "Rebasing" chapter of the git community-book, if you're on the mywork branch and say

$ git merge origin

you'll get

Think of a merge as cramming together two different snapshots: in this case C4 and C6 came together to make C7.

Rebase creates a tree that looks just like C7, but its history looks completely different. Say instead of the merge, you gave the command

$ git rebase origin

you'd get

When you find yourself wishing, 'I really wish I'd created the mywork branch at C4 instead of C2,' git rebase is the djinni that will grant it.

You could also think of rebase as cutting a branch out of your history and transplanting it on a different point. Don't miss the subtle change from C5 and C6 to C5' and C6'. Although the trees will look the same, they'll have different parents, thus changing their git identities.

Answer 2

You want git checkout master; git merge develop.

This is because git merge takes the name of a branch that you want to merge into the currently checked out branch. Thus, you check out your desired destination branch (master) and then merge the other branch into it (develop).

If you take a look in the first "Description" section on the git-merge man page, you'll see a diagram almost identical to yours (albeit flipped vertically) that describes this.