When I was attending my software engineering bootcamp, one of the questions that I and many of my fellow classmates had was, ‘What the heck is Git?’. This question developed because as part of our class we were required to fork and clone repositories from GitHub, which we all just assumed was Git. It wasn’t until after I had graduated and started digging around that I actually got the answer and I thought that I would share it.
First things first, Git and GitHub are not the same, although they are related. According to git-scm.com:
"Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency."
To boil this down, Git is a version control system that can be installed and lives locally on your machine. The idea being that as you code you can locally save different versions of your code, in order, to keep track of changes, rollback changes, and etc, so essentially it becomes like a checkpoint for your code.
For example, if you’re working on a project and you suddenly realize that something you coded earlier is now no longer working, you have the option of either: A) go back though all of your new code to try to find the bug, or: B) use Git to simply rollback your code to the earlier point in time to when the code was working. Now the case for using either option is completely up to you, but if the code that broke was essential to your programming and all of your later code was just window-dressing, then maybe it’s easier to just roll it all back. Cool, right?
So now that we have an idea of what Git is, how do we get it? Well on a Mac, it’s as easy as just trying to run Git, in Terminal type:
$ git --version
If Git is installed, you’ll get the version currently in use, if it is not installed, you’ll be prompted to download the Xcode Command Line Tools, which include Git.
On a PC, you can go to https://git-scm.com/download/win to download the most official build of Git (it’s actually Git for Windows, which is separate from Git but it’ll get the job done).
Ok, so now we have Git installed, but how to use it? Well let’s go over some basic Git commands, these commands are entered into your preferred command line:
git init <directory>
This creates a new git repository using the provided <directory>, if you don’t provide a <directory> it will create the repository in the current directory.
git add <directory>
This stages all changes in the <directory> for the next commit (save).
git commit -m "<some message>"
This commits (saves) all of the changes that we staged with the
add command above, the <some message> allows us to give that commit a save-name.
Shows all of the untracked, un-staged, and staged changes that we have, it’ll also tell us if everything is up-to-date.
git revert <commit>
This will create a new commit (save) that rollbacks all of the changes made in the <commit> and will bring the new commit into your current branch.
Speaking of branches, that is a another benefit to using Git, instead of only having one master file where all of your code lives, you can create new workspaces for anything that you want. These new workspaces are called branches. If we think of it like a tree (sticking with the branch analogy), we start with just one “branch” of the tree, the trunk, but as we go up the tree, or keep working on our code, we can split off into different branches. Now all of these branches are separate but they are also all connected to our tree. If we take a look at this image:
We can see that we have our “master” branch or the tree trunk, this is the main part of our code, that everything comes back to in the end. Here we also have several branches which break away from our “master” at a given point so that they can be worked on separately without interfering with what is happening in our “master” branch.
For instance we have a branch “bugfix-e” which branches away from our “master” branch to try to fix a bug we found, without messing with all of our code in “master”. Also, we have a “new-feature-a” branch that spilts away from the “master” so that we can try out a new thing, again without messing with the code in our “master”. Then once we have fixed our bug or got our new feature working without any issues, we can recombine them into our “master” branch.
So now that we covered branches, here are some Git branch commands:
Shows all of the branches that are in your Git repository.
git checkout -b <branch>
This will create and checkout (move to) a new branch, called <branch>.
git checkout <branch>
Allows you to navigate existing branches that you already have.
git merge <branch>
This will merge all changes in the <branch> to the current branch.
git branch -d <branch>
Will delete the <branch> that you specify.
Ok, so those are the basic Git commands, there are a lot more of them out there but I think that the list that I gave you is enough to get you started. If you’re looking for more commands feel free to use the Git documentation here or Google and you’ll find plenty.
Well, I feel like we covered a lot of information, but I wanted to go back to my classmates’ and my original issue, of why we thought GitHub was the same as Git. Now for us, our endgame in class was to get our code up into our GitHub pages, so that our teachers and coaches could keep track of our work, and we used most of the commands that I provided here (except for one I didn’t give you yet) to do that.
So what is GitHub? Basically, GitHub is a online tool for us to save our Git repositories remotely. As someone who spent ten years doing technology support, I am a very big fan of backups, and that’s basically what GitHub lets us do. Take the local Git repositories of our code and save them to a different location. It also allows other people to see what you’re coding, you can see what others are coding, and, if you choose, you can collaborate with other people on your code or theirs.
In order to connect your local Git to GitHub, you will have to create an account with GitHub and follow some other steps. For the sake of time, I’d like to direct you to the GitHub documentation here, to get everything up and running. GitHub documentation is usually very good and easy to follow, and once you have everything up and running we can add the last Git command (that I wanted to leave you with anyway):
git push <remote> <branch>
This command will push all your commits from your <branch> in local directory into your <remote> directory (for us it’s GitHub). Typically, if everything is connected properly you should be able to just use
git push to push everything up to GitHub (the <remote> should be connected if you followed the guide above and if we leave off <branch> everything should be pushed, worst case try
git push --all).
That’ll do it for my crash course in Git. I hope that you find it useful, and as always I’d like to say, “Thanks for reading!”