Terminal Git… a profound, scary space not too different from the Abyssopelagic zone of the ocean — that’s the deepest of the deep. There’s things floating around down there that are strange, and new discoveries seem to happen frequently. But no need to fear. We’ll be traversing in a pressure sensitive submarine to ooh-and-aah at all the wonders git has to offer!
From here on, it will be assumed that you have at least a beginner-level knowledge of what git is, why we use version control and some experience using the terminal. Also assumed, is that you have your git linked to a storage location like Github / Bitbucket / Gerrit / Etc.
If this is super fresh for you I would recommend going through some of the very basics here — Atlassian Tutorials— this website will also include more detail about some of the things expanded on below.
git init / git clone
Let’s start from ground zero. You’ve got some folder with files inside of it that you want to put on a storage platform. The very first thing that needs to be done is git init. Git init does a couple of things, but most notably it creates the empty repository (place where something will be stored) that is configured to interact with git.
Before git init you just had a generic folder. Git init says I want to start applying the rules of version control to this folder and everything in it. Quite literally → initialize git
There is a commonly used alternative to git init → git clone.
More often than not, in a professional setting, you will hop onto a new team with an already existing git repository for a project. In this case, you want to grab everything at once from the remote location (online) and place it locally on your computer. This is where git clone comes in.
Git clone acts like git init. It’s a one time setup that once done won’t have to be configured again. You’re grabbing an existing git repo and getting the rails on track for your local machine.
ProTip: git status
If you take away nothing else from this post, take away git status. This is easily the command I use the most with regards to git. If you ever, ever want to see what’s going on with your git repo, git status will tell you. Easy as that. You’ll see me continue to use git status in the rest of this post!!!
git add
So you’ve officially made a git repo. Time to start using git to track your changes. Let’s break down what that process looks like.
I’ve turned a folder into a git repo, and I’ve added one file to it with a line of text inside that file. Git status paints the picture for what’s going on.
For now, ignore the ‘on branch master’ line, but it means we’re in a git repo and everyone’s happy. Great. We see there’s no commits yet. This makes sense because we haven’t made a commit yet, that comes in a bit. Now to the nitty gritty.
Looks like there are some “untracked files” and a message from git prompting us to do something. That message is actually in two places, the other being at the bottom. Must be important right? Git is saying “I see you’ve made some changes but you have to add them for me to pick it up”. The file where those changes are appears in red. This is a another hint that something needs to be done by the user!
The files that appear in red after git status represent unstaged changes. These unstaged changes are changes that are not ready to be committed by git… at least not yet. You have to tell git to add those changes — or stage them.
What’s the purpose all this unstaged and staged business?
Typically, you can use the command git add -all to add all of your unstaged changes to the staging area. You’re telling git to grab every new line of code you’ve written in every file you wrote it. Adding all of the files can seem redundant at first — you just want git to go and grab everything all the time right? Well, not always…
There are plenty of situations where you may only want git to track certain files, or pieces of those files as part of a commit. If that’s the case, you can use git add <filename> to add that filename to the staging area, but leave the rest of the code unstaged.
Pretty neat eh? In case it wasn’t already obvious, you’re getting a lot of power and flexibility when you use git. And I’m only scratching the surface of git’s capabilities.
git commit
Before I go any further, what exactly is a commit? Think of a commit like an entry in a journal. Each journal entry describes what you did that day or week just like a commit does. Inside your whole journal you would have multiple entries that compromise the entirety of the journal. If you want to go back and check out what you did on a certain day, all you have to do is flip to the journal entry with the date you’re looking for. Maybe it even has a unique title if you were nice enough to give it one.
Commits work the same way. Each commit is a sort of log of the changes you’ve made. It has a timestamp as well as a commit message, written by whoever made the commit, which acts as a title. Good commit messages are essential because they allow you to easily find a previous commit you made, or help a peer to interpret your commit at a glance. When you review other people’s code the commit message is the first place you receive direction for what you’re looking at! So make your message clear and concise.
Alright back on track —
At this point we should have some or all of our files in the staging area with the items we want in the upcoming commit in green after a git status. Sweet. Last thing to do as actually log the journal entry — or commit. The commit is created using git commit -m “<your message here>”.
git push
The home stretch is in sight and in all honesty the process for version control has ended before a push is needed. We’ve got one, or more, commits which act as a history of logs and we can look at those logs if needed (or return to the point when the log was made). Git push is important because at this point the commits live on our computer and only our computer. The real excitement lies in our ability to share code! To do that we need to push our commits onto the interwebs. This is where we use — Git push.
If you have your own solo project backing up your code online with git push is pretty easy. Once you’ve linked the local repo to a Github location the command git push origin master will push your commits onto Github. Haven’t linked the repo to Github yet? No problem, follow Github’s HowTo to get started here (and hey, this briefly goes through each step used in this post as well…)
More commonly however, your new git repo will be worked on by multiple team members. Each person is writing code, making commits, and pushing their code online.
Take a second to think about this… what might be problematic here? What’s the actual homebase for the code? Can you push code that trumps another team member’s code? Is the version of the project on your computer the real version, or is it the version online? Welcome to merging and rebasing. This is where the fun begins, and by that, I mean, where git can start to get complicated. For the purposes of this post I’m going to graze over the details here. Partially because different companies operate under different pretenses and also because a budding new developer should focus on the basics first.
I’ll leave you with some food for thought though. It is possible that you might want to push your code to a location that’s not origin master. Perhaps you made your own little happy git land — aka a branch, where your changes live temporarily. Your branch would be part of many branches on a tree where the tree trunk is the master branch. Sounds easy? Actually it’s not… There are git pros out there who still learn new tools for git frequently, so don’t fret.
Phew, we did it. Built a git repo from the ground up — and hopefully learned some tricks along the way. The next git related post will have some more intermediate techniques such as git patch, rebase, fetch, etc. The resources to learn git are limitless just as many things are in the programming world.
And if you don’t already use git status. Do it. Just do. It. You’ll thank yourself.
