Version Control and Git Strategy?

Question

I use git to maintain some sort of version control and to synchronize my work across multiple machines since I do tend to work on multiple machines. I am the only person working on my code.

I can do most of the basics with git e.g. git checkout a file to return an individual file to an earlier state, and use git revert (I dread using git revert since I still have not understood some of it's intricacies fully) to return the entire project to an earlier state. I do also sometimes use git branch to fork the code in a different direction, specially if I am unsure of the direction.

My knowledge of git however is somewhat tenuous and I still tend to keep resaving the source file progressively as I work further on it. e.g. I maybe working on project18.c by the time I am done, having gone through 1...18 as I work through the code. This is in addition to doing frequent git commits while working on the file, so effectively I have two ways of "dialing back" my work on the project. This incremental file numbering however does not work well with code spread across multiple files since keeping track of a feature implemented across multiple files gets too crazy. I suspect that by working harder on creating self contained functions that encapsulate, and hide the inner implementation from the surrounding functions is a more elegant solution to some of my issues.

People often suggest performing a git commit for each major new feature or piece of code, however when I fail to perform frequent git commits, I will often spend an inordinate amount of time manually "backing out of" a buggy piece of code, if I am abandoning that particular way of implementing the code. I suspect that better planning//design of the code ahead of time may sometimes help, but it is often hard to fully anticipate what will end up being a dead end or buggy piece of code.

I am looking for a practical strategy for version control, that aids specially when things are not going well, and that aids with debugging the problem parts.

Answer 1

If you are serious about your working habits (like if you want to write code for living or contribute to some free software project), it’s best to get used to commiting often. The commits should still have some logic in them, it’s a faux pas to have a separate commit for each ten lines of code you write. Small & logical commits are nice to review or bisect, should you run into a regression.

If you need to have many checkpoints, you can have one commit for the test suite for the feature you are working on, and one commit for each passing part of the test suite. Or something like that, depending on your working style. (With Git you can always clean the history up when publishing the changes, if needed.) If you find that’s not enough, you’re doing something wrong.

Answer 2

The solution to your problem comes in two different parts:

Understanding commits

You need to better understand the idea behind committing and the way it was thought of originally. A commit ideally has to be at the same level with a piece of code that does something (like a function or a refactoring of some part). So you need to commit often, and if you fail to do so, you will simply lose information on your progress that would have been recorded if you did those commits. I recommend reading http://git-scm.com/book for a better understanding of how git works.

Exploring branching

If you are working on different unrelated features on the same project, it may be annoying to do successive commits that have nothing to do with each others. Here comes branching, a powerful feature that lets you work on different ideas on the same time, independently on each other (code-wise). You can find informations on how to branch and so in the previous link. But also, here is an article about a model of working with git branches that is particularly helpful for large softwares with multiple features http://nvie.com/posts/a-successful-git-branching-model/