Under what conditions should I rebase rather than merge?

Question

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?

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)