Rebasing

Rebasing takes the commits that are only on your branch and replays them on top of another branch. The result is a straight line: your work appears to have been done after theirs, rather than beside it.

What it is good for

A branch that is three commits behind main and has two commits of its own can be rebased so that those two sit on top of the current main. The history reads in order, and nothing has to be reconciled when it lands.

Innesta’s own merge still makes a merge commit — it passes --no-ff — so rebasing first does not remove the join, it removes the interleaving.

What it costs

Your commits are replaced. A rebase does not move commits, it makes new ones with the same changes and different ids. Everything that follows from that follows:

• If you have already pushed the branch, the remote still has the old commits. Sending the rebased version needs a force push with lease.
• If someone else has your branch checked out, their copy and yours have diverged in a way that is awkward to reconcile.

The rule of thumb is the usual one: rebase work that only you have, merge work that other people have.

Conflicts during a rebase

A rebase applies your commits one at a time, so it can stop more than once — each commit is a separate chance to conflict. Innesta shows the same three-pane editor each time, and Continue carries on to the next commit.

A rebase Innesta started keeps the signing choice that was in force when it began, so a branch does not come out signed in patches. A rebase started elsewhere keeps whatever policy Git was given at the time.

Getting out

A rebase in progress can be abandoned, which puts the branch back where it was. And if one finishes and you wish it had not, the commits it replaced are still in the reflog.