On: Git commands you probably do not need

[kramerger]

Maybe,

... although these days rebase is mostly handled on the server. By the time your PR is reviewed its already behind main so server side needs to rebase it anyway before merge can be done.

If you do rebase to squash commits, most projects prefer you didn't

[nicoburns → kramerger]

> If you do rebase to squash commits, most projects prefer you didn't

I've been using rebase to fix bugs in earlier commits (on a feature brannch that hasn't yet been merged into main) so that you don't end up with broken commits in the history.

I've also been using filter-branch to retroactively apply autoformatting to all commits in the branch.

[xmcqdpt2 → kramerger]

You should rebase instead of merging when pulling though otherwise you contaminate your branch with merges that mess up the git log.

Alternatively you can squash the merges before pushing but this still requires rebasing.