Here is, roughly, our structure of work using git, for web development. We have a master branch, and individual or groups of work are done seperately in branches, then merged in.

  1. A ticket (or several) comes in.
  2. We create a branch on our local development repository, and push it to origin.
  3. We fix the tickets in code, commit the work and push to origin.
  4. Once we're happy with our work, we pull the branch down to a repository on our UAT / Staging server and check it out for the client to review.
  5. The client approves the work.
  6. We go back to our local development repository, we check out master, merge the branch, and push to origin.
  7. We create a tag from master afterwards.
  8. We then go on the live server, pull master and move/update the tag to the new one.

There are 7 of us, working on about 15 projects or so throughout the year. Generally, one person is sufficient to work on a project at any one time, but sometimes two people might work in separate branches with a view to merging into the master branch around the same time.

Generally we think merging is best because it, as I understand, preserves a development history with regard to what was merged and when. Whereas rebase seems to completely destroy this and linearize the master log.

Why would, if this assumption is correct, someone want to use rebase? Is it only for extremely busy projects that are constantly being branched and merged and there needs to be a guarantee that merges are successful - so developers can test out adding master to their work and resolve conflicts before merging back in?

1 Answer 1


rebase may only be used on work in progress that was not merged anywhere yet (not even into your colleagues. Once the work was merged, you must not rebase (or amend) it. If you try, you'll create unbelievable mess.

For work in progress however rebasing is often appropriate. It is used to keep merges out of the work in progress and to keep the work in progress organized in logical rather than historical steps. Which is useful if:

  1. Somebody will be reviewing the changes before integrating. Larger changes are much easier reviewed in series of logical steps, but they must be logical steps.
  2. You want to similarly review the changes yourself to be sure you didn't do any unrelated or inappropriate changes.
  3. You have some experimental changes among changes you need to integrate (the rebase -i lets you reorder the changes).

(Linux development always included reviews that required the changes presented in patch series, which is what inspired git rebase, especially the interactive one)

  • 1
    Understood, so a good example of where this is useful is if you branched from master much earlier in the year to do some work; and several months later, you want to return to it and publish - but master's moved on so much that it would be more logical to rebase the branch, get your commits on the end for reviewing and checking they don't conflict with the updated master? After that, you know you can safely merge and it'll just do a fast-forward.
    – njp
    Jul 30, 2013 at 13:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.