←back to thread

361 points mmphosis | 3 comments | | HN request time: 0.431s | source
Show context
simonw ◴[] 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 #
charles_f ◴[] 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 #
JoshTriplett ◴[] No.42165883[source]
Agreed, but after decomposing the change into logical commits, doublecheck that the project builds after each commit.
replies(1): >>42165954 #
do_not_redeem ◴[] No.42165954[source]
Or even better, set up a pre-commit hook so that happens automatically.
replies(2): >>42166337 #>>42167243 #
1. s4i ◴[] No.42166337[source]
Or even better, do that in CI.
replies(2): >>42166794 #>>42167705 #
2. mdaniel ◴[] No.42166794[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
3. ervine ◴[] No.42167705[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.