Document the squash-and-merge workflow of pull requests

.github/pull_request_template.md

@@ -1,5 +1,7 @@
 <!--
 * Read [`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md).
 * Include a screenshot or gif (if applicable).
-* Add a line to `CHANGELOG.md` if this is a big enough change to warrant it
+* Add a line to `CHANGELOG.md` if this is a big enough change to warrant it.
+
+Add any improvements to the branch as new commits, to make it easier for reviewers to follow the progress. All commits will be squashed to a single commit once the PR is merged into `main`.
 -->

CONTRIBUTING.md

@@ -38,6 +38,10 @@ You can use [bacon](https://github.com/Canop/bacon) to automatically check your
 ### Other
 You can view higher log levels with `export RUST_LOG=debug` or `export RUST_LOG=trace`.
 
+## Pull Requests
+We use [Trunk Based Development](https://trunkbaseddevelopment.com/), which means we encourage small, short-lived branches.
+
+All PR:s are all merged with [`Squash and Merge`](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-commits), meaning they all get squashed to just one commit on the `main` branch. This means you don't need to keep a clean commit history on your feature branches. In fact, it is preferable to add new commits to a branch rather than rebasing or squashing. For one, it makes it easier to track progress on a branch, and secondly it is more difficult to collaborate on a branch if one user is rebasing it.
 
 ## Rust code