What are the good criteria for committing changes to repository?

Question

Hello, 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

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 2

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

Answer 3

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

Answer 4

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 5

It really depends, is this your personal repo or is it a repo that is shared by many developers? How far into the project are you?

Personally I commit to my subversion repositories when I am done with one aspect and everything compiles. It does not have to be complete, just not broken. I prefer to not leave things broken in the first place.

Half written code can get checked in, but only in my personal branches, generally with notes about what I was doing at the time and what still needs to get done. Since I use Subversion and this is my personal repo I use this mainly to be able to leave my desktop and pick back up where I left off on my laptop.

Generally the one bug/issue/feature per commit is nice, but may not suit your development style. If this is a more complete project it may work out since commits mean that you are crossing items off a list somewhere and it means one more item that is now completed.

Other things to consider, what is significant about the changes that it warrants checking in? For example, I checked in code last night that significantly changed an internal API, this meant I had to document the changes in the commit message as well as the documentation. At the same time I also changed a few comments to fix typo's. That gets a small sub-note on the commit message, but is not something I consider a big enough issue to get committed on its own.

Answer 6

First: Ignore subversion strategies and strategies stemming from that mentality. There is a difference between saving a change and publishing a change.

Committing is saving a change. While I wouldn't suggest committing on a timer, I would suggest you think of it more like saving a file than releasing a version. Do it when you fear you may need to come back, but are afraid it would otherwise be hard to get back to where you are.

However, rewrite the commits (git rebase -i origin/master # for example) before you publish them. Find the meaning in the mess you made and create a set of comprehensible and clean commits with good commit messages and ensure each passes whatever quality checks you might have. Then publish it.

Answer 7

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.

Answer 8

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 9

Commit any code you don't want to write again :)