Git: What and Why? An introduction for Students- 6 mins
Since heading out onto placement, the importance of version control in the world of software development has become clear. This subject was covered only briefly as part of my University course, which on reflection is surprising seeing as it’s the one thing I’m guaranteed to use each and every day. Here I outline a few of the benefits of source control and how to get started.
What is it?
Any software company worth its salt will use versioning of some sort or another. Don’t believe me? Check out this great post from David Crotty, a developer at Vualto. I wholeheartedly echo the points David makes in that post. Every single line of code I’ve written during my placement has been version controlled.
Git is one of a handful of systems that can be used to version software, storing code in a canonical ‘repository’. When used effectively it allows individual features to be ‘branched’ from master, changes can be ‘rolled back’ and code from different developers to be ‘merged’ together. My personal favourite its role in ‘continuous deployment’, whereby code is deployed to production directly from the repository if unit tests are passing.
Why should I use it?
You might not agree with this, but stick with me. You should put everything of any quality on a public facing host, such as Github, for all to see. Everything. You may be thinking that your code is not worth sharing online. You may even think that it’s a bit shite. You may be right, but my point still stands.
GitHub is the social network of software developers, having a profile can set you apart from those around you when trying to find a placement position. Any software you create as part of your course should be added as a repository for others to see. Don’t worry about people looking down at your code. Employers are not expecting you to be an awesome developer at this point and will have that in mind when viewing code. What matters is that it looks like code they could have written at some point in their career.
The objective of putting your code onto Github has nothing to do with its quality. Instead, it’s to demonstrate that you’re familiar with the basic concepts of version control. One of the comments I’ve heard over and over when asking within the software industry is that students have very little or no experience of version control.
On my course we had one lecture on version control as well as one assignment that has to be submitted via a link to a repository. In the days following the lecture I discussed it with course mates and their take home was that they’re more likely to delete all their work if they use it (you’re not). I’ll admit I didn’t attend that session, but I’m sure that wasn’t the intended take home.
The true benefits of using version control are not seen until working as part of a team. The canonical repository allows team members to work on the same code at the same time (hopefully) without causing issues. It’s also been pivotal in allowing developers to work remotely from a physical office, including myself. Individual changes are attributed to a specific team member which, in the context of University, can be handy when group members are not pulling their weight on a project.
The final point I’ll touch on is backing up. It’s often been said that “you’re only as good as your last backup”. The great thing about git is that it’s a continuous backup of code at all states of development, providing that you push your changes to the remote host. If the worst should happen and your computer fails, restoring your work is as easy as pulling your code from the remote ‘origin’.
Where do I start?
Now that you’re convinced on the benefits of versioning, it’s time to get everything set up. First thing is to decide which version control system to use. The three most common are Git, Subversion and Mercurial, which are are by no means the only systems to choose from. I’d suggest Git. It’s the most widely adopted and the easiest to find help for, something that you will need when you start. It’s also the system that GitHub was built around, which brings me nicely onto my next point.
I’d recommend GitHub as the online host for your code, followed closely by BitBucket. It has a thriving community and you’d be hard pressed to find a notable project, at least in the world of web, that does not have a presence. It’s open by default, meaning your code is available for all to see. As a student you can get an upgraded account with 5 private repositories included (and currently $100 dollars of Digital Ocean credit). These are great for hosting university assignment code whilst in development. If you would like a completely private system I’d recommend GitLab, whose cloud solution offers unlimited free private repositories and can even be set up of your own server, such as Digital Ocean, if you so wish.
It’s for you decide if you’d like to use a GUI or the command line to work with Git. I’ve found that the visual representation aided my understanding of git before moving onto the command line. For windows, my preference was for ‘GitHub Desktop’, before switching to a Mac and moving to ‘Tower’ (which offers a substantial student discount). On both operating systems the command line is needed at points, which should be installed automatically when installing either of these clients.
Git comes with a whole host of terminology, features and surprises. There are two resources that are great for getting your head around the world of Git. Firstly is the excellent learning resources from the team behind Tower. Although some of the documents and videos specifically refer to the Tower client, the lessons contained in them can be applied to any client or even the command line. Speaking of which, Codecademy have a great course on Git, which will make you a command line wizard in no time. For GitHub specifically the docs are, as always, the source of all truth. If you would like a handy reference, the Git Pocket Guide is probably the best you will find out there.
Are you new to Git and version control? Get in touch via Twitter and let me know how you’re getting on, I’d love to hear from you.