12 ms·
I used this frequently, but it really requires your team to enable squashed merges and have consistent feature sizes. Otherwise a person who commits often (had
by dagmx 2y ago
I used this frequently, but it really requires your team to enable squashed merges and have consistent feature sizes.
Otherwise a person who commits often (had someone committing per line changed) will make it super noisy. And someone who merges in a giant branch will just blow up the screen for a bit.
- diggan 2y ago> commits often (had someone committing per line changed) As long as they squash their history before it goes into the branch everyone shares/branches off from, I couldn't care less how they do their work. But, pushing that aside, what could be the supposed benefit of committing each line like that? They'd spend more time writing commit messages than actual code, assuming the commit messages actually had proper meaning in them,.
- dagmx 2y agoInsecure coder or just trying to pump up their commit activity.
- bqmjjx0kac 2y ago> what could be the supposed benefit of committing each line like that? If you're making two meaningfully different changes, I would always say two tiny commits are better. Not only for organization, but to make it easier to revert just one change.
- diggan 2y ago> If you're making two meaningfully different changes, I would always say two tiny commits are better. Not only for organization, but to make it easier to revert just one change. As long as the tests pass on every commit that ends up the main development branch, you can pretty much do it however you want. But committing per lines changed isn't "making two meaningful different changes", it's saying since they are on two different lines, they aren't related, which just seems wrong.