For everything you need to know about version control, check out Version control – Everything you need to know, on Programming Duck.
Knowing the basics is essential
Knowing the basics of version control is essential. This includes things like:
- Creating commits
- Creating and changing branches
- Pulling and pushing from / to remotes
I imagine that almost all programming jobs out there use at least these basic features of version control.
Thankfully, these are things that even complete beginners can learn very quickly.
Intermediate to advanced knowledge is useful, but possibly optional
In my experience, many jobs don’t require more than the basics. I’ve personally worked with many people, even senior developers, who only had very basic knowledge of git and version control. There were no issues with their work, and they didn’t seem to have trouble finding work either.
However, having intermediate to advanced knowledge of version control can be helpful. Also, some higher level positions may require it.
Intermediate to advanced level version control would include things like:
- Being able to clean up your branch history using interactive rebase.
- Knowing about branching workflows and strategies and being able to apply them to a project.
- Knowing about merge strategies, such as fast-forward merges vs normal merges.
- Being able to revert commits.
- Knowing miscellaneous techniques such as how to cherry pick commits (and more).
- Etc.
It’s essential that at least some people in your team have that level of knowledge. It’s necessary because a project should have a branching strategy and a merging strategy in place. Additionally, version control issues, while rare, do happen sometimes, so it’s important to have a few developers who are able to fix them.
On the other hand, based on my own experience, it seems that as long as one or two developers have that level of knowledge in the team, the other developers don’t need to. The knowledgeable developers can set up the infrastructure and version control standards for the team. Afterwards, the other developers only have to use the basics such as creating commits and pushing them, while following the existing standards. If there are ever any issues, the less knowledgeable developers can ask the more knowledgeable developers for help.
Perfect version control
Other than the essentials discussed already, using version control well doesn’t seem to be a high priority matter. This is mostly because version control issues tend to be rare, at least in my experience. Additionally, reading through the commit history of a codebase isn’t something that’s frequently done.
For these reasons, structuring commits well and having good commit messages, among other things, are things that many developers neglect.
Therefore, in-line with being pragmatic, I don’t believe that it’s worthwhile to be extremely diligent with your commit history. Personally, I don’t spend a long time on every single commit to make it perfect. It doesn’t seem like the benefits gained over the lifetime of the project would justify the cost of time.
However, I do believe that having a pretty good commit history is worthwhile. Maintaining a pretty good standard takes significantly less time than maintaining a perfect standard. Therefore, this is the point at which I believe that the benefits gained over the lifetime of the project justify the cost of time.
Please note that this conclusion is only based on my personal experience. Your experience may be different. In any case, remember to be pragmatic and do what you believe is best in your situation.
Final notes
That’s it for this article.
If you have any feedback, or even counter-arguments, please let me know in the comments.
Next, if you want to know more about version control, as well as how to use it, please see the article Version control – Everything you need to know.