+1  A: 

I've had success with the following method in the past:

For this method, I have added the following alias:

up = pull --rebase origin
  1. Branch your master branch to something like 'dev' or whatever
  2. Work in dev
  3. when you've finished adding and committing changes
  4. git up master
  5. switch to master
  6. git merge dev
  7. git push

When pulling in changes from the remote repo:

  1. switch to master
  2. git up
  3. switch to dev
  4. git up master

YMMV

Mr. Matt
Your alias seems to be a less standard way to do `git config --global branch.master.rebase` along with `git config --global branch.autosetuprebase always` (you can always fetch and merge if you want to do so for a particular branch)
Dustin
+3  A: 
Norman Ramsey
A: 

You should be able to undo your last merge by changing the branches like this:

git branch your-changes <reflog of "Reworked test files...">
git branch -f master remotes/origin/master

After that you can try rebasing.

Esko Luontola
+1  A: 
  1. Ensure that the current commit is the merge commit: git log
  2. First we re-set the master to the previous commit (the one right before the merge): git reset HEAD^
    • HEAD^ means: 'the commit before the commit referenced by HEAD'
  3. Now you can do a normal rebase: git rebase origin/master

Next time I recommend to do a git fetch and then the rebase as step 3.

I would recommend to create a small tarball of your current git repo, just in case the rebase goes wrong. You'll do that less often when you feel more confident (and usually you can fix almost everything with git, but sometimes the tarball is faster).

reto
A: 

As a followup to Dustin's reply, it should be "git config --global branch.master.rebase true".

Collin Anderson