4 ms·
And on this topic, another underrated feature that everyone seems to hate is merge commits. If you use rebase on your own branch, but merge commits on the stab
by quectophoton 3y ago
And on this topic, another underrated feature that everyone seems to hate is merge commits.
If you use rebase on your own branch, but merge commits on the stable branch (whatever name you use for it), you get both things:
* Small individual commits with the size and ordering that the original author intended on their branch.
* A "commit group" that describes that set of changes for the sake of future maintainers' sanity, and that can be atomically reverted.
More so in PR-based flows. You can have `git log --first-parent` display only the PR merge commits[1], and `git log --no-merges` display the linear history.
[1]: Assuming you actually put useful info on those commits. If you use GitHub, those merge commits can be set to default to PR title and description.
- dayjaby 3y agoI also set up recently the policy to only use merge commits on stable branch, as otherwise the path filter^1 in the workflows would not detect correctly which files changed after merging a PR. [1] https://github.com/dorny/paths-filter https://github.com/dorny/paths-filter