Git is one of the things I had on my list to learn for 2016. As a current developer there really is no excuse not to be using Git for your projects. The problem is, it's not exactly the simplest of things to understand right off the bat. I recently discovered a fantastic learning resource for Git and Github, and after completing their online course I now have a far better understanding of the subject.
In this post I will be giving an introduction to Git and Github that a five year old could understand. As with the majority of things in this blog, this will be for my own benefit just as much as anybody else - so I'm aiming for utter simplicity. This will not be a highly technical post - the Udacity course really cannot be beaten for that, so I'm not even going to try. This is intended to be an easy to understand, brief introduction to Git, GitHub and what they involve.
So first things first, just what is Git?
Git is a source code management system, or version control system that is installed locally on your machine. It keeps track of your code at different points during development, allowing you to easily revert your code to that point in time.
Have you ever had that traumatising moment when you make lots of changes to your code, refresh the page and discover you've broken your website with no easy way of getting back to a working state? Git can help. If that's not reason enough to start using it, I don't know what is!
OK that's Git. What's GitHub?
GitHub is a website that you can upload your Git projects to. It's a hugely popular resource amongst developers that allows you to easily share and collaborate on your projects. Alternatively you can make your projects private, and no one can see your code except you. At its most basic level you could think of GitHub as a remote backup destination for your code, but the community aspect makes it far more than that. There are other websites which serve the same purpose (Bitbucket being one of them), but GitHub is by far the most popular, and for the purposes of this post we will be focusing on that. Now that we know exactly what we're dealing with, let's look at some of the Git commands and what they do.
git init command creates a new Git repository. Imagine you've created a new directory for your latest website project, and you now want to start using Git on it. By running
git init on that directory, you are telling Git that you have a new project you want it to monitor.
Note - in simple terms a "repository" (or repo) is the same as a "directory" or "folder". It's basically the place that you have your project files saved.
Alternatively, you can run
git init my-new-directory-name and it will automatically create a new, empty project folder for you. Whichever option you choose, you will now have a new Git repository for your files.
Already we're encountering a command that can utilise GitHub. The
git clone repository-you-want-to-copy command copies an existing Git repository. This can either be a repository stored locally on your computer, or one that exists remotely on the GitHub website.
The value you supply for repository will either be the name of a local repo on your machine, E.G.
git clone my-first-website or the url for a remote GitHub project E.G.
git clone https://github.com/username/my-first-website.git.
This command tells Git to add a file to a temporary "staging area". You can add multiple files to the staging area, before finally saying "OK Git, now remember my code at this point".
This makes sense, right? Because you could be altering code across multiple files in order to make a change to your website. You could add a new element in your HTML file, and then a new rule in your CSS file to style that element. These two changes have to be made together for the one bit of functionality you're adding to your page.
So you would run
git add my-webpage.html then
git add my-css-file.css. Both your HTML file and your CSS file are now in the staging area waiting to be passed on to Git together, using "commit".
This tells Git to save a snapshot of your files that are currently in the staging area. Once you have committed your changes, Git will add that snapshot to its history. In future you can revert your code to that particular point in time. This is a lifesaver if you start playing around with your code and accidentally break something. You can simply revert back to your last "commit" and your code will be restored to how it was before you happily started destroying things with abandon!
With each commit, you provide a short description to help you to remember what each commit was for, E.G.
git commit -m "Add background to header".
Here's another one that is used for GitHub. Imagine you have been developing your project, and you have a bunch of commits that you've made along the way. Up until that point, all of your commits are still on your local machine. If you want to send all those changes to GitHub, you can run
git push origin master. Those extra bits (origin and master) basically tell Git where to send the changes (origin equates to GitHub), and what "branch" to send. Unless you specify otherwise, your commits will all be on the "master" branch. Those last few points are a bit complex for an introduction post, but you can find out more about them on the Udacity course.
This command will give you a useful summary of the current status of your repository. For example, it will show you which files have been changed since the last commit, and which files are yet to be added or committed.
Remember those "commit"s we made? The
git log command will show you a list of all those commits, with a unique ID, a timestamp and a message (the one that you provided when you committed your files).
This will show you a list of all the changes that you have made in your files - compared to the version that you last committed to Git.
That's probably enough commands for now. There are way more but it can start to get quite complex, and (for me at least) the video tutorials in the Udacity course explain things far better than text can.
Hopefully though this post gives you a nice taster of Git, GitHub and just how useful they can be in tandem. Even if you're a solo developer, you really can benefit greatly from using version control in your development. It's not just something that people collaborating on bigger projects can utilise (although of course it's great for that too). I guess it's like with anything, the first time you start using it will feel unfamiliar, and development may take longer than it usually would. But the more and more you use it, the easier it will become and soon you'll be wondering how you ever lived without it.