For those not yet using git
Whether you’re yet to use the world’s favourite new version control system in earnest or not, be under no illusions – it is the future, git has won. But then you already knew that. This series of blog posts are for those who haven’t learned git possibly for one of the following reasons:
- You find the quick introductions don’t adequately explain the complex concepts of git
- You find the “grok the man pages” approach to learning convoluted and impenetrable
- You find brick walls when arguing why your team should adopt git
If any of those sound familiar, this series is of blog posts is for you. In simple, manageable steps they will allow you to understand how git works; how to write code collaboratively; and make cohesive arguments in favour of git. It won’t make you a git expert and there will be caveats along the way, but this will provide a perfect first step.
How development used to be done
When it comes to tooling and process, we sometimes look back with fondness about how things used to be done. But also with an awareness that the automation, complexity and productivity of how we produce code today is greatly improved.
For instance, my first industry job was as a software engineer for Thomson Financial (now Thomson Reuters) writing and maintaining real time ticker plant server code for various European stock exchanges. We didn’t use a version control system. It was the middle of the 2000s.
Even in academia I was vaguely aware of this tool called CVS that let developers undo changes, or let multiple users commit code to the same place. But at Thomson, we had meetings to co-ordinates concurrent projects working on the same exchanges. With hindsight, it’s laughable how arcane the process was: copy the source code folder on a shared drive, update the version number… Before CVS, before Subversion, we look back at and think how arcane it seemed. We will one day think the same regarding the days before distributed version control systems (DVCSs) like git.
With power comes complexity
Git is not an easier tool – it’s a better tool. Because it exposes so much more functionality the learning curve is harder than when you first learned to use, say, Subversion. Do not worry though, this series of blog posts will help you. It will help you think about source control versioning in a different way; it will highlight the big ticket wins that git provides if you need to convince managers why the tech change is needed; it will introduce the basic template for collaborative development; and finally it will send you on your way with pointers for where to go next.