3 ms·
1 commit per PR sounds like terrible advice, unless it's a change of just a couple of lines. Don't squash your PRs to make logs look shorter, learn to use the `
by rjmunro 3y ago
1 commit per PR sounds like terrible advice, unless it's a change of just a couple of lines. Don't squash your PRs to make logs look shorter, learn to use the `--first-parent` option to show only the merges if you want less detail.
- Zacharias030 3y agoCan you elaborate? Our team has a squash-and-merge policy that I never questioned before. I guess people just don’t write clean commits and consider a PR the smallest unit that makes sense.
- rjmunro 3y agoOver-simplistically, I might have commits like: * Add new field to the database * Add new feature to API * Add new feature to front end * Add new feature end to end test Each would make sense on it's own from a code review point of view, but the full feature doesn't exist until they are all included. You don't want to merge them one by one because QA would have to test every step doesn't break something else, but wouldn't be able to test the feature itself until later. Splitting it up means code reviewers can consider each part without the clutter of the others, and git blame may be more helpful in the future (although maybe not in this over simplistic case).
- from-nibly 3y agoCommits should represent a single change that can be added or reverted independently. Everything should be squashed to that point, no more no less.