I've created a branch for experimentation. I've decided it was the direction I want to take, so want to put the changes into the master.
I don't want to merge, I'd prefer rebase, as this sounds exactly what I want (it to be like I was using master all along).
Looking at the documentation, it seems pretty simple (this is instruction from the docs):
However, there is another way: you can take the patch of the change that was introduced in C4 and reapply it on top of C3. In Git, this is called rebasing. With the rebase command, you can take all the changes that were committed on one branch and replay them on another one.
In this example, you’d run the following:
$ git checkout experiment $ git rebase master First, rewinding head to replay your work on top of it... Applying: added staged command
'experiment' in my case is the branch 'denormalized' which is already checked out (output from my console):
$ git status
On branch denormalized
Your branch is up-to-date with 'origin/denormalized'.
nothing to commit, working tree clean
Now, I call git rebase master
:
$ git rebase master
Current branch denormalized is up to date.
Okay, so that's not what I'm expecting according to the documentation. There also seems to be no changes to either branch:
The master is still what it was before the rebase. I can check it out and nothing has changed.
What am I missing?
While Matt Clark's answer is a correct procedure for your current situation, I think it leaves a couple things unclear; so I'll add the following:
The rebase command you issued is correct, but it doesn't do exactly what you think. If you had
A --- B --- C <--(masteR)
\
D --- E <--(branch)
(so master
has moved on since the branch point for branch
), and you want to combine branch
into master
without a merge commit, then a rebase would be the first step.
git checkout branch
git rebase master
(or the shorthand git rebase master branch
). This gives
A --- B --- C <--(masteR)
\
D' --- E' <--(branch)
and now a fast-forward merge (combining branch
into master
without a merge commit) is possible whereas before it was not. To cause the fast-forward you can either
git checkout master
git merge branch
(which will do a fast-forward because it can), or while still on branch
git branch -f master
which simply forces the master
branch to move to where you are (and is generally a more dangerous command but has the same effect here).
In your case, because the branch is already rooted at the tip of master
, the rebase is unnecessary and you can move straight to the ff merge.
Note that if you are sharing branches with other developers (e.g. through a remote repository) and it's possible that they're using a branch (e.g. because you've pushed it), then you should be careful about rebasing that branch (i.e. you need to coordinate with the other developers to do it). See "recovering from upstream rebase" in the git rebase documentation. https://git-scm.com/docs/git-rebase
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With