Hacker News Reader

Comment by randall | Hacker News Reader

One question i've always had: How often do "regular" people commit? Should I be committing every time I hit save... or should I wait? (I don't work in a dev team, so I'm looking for the wisdom of developers who have to work in teams.)

View on HN

I like to think about my commits as units of work that I can pull back or cherry pick if I want to. It doesn't always work out that way.

Make sure your commits are cohesive to the change you are making. I think that is a good rule of thumb.

Yes, definitely nice if you can make your commits atomic changes. The more easily able to right a nice summary line (50 chars please!) the better.

On the other hand, some changes are big and messy. In this case I sometimes do intermediate commits, especially if it's at the end of a day just so I can keep yesterdays changes conceptually separate from todays. In the end I may rebase -i the whole thing and clean things up before pushing, but only if there are some obvious and quick ways to split it up.

I tend to do a lot of work upfront (without committing) and then go back and split the work up into smaller commits with "git add -p". I commit often, so it's never a huge list of changes I have to split.

I do this so I can cherry pick commits into other branches (e.g., fixing a bug in my current branch and merging it back to master).

It's really a judgement call, although I'd definitely recommend against committing every single save. The only hard-fast rule I follow is to always commit whatever I have left-over at the end of the day, so that I never lose work overnight or over a weekend.

Other than that, if you felt like you've taken a decently-sized chunk out of whatever problem or feature you're currently working on, commit.

I think you are confusing committing with pushing? But even then, I do not see any harm in pushing often, you can always amend your commits before final merge or pull request.

I try to commit when I have made enough changes so that builds and functionality don't break but not everything is 100% done either. My commit comment will describe what I was doing and what I changed. If unit tests pass then I think it's fine to commit (if you aren't writing unit tests than I advise that you should). There are projects I have to share with other developers and projects that I am the only developer on and I keep my rule of committing the same for both.

I tend to commit the first set of written tests, the first code & test fixes that passes them, etc. It's very organic though; if you do a "write one test pass one test" workflow that'd be a lot, but since I tend to work on multiple tests at once, it works fine.

Reply on news.ycombinator.com