What are the good criteria for committing changes

Question

I'm currently using git for managing several projects, however, one question has been bugging me recently: what is the good tone for committing modifications to the master branch and to secondary branches? Should it be 'commit when it compiles', 'commit when it works', or something else? Thanks.

Answer 1

Some basic things:

1. Strive to commit per "logical change"; bug fix, refactoring, feature, ...
2. Run your unit tests before commiting the code; make sure that you didn't break anything obvious (you do have unit tests, don't you).
3. If in a multi-developer environment; update from the repo and run the unit tests again to make sure no conflicting changes broke someone's code (yours or theirs).
4. Fix as needed and repeat from 3 until nothing is broken.
5. Commit immediately and cross your fingers.
6. Rely on your continuous integration tests to tell you whether something else broke.

Answer 2

To take it one step back, I try to work on issues/bugs/features that can be completed in a short period of time. If it's going to take more than a day to come to a good stopping point the task is too big.

That said, I think the best practice is to commit your changes when the code compiles and has been adequately tested (ideally with unit or integration tests that get committed with the code change).

If compiles + functions properly + is well tested == 'commit when it works' then that seems like the appropriate rule.

Answer 3

Commit when it works. In my case this means to: automate the smoke test, run it and commit.

Note: its just the smoke tests that I automate/run before the commit. Regression tests are left to the continuous integration.

Answer 4

I go with 'commit early, commit often', myself. If you have an automated checkout and build going on, this obviously won't work.

Answer 5

If you are using a ticket management system, I would say commit when a task is fixed.

Answer 6

Commit only one type of change at a time.

What "type" means is different for each project, but some popular examples include "cosmetic changes" vs "functional changes" and "refactoring" vs "adding new". This makes it easier to follow the changes when looking at the log, and also easier to revert to a revision.