| | 205 | == Merging of Pull Requests == |
| | 206 | |
| | 207 | Rationale: We should try to have clean history and good commit messages. This helps really a lot when you try to understand why something is implemented the way it is. |
| | 208 | |
| | 209 | When a Pull Requests (PR) has multiple commits, the merge commit is more or less mandatory because if you don't have it, you can't use `git revert`. |
| | 210 | |
| | 211 | === PR with single commit === |
| | 212 | |
| | 213 | **Proposed**: when a PR only has a single commit, the "merge commit" doesn't offer anything and it can be avoided by rebasing the feature branch. |
| | 214 | |
| | 215 | === PR with multiple commits === |
| | 216 | |
| | 217 | **Proposed**: it is a good idea to try to squash the accumulated commits in a PR before merging, especially if those are trivial fixes. |
| | 218 | |
| | 219 | As an example, PRxx contains 5 commits. Esp. in case that several commits of them are trivial fixes that only add noise to the history, "squashing" those results in a cleaner history and, among other things, makes it easier to use `git bisect` and `git blame`. |
| | 220 | |
| | 221 | Importantly, not always commits of each and every PR need to be squashed before merging. When extensive changes are being made, it often makes sense to keep them unsquashed (e.g. to make reviewing easier), but trivial fixes should still be squashed to the main commits. |
| | 222 | |
