3 ms·
There's no guarantee that every individual commit of a feature branch is meaningful, or even builds. It also makes the history of the master branch a lot harde
by haberman 11y ago
There's no guarantee that every individual commit of a feature branch is meaningful, or even builds. It also makes the history of the master branch a lot harder to read when it has tons of commits representing the minutiae of the feature's development.
- jakub_g 11y agoIt really depends on each individual's workflow. I tend to use lots of "in progress" commits (each time things are "green"), and as I go, I regularly squash the commits, so in the final pull request I typically have several commits (and if I wasn't squashing it would have been a dozen). If I do feature and a refactor, they are always separate commits, it's easier to review these and bisect if something turns out to go wrong. Some people might do similar things but they might not assure each commit is green, and they never squash anything (so you end up with non-meaningful commits). As @3JPLW said, I see when it can be useful for opensource maintainers to have the option to squash someone's commits, when the change is small, but there are many commits (due to a review ping-pong etc)
- echion 11y agoThere's no guarantee, but there are many benefits to striving for this ("git bisect run", CI test results).
- yxhuvud 11y agoIf it isn't meaningful, then that is something the review stage should catch.