Though version control is here to help you, it can sometimes become a rite and a burden. That’s where I ended up. Let’s use version control in a lighter fashion to help us work faster and smoother.
I’m a detail oriented person. Because of this I tend to lean toward the “slow and perfect” side of things rather than the “fast and sloppy” side. Neither is always better, but rather, both are terrible if you follow either of them always. Instead you must adapt, and knowing which direction you tend to lean is very helpful when you need to adjust to the current situation.
All I’ve ever read on the topic of version control of program source code leans toward the perfect side. How to write “proper” commit messages. How you should always split up everything in small independent commits. That every feature should be developed in its own branch and later merged. Create branches and lots of them!
I’m not surprised that all I’ve ever seen are tutorials, notes and suggestions on how to do version control “right”. I mean, you type something up when you have a tip or have found a neat workflow or tool.
An example of such a tip is Tim Pope’s rather nice git commit message guide over at his blog. I think this is a rather good guide actually and I mostly follow it, things just look nicer in command line git this way. However, it definitely leans toward “slow and perfect” and might actually just be satisfying my detail oriented mind and not really help me.
Another example is the branching model for git suggested over at this site. This one is rather crazy though. It goes into meticulous detail on how to branch in several layers to successfully build software. My detail oriented mind is completely vetoed by my love for simplicity here. This is just too complicated. I caution you to stay away from this.
It’s a balance
The problem here is that “perfect” and “correct” slows you down and you should beware of this. Think twice before listening to someone telling you how you should do something more “correct”. It will often have a cost in reduced speed. Think of the trade off you are making.
Actually, I urge you to always think of the trade offs. Any time someone preaches about something you absolutely must try. Must do. Now! They are most likely oversimplifying things. Maybe it’s perfect for their case, maybe, but people certainly can make things sound like they would solve your problems too.
The actual problems in software are complexity and the many trade offs one has make to reduce and handle that complexity. Version control was invented to help with this. Instead it sometimes becomes another burden.
Don’t let it.
Don’t use version control, got it
Note that I’m not saying to do or not do these things. I’m saying spending more time on commit messages makes less time for programming or debugging. Spending more time on how to branch or reordering commits leaves less time for thinking about the actual problem at hand.
What I’m trying to say is that it’s easy to spend too much time on doing version control right. In the end it’s just a tool and that should not be forgotten, I did and wasted a lot of time on perfect git histories and commit messages, especially on personal projects. What version control should do for you is help optimize you software development in the grand scheme of things. That might mean spending days figuring out how to use it for your project. But in the end it must be worth the time you spend on it.
Suggestions that might help
- To work fast, commit things in small chunks with ugly but to you descriptive messages. Clean it up before you share or finish up, possibly changing local history or combining many commits into one.
- Don’t branch more than it helps. You don’t need a branch for every change. Just hack on master locally. Branch later if you have to to commit or branch from the get go if that’s helpful. There’s no rule.
- Consider a very descriptive final commit messages if you work in a bigger team. This is mostly for others but possibly also yourself in a few months. It’s great to know why something is the way it is when considering changing it to fix a bug.
It’s OK to use something other than git too, by the way. 😉