Discussion on: Up your Git game and clean up your history

Nice walkthrough. Rebasing is often painted as advanced, but I think it's best to play with it early on, and not fear it later.

Git rebase lets your remodel your history to your will. See it as a way to manipulate your list of commits on a given branch.
...
To do so, we'll use the interactive mode of git rebase, which lets us apply the rebasing with a nice interface.

Technically true, but I wouldn't phrase it like that. IMO, taken together these risk implying untrue things — that a branch's history can be arbitrarily rewritten with a plain rebase, that it's why rebase exists, and that --interactive just changes the UI.

I'd instead say:

git rebase allows you to replay the changes introduced in a set of commits on top of a specified base. It works by repeated cherry-picking (i.e. applying changes introduced by a commit on top of a different one). --interactive allows you to edit the changes before they're applied.

This leads to a special form of rebase — interactive rebase where the source branch is also the target — where you can arbitrarily rewrite a branch's history.

git-scm.com: Rewriting History

This very frequent scenario will have us rebase our second PR on master so that it gets the new code merged from the first PR.

Just to add context: rebasing works here, but merging master is likely better for PRs on a team.

• if there are conflicts, you'll only have to fix them once, rather than repeatedly across commits
• rebasing can cause reviewers to lose work
• you can't assume that others haven't checked out a PR branch
• it's the truth

I'd say only the first two are potentially serious, but I can't think of an upside that'd make it worth dealing with them.