Most active commenters
  • ervine(3)

←back to thread

Good Software Development Habits

(zarar.dev)
361 points mmphosis | 13 comments | 17 Nov 24 16:34 UTC | HN request time: 0.215s | source | bottom
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 #
1. charles_f ◴[17 Nov 24 18:21 UTC] No.42165815[source]▶
A trick to help doing that, when you start having multiple changes that could be distinct commits, use git add --patch to select the changes one by one. Not only that can allow you to create smaller changes, it also gives you an opportunity to review your code before you commit
replies(2): >>42165883 #>>42167379 #
2. JoshTriplett ◴[17 Nov 24 18:29 UTC] No.42165883[source]▶
Agreed, but after decomposing the change into logical commits, doublecheck that the project builds after each commit.
replies(1): >>42165954 #
3. do_not_redeem ◴[17 Nov 24 18:38 UTC] No.42165954[source]▶
Or even better, set up a pre-commit hook so that happens automatically.
replies(2): >>42166337 #>>42167243 #
4. s4i ◴[17 Nov 24 19:22 UTC] No.42166337{3}[source]▶
Or even better, do that in CI.
replies(2): >>42166794 #>>42167705 #
5. mdaniel ◴[17 Nov 24 20:15 UTC] No.42166794{4}[source]▶
As someone who works in small companies, and had to endure developers who were using gitlab as "offsite backup" or I guess "push-based 'does this compile?' workflow", please don't do this. CI minutes are rarely free, and for damn sure are not "glucose free". If you can't be bothered to run the local compilation step for your project, that is a wholly different code smell
6. keybored ◴[17 Nov 24 21:05 UTC] No.42167243{3}[source]▶
Stalling a commit for more than a third of a second is way too much.
replies(1): >>42167694 #
7. necovek ◴[17 Nov 24 21:19 UTC] No.42167379[source]▶
Also look up at any one of the "stacked branches" approaches (plenty of git extensions or tutorials that work natively with newer git versions).

For those still in bzr land, there used to be a wonderful "bzr-pipelines" plugin to enable seamlessly working on a set of interdependent changes.

8. ervine ◴[17 Nov 24 21:59 UTC] No.42167694{4}[source]▶
Slightly-longer commits to have never-broken commits... hmmmmmm.
replies(2): >>42168168 #>>42170498 #
9. ervine ◴[17 Nov 24 22:00 UTC] No.42167705{4}[source]▶
Not for things like type / lint / formatting errors. Tests too if not too long.

I mean have them in the CI as well, but for sure have them as pre-commit hooks.

10. Izkata ◴[17 Nov 24 23:07 UTC] No.42168168{5}[source]▶
If you hit a full second, that's just right back to the svn days where there was just enough friction people wouldn't bother to commit until everything was completely done, then the commit would often be too big to easily describe why things were done in the commit message.
replies(2): >>42168174 #>>42168289 #
11. JoshTriplett ◴[17 Nov 24 23:09 UTC] No.42168174{6}[source]▶
I don't think taking one second to commit is a problem. However, verifying that software builds typically takes a lot longer than a second.
12. ervine ◴[17 Nov 24 23:29 UTC] No.42168289{6}[source]▶
Huh, I guess we have different expectations. I really don't mind a few seconds even to know I didn't totally break things in a commit.
13. keybored ◴[18 Nov 24 07:32 UTC] No.42170498{5}[source]▶
Second-order effects. Longer to commit means less commits which means more grab-bag commits which means less useful commits.