On 30. Nov 2018, at 09:08, Joern Kottmann <[email protected]> wrote: > > In git you can rebase the PR on top of master and then commit it, and > this leads to a much clearer and easier to understand linear history > compared to merge every PR with a merge commit.
For small PRs, that works - but what if you work on something longer and regularly wish to pull in the changes from master? Ok, I could re-base the PR, but then I have to do a force-push and people who might be collaborating with me on the PR need to drop their local versions and fetch my force-pushed version. It happens often to me that I work on a PR and need to pull in changes from master. Usually, I do this using the "Update branch" button on the GitHub page for the PR - this creates a merge commit. And after that, trying to rebase the commit on the final merge would probably cause more effort then it's worth. So my experience: - rebase is nice for small commits - squash is ok for larger commits, in particular those where it would be tedious to go through the history and fix the commit messages where contributors have e.g. forgotten to reference the issue number - merge commits are the normal case for me, even if the repo graph may look funky at times. They preserve all commits (contrary to squash) and there is no risk to annoy anybody with force-pushes. Cheers, -- Richard
