On private development branches, favour rebase over merge, and encourage rewriting history for a clean tree

[axmmisaka]

I've complained in the past on Zulip about the cleanliness of our git history trees.

Since our contributing guideline is rather indicative, I think it might be worth it to outline some suggestions to make our git history cleaner, such as:

1. If working on a branch which nobody is actively using in a productive environment and pulling from the main branch is common, prefer git pull --rebase instead of merge to keep the history linear
2. Be comfortable to rewrite history by using rebase with squash/fixup/git commit --amend when solving linting/styling/typo problems, instead of have several "fix typo" or "minor fix" commits hanging around
3. Configure pre-commit hooks and ensure each commit is linted, instead of linting everything in one commit

[lhstrh]

The problem with pre-commit hooks is that we can't enforce them -- we can only suggest them. I agree with you that we can do a better job maintaining a linear history.

[cmnrd]

Would you like to draft a section for the guidelines? I don't think we should write a complete git tutorial, but we could describe some best practices and insert pointers to existing tutorials describing the git features in more detail.