Question

I have been trying to learn and get used to version control, more specifically git. However, my development team is currently (and for the foreseeable future) composed solely by me, and thus, my focus with git has been on trying to master branching and committing techniques.

I have seen and tried some work-flows examples, such as git-flow. However, i can’t seem to really master how to use them. For example, how often, and which kind of contents should commits have? when should i really branch for a new feature? I find myself very often in situations where I’m writing a new feature, and suddenly realizing that i need to fix a previous coding error, or supposedly finishing a new feature and later on realizing I still miss some things.

This leads to some confusing branching and committing, which are of absolutely no help. And I find myself wondering how much of a help version control really is.

What am i doing wrong? Or isn’t git/version control systems intended for single-person development?

Answer 1

If you’re just starting out with version control, for a single-person project, then don’t worry about all those workflows and etc initially. First, get used to committing.

Did you just run your program and test something, and it worked? Great, commit. About to do something you’re not quite sure will work? Commit. Commit early and often. The nice thing about git is commits are undoable if you picked a bad place to commit (hint: if it doesn’t compile, it’s probably a bad place – but there are exceptions to this, once you’re comfortable with git rebase -i and git add -i (kind of an advanced tool though, so get used to the basics first! (nested parenthesis are fun!))).

Now, about switching focus – git has a number of useful tools for this.

For example, if you want to fix a bug, but have a bunch of other work already…

git stash save

Git then takes all uncommitted changes, saves them, and reverts to the last commit. You can fix the bug, test, commit, then

git stash pop

All those changes are then re-applied on top of the bugfix.

If you’re working on a small feature, but then realize this is actually kind of complicated and you’ll probably commit more than once…

git checkout -b mynewbranch

And there you go – you’re now on a new branch. You can get back to another branch at any time with

git checkout someotherbranch

You can use this together with git stash to save uncommitted changes, then swap to another branch to do something completely different. And when you want to get back, git checkout mynewbranch.

As a slightly more advanced tool, if you have a tiny bugfix to make, and don’t want to bother with the whole stashing thing, you can do

git add -i
# select what changes to include
git commit # commits only what you selected

This is thanks to the git index – git add -i lets you select, down to the individual line level, exactly what to copy from the working copy to the index, then git commit saves it as a commit. By doing this you can very quickly and easily tease out minor fixes from a mess of other changes. Note, however, that this means that you’ve just committed something that has never been compiled or tested in that form; so it requires some care not to commit something that is completely broken (You generally should avoid committing completely-broken code because it breaks git bisect – a very handy tool for tracking down regressions).

Once you’re used to this basic flow, you can start adding some process to it. For example, you could keep a v1.x branch for bugfixes only to the 1.x series. Or whatever. Use a workflow that works for you.