Hacker News new | past | comments | ask | show | jobs | submit login

It's interesting to me hearing people in the comments talk about committing after hours of work. I instinctively commit after every maybe 30 loc, especially if I feel it has value. I'll sometimes squash them down if the PR turns out particularly noisy. It would be interesting to compare the average size of commits as well I'd imagine.

I don't know, I commit logical units. Changes that do something. If they're a one liner, that's it. If it's 500 lines, that's it.

If it's more than a day of work I might commit and push unfinished stuff before i stop for the day, but otherwise no.

Edit: although the latter happens very rarely. IMO if a unit is a whole day of work, maybe it needs splitting.

I would like to do that at work but the code review and Jira ticket adds to much overhead so we mash stuff together to umbrella commits.

That is probably becouse we use Perforce where you don't do local branches by default.

In my opinion, the project should be in a working state (everything builds, all tests pass, and the built binary or library would be usable) after every commit. Additionally, every commit should also contain unit tests for the code that's being changed, if possible.

Sometimes it's possible to meet these criteria after writing just 30 lines of code, but more commonly it will take 100-300 lines of code and several hours to get to that state.

Agreed here. I think it leaves the commit history to messy if the commits aren't actually fully functional changes.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact