Do you guys commit after your code works or when the day is over?

Which ever comes first

No. Atomic commits.

One commit should contain a very small feature. That way it's easy to identify and revoke a feature.

Mine are usually a few hours apart.

I commit often to branches and squash commits into meaningful ones before merging.

@hashedram What if you make core data structure changes?

@raldo94 same. Atomic commits every few hours, on a different fork. Merge latet

I don't commit... to relationships

@Floydian I'll write you down on the list

@Floydian up to a lifetime

Both. And sometimes even when the code doesn't work.

@Floydian aww :/ I should warn people that I'm known as heartbreaker

I'm still new to git, but I try to commit for every change I make. I find it easier to track on what I did wrong at a later date.

each piece/feature that works, as soon as it works and can be commited as a logical whole.
the more often you commit, the less merge trouble you get.

I instantly commit whenever my commit-alarm rings, no matter what I'm doing. This sometimes causes me to submit unfini

After it works

usually when it works, but if I have other obligations after work I'll move it to a branch prefixed with "WIP-" for "work in progress"; we have CI configured not to run on such branches.

When I've had progress where I'd like to keep its state, but not commit to keeping it as such, STASH!
When it works and I'm comfortable with how it's working and ready to move to another experimental upgrade, COMMIT!
When something isn't working and it's a recent action, BLAME ANOTHER DEV!

... I'm the only dev on my team... EVERYTHING IS OK!

Well played! 🙌 @wizzzard