Is it possible to do a git-rebase after doing a git-commit

I started to rewrite some of the Perl programs from the NASM source files. I have already done a few commits to my own working copy, and I was wondering if I should have instead of doing git pull, if I should have been doing git rebase.

I have pretty much decided that I should have been doing a git rebase, but I don't know how to rework my repository to achieve that effect, or even if it is possible.

From stackoverflow

• 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

  Dustin : 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)

• It is possible, and the Git Magic tutorial will explain how to do it. But if anyone else has seen your branch, it is unsafe. Even if nobody else has seen your branch, let me urge you to reconsider.

  Why have rebasing? Why not just pull/merge?

  The purpose of rebasing is to rewrite history so that your repository reflects the way you believe your software should have evolved instead of the way it actually did. When is this important? When you are a junior member of a distributed development team, and you don't have commit privileges—instead, all you can do is submit patches to a gatekeeper and hope that they are accepted. To maximize the chances of acceptance, you want to rewrite history to make your patches as clean and clear as possible. Is the development model sounding familiar?

  Manoj Srivastava has written a fairly thoughtful analysis of rebase-vs-merge.

• 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.

• 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).

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