OSDev.org

Hi, I've often asked myself exactly when to commit my code... should I commit after I get a new feature working? Of course commit when you fix a broken build(missing file, etc)

exactly how long do all of you wait until commiting? and what do you do when you write 200 lines of code reworking almost everything(and breaking everything while in progress), but discover that something went horribly wrong in the last 10 minutes of your coding?

I don't commit for much more than releases. And when something goes horribly wrong, I attempt to debug my code. If that doesn't work, I put it away in my "strange or broken code" folder and restore the old one.

Commit early, commit often.

With git you can simply throw local development branches on the problem - they can even break compilation without hurting anyone. When you're done with the changes and have reached a new working state, you merge things back into the master branch. Before merging you even can rewrite the version history to be a nice patch series if you like (being able to edit existing commits in my local branches is actually one of the things I like most about git).

Welcome to the forums, Kevin!

I prefer SVN over git for simplicity. That and the fact it works good for smaller teams (say two or three people.)

You might be right that SVN is more intuitive than git and git has a steep learning curve in the beginning. But it's really the same thing as with vim: It's powerful and once you know how to use it you don't want to miss it. I even use it as a better SVN client for some projects which officially use SVN for their main repository (a nice example is qemu which still uses SVN, but basically all developers use git - including the maintainers).

I tend to commit less often, with bigger commits toward the beginning of a version, but towards the last few days before the release I commit a lot (bug fixes, minor last min. things)

-JL

We usually commit at the end of each day before we go home (we skip this step if we know there are bugs that are going to majorly affect the other programmers). We'd also do a massive number of commits in a day if we were working closely to another programmer.

I guess how often you commit depends on if your source code is available to the public or just internally. If it's just internal and you're working with another programmer than you can often commit buggy code (provided you warn the other programmers) - this is what branching is suppose to be for, but it usually becomes too much of a hassle so we work out of trunk.

I think committing at the end of the day will suffice for open source projects.

I commit after getting the job done,when the code works perfectly,
I don't commit in the middle of coding unless there's somthing really important.

I generally commit when I have the next feature implemented.

And sometimes I commit half work when I expect that I will be editing my code on a different computer next time. (which I only do because I'm the only user of my OS' repository, in work I wouldn't dare do that)

A commit should address one issue, one issue only, and - if possible - that issue completely.

Commit often enough that a crash-and-burn of your workstation won't lose you much work. (This doesn't really apply for repo's kept locally, but it's still a good rule-of-thumb.)

Commit seldom enough not to break the build or leave an issue half-fixed (unless you're expecting to leave the project for some time and somebody else wants to take over).

A good benchmark for commits is the comment attached to the commit.

Good:

• Bug #1432 - buffer overflow in module XYZ. Fixed.
• Changed code from char[] to std::string.
• Backports from branch 0.3.
• Sync'ed with upstream release 0.4.23.

Bad:

• Various fixes.
• Completely reworked everything.
• This doesn't fix it, but it's better now.

I really like Git, and try to commit something as soon as a single feature is working. Like Solar said, you really should only address a single feature in a commit, but sometimes that's a bit difficult. Fortunately though Git makes it really easy to only add the files (or even just the parts of files) that you want, and branching is absolutely effortless, so if you're working on a big, complex feature that will break things, it's easy to just make a branch and keep that up to date so you don't loose any code if your drive dies. And that way you don't annoy any other developers or anyone that wants to see the source by breaking your main tree.

For personal projects, I typically setup a repo as the first step (git user). The first dozen or so commits follow the "bad commit" format (though I leave myself notes sometimes), since I tend to use source control as a type of "whiteboard" for ideas. Following the first dozen, the commits trend towards, then reach "good commit" format. After reaching "good commit" format, I use branches and alternate checkouts to manage features that break things.