Git Theory and Basic Commands

Categories coding, git, github, version control

Github is an extremely useful place to be able to make free use of, but the reason it’s so neat is because Git itself is neat. 

Git is a version control system that most basically is able to take snapshots of your code as you develop a project. Not only does it allow you to take snapshots of your code in one linear progression, but it also allows you to ‘branch’ into different version of code projects for specific feature development, which will ultimately be automatically merged back into the main branch, unless there are merge conflicts, which git will help you manually merge.

As a developer, knowing Git is a must. 

Here are some of the most basic commands that one should know in using git: (please note that these commands are in conceptual order, not necessarily in the order you would run them in the CLI)

1. git init

Initiates a git repository in the folder this command is called in.


2. git commit

The commit command actually takes the snapshot of your code and stores it in what it calls a HEAD. This will take you to a vim editor screen which will require that you specify a message about your commit. To avoid being taken to this screen and specify a message in the original commit command, you can write git commit -m ‘First commit’.  ‘-m’ allows you to specify a message.

3.  ‘git add .’ 

The first command requires understanding the concept of staging and tracking. Before git commits files in a directory to a snapshot, it first must know which files to snapshot. When you tell git which files it needs to pay attention to, you are telling it which files to track.

Running git add . tells git to start tracking these files in the sense that it will pay attention to any changes made within them.

When you run git add . , you not only tell git which files to track, but you also ‘stage’ files. Telling git to stage changes in a file is like telling your files to pose right before a picture, or, saying something to the effect of, ‘Look at all the changes I’ve made to these files. The next time I tell you to take a snapshot, these are the changes I want you to commit’

If you try to run a commit snapshot while files that git has been tracking have unstaged changes, it will throw an warning telling you that it notices that there are changes to files you told it to track that have not been added to the staging ‘platform’.

So, running git add . will do two things: 1: if there are any files in the directory (other than .git files, which it ignores) that have not been added to it’s tracking list, it will add them and start paying attention to them, and 2: even if all files are already being tracked, it will take all of the changes made to tracked files and ‘stage’ them, preparing them to be frozen in place with a snapshot record.

4. git log, git checkout

I have been working on a web app for a month. I’m pretty proud of it at this point, but let’s say at some point I’m sitting there looking at the interface and in a painful reality check realize that the original styling I had for the app was way better than what I banged out on the keyboard at 3 AM one night last week. At this point, in terms of the folder I’m coding in, my original designs are completely gone. I’ve edited them away a hundred times over.  But since I’ve been pushing my changes to git daily, if not hourly, I can simply temporarily revert back to a snapshot of my app when I had the design files exactly how I like them.

I run git log , which will give me a list of all of the commits I’ve made on the project. I find the ID, or SHA of the commit I want to revert to and copy it to my clipboard. I then run the command git checkout <commitID>, and suddenly all my code in my text editor and in my file folder containing my code is reverted back to a week and a half ago. I start my server back up and now the app looks just like it did. I copy the design files out, then I run git checkout master and everything is back to my most recent commit. How cool! This is a powerful tool for working solo and working together on code.

5. git branch, git checkout -b <newbranchname>

Running git branch will list all available branches in your code.  Running git checkout -b <branchname> will create a new branch of the name you specify. git branch -D allows you to delete a branch.

6. git merge <branchname>

Allows one to, from the master branch, merge all changes from a feature branch into the master branch. Many times this will go smoothly, but other times there will be some merge conflicts that need to be addressed.

7. git push

Pushes your git commit(s) to an online repository. Usually this will be Github. In order for this to work, however, you must specify an online repository and authenticate yourself. The first thing you will need to do is create an online repository on Github. Say I’m pushing local git repository to a Github repository I’ve just created at the address of  I’ll want to run the command git remote add origin and then push it to the repository with git push -u origin master.  The -u origin master specification tells your local git repo that you want to save the upstream ‘origin’ or source of the git as master. When you create a branch, you’ll push your branch to -u origin <branchname>. 

After running this you should see your changes show up on git-hub’s website at your URL!

8. git pull

Git solves the problem of everyone not sitting in the same room connected to the same network (actually, this could cause it’s own set of problems, but no need to elaborate). Imagine I have been working on a collaborative app with my friend and I take a week off working on it. If he continues to work on it, then when I return I will be making changes to outdated code if he doesn’t send me the updated files. But sending source files via emails or however one might want to send them these days is not always efficient. If my friend has been pushing his changes to github, all I need to do is ‘pull’ his changes down to my local repo. So, if I have a local repo and the upstream origin is set, all one need do to ensure he or she is up to date on the most recent changes is run git pull. This will bring all changes down to your repo and merge them without any effort on your part, unless there are merge conflicts.

9. git clone

One can use this command to clone an online repository and all its settings down to a folder on their local PC. If I wanted to work on my ‘testgit’ project on another computer, I could just ensure that I had pushed all changes on the original computer, then move to the next computer and run git clone, and suddenly a folder with all of the code, past commits, and branches, and settings shows up on my PC.


Leave a Reply

Your email address will not be published. Required fields are marked *