←back to thread

Good Software Development Habits

(zarar.dev)
361 points mmphosis | 1 comments | 17 Nov 24 16:34 UTC | HN request time: 0.209s | source
Show context
simonw ◴[17 Nov 24 18:17 UTC] No.42165792[source]▶
On commit size:

> You just never know when you have to revert a particular change and there's a sense of bliss knowing where you introduced a bug six days ago and only reverting that commit without going through the savagery of merge conflicts.

This is key for me: a good shape to aim for with a commit is one that can be easily reverted.

replies(7): >>42165815 #>>42166356 #>>42166417 #>>42166427 #>>42166824 #>>42167218 #>>42167574 #
patrick451 ◴[17 Nov 24 19:33 UTC] No.42166417[source]▶
Unless all your features actually fit in one small commit, this doesn't work. Much more common is that you merge a chain of dependent commits, which means you cannot just rollback a single commit, since that will leave your codebase hopelessly broken. Much cleaner to commit the entire feature as one large commit.
replies(2): >>42167264 #>>42167433 #
1. necovek ◴[17 Nov 24 21:24 UTC] No.42167433[source]▶
If your "features" don't fit in one small commit, you should probably look to redefine what "features" are or at least not tie them to a commit.

You can and should split your features into a series of product/codebase improvements that end up delivering the full "feature" with the last of your commits. If done smartly, along the way, you'll be delivering parts of the feature so your users would start benefiting sooner.