Git: beginners quide

Here's an easy to read beginner friendly post, with examples, about getting started with Git.

Git is one of the things that seem daunting at first, but it’s actually really logical and simple. I’ve tried Tower and SourceTree GUIs for Git, but found them actually harder to use than the command prompt. Let’s get started.

The basics

Make directory and initialize a repository in it:

$ mkdir my-git-test && cd my-git-test
$ git init

Note, the following only creates the repo to your local machine, not in GitHub of course.

Now the repo is up, check what’s happening with it:

$ git status
On branch master

Initial commit

nothing to commit (create/copy files and use "git add" to track)

Nothing much, yet. Make some test files to your repository:

$ touch file-{1..10}.html

Then check the status again:

$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)


nothing added to commit but untracked files present (use "git add" to track)

Let’s imagine we want to commit these ten files. First we need to add them.

Adding files

Next up, the new files need to be added to the staging area, to be committed later on. There are mode to adding that first meet the eye, see below some common add commands:

$ git add <filename> # Add a specific file
$ git add .          # Add all changed files
$ git add -u         # Add untracked new files
$ git add -A         # All untracked new files and all changed files

In this case, since we only have new untracked files, git add -u would fit the bill pretty perfectly. But in reality, 99% of time it’s just easy use the -A flag: $ git add -A to just add everything. Go ahead and do so.

Now check the status again:

$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

    new file:   file-1.html
    new file:   file-10.html
    new file:   file-2.html
    new file:   file-3.html
    new file:   file-4.html
    new file:   file-5.html
    new file:   file-6.html
    new file:   file-7.html
    new file:   file-8.html
    new file:   file-9.html

Now it says “Changes to be committed”, instead of “Untracked files”. Next up: committing.

Committing changes

Now that all the files have been “staged” (added to the staging area with add), the syntax for commit is:

$ git commit

This commits all the files that were added before. If someone now looks the commit history of this repo, he/she has no idea what has changed in that commit (without looking at the files), so we better add a message to inform everybody of the changes:

$ git commit -m "Short description what was changed"

The -m flag stands for message and the bit wrapped in quotes after it is the actual message.

It sucks to to type a long message in the prompt, right? If you leave the -m flag and the message away and hit enter, git will pop Vim open right there in the prompt, you can type the message in Vim, where you have “more room”. Go ahead and do it:

$ git commit

Here you see what the Vim looks like: it shows you the files that have changed, and I have written a sample commit message there.

Screenshot 2014-12-26 18.24.35

The summary line should be no more than 50 characters long, and the rest should wrap at 72 characters. Writing good commit messages is a post of it’s own, but have a look at this comprehensive commit message guide.

After the message is ready, just save and exit (below is how to do that).

Vim briefly

Vim is a beast of and editor, and for sure will throw a neophyte off at first. For example, a simple task of closing the editor can turn into a funky adventure.

There’s two modes in Vim (actually there’s more, but two that matter in this case):

  1. Command mode: saving and copying, for instance, happens in this mode (press esc to get there)
  2. Insert mode: code editing happens in this mode (press a to get there)

So, after commit message is ready, you should press esc to enter the command mode, then type :qw (quit and write), or :x (the same thing) and hit enter. More on exiting Vim here, and a tutorial here.

If Vim is too enigmatic for you, the default editor can be changed, for instance, to nano:

$ git config --global core.editor nano

Or to Sublime Text:

$ git config --global core.editor "open -a 'Sublime Text'"

Put it online

So far, the code is only good for you since it sits on your hard drive, you might want to consider putting it in the interwebs for everybody to see and fork. Head to GitHub or BitBucket (or other such service) and make a repository. In GitHub there is a big + button in the top right, and in BitBucket there is a juicy, blue, “Create” button on the top of the screen.

After the repo is done, grab the SSH or the HTTPS URL from the “Clone” field, it should look something like this: or Now point the local repository to that remote repository:

$ git remote add origin

If the repo has a remote origin already, it can be repointed like so:

$ git remote set-url origin

And, now, push!

$ git push origin master

That’ll push the whole project to the remote repo.

In the first push the branch needs to be defined origin master, after that issuing only $ git push will do the job.

If you’re unsure, whether you set up the remote origin already or not, or if it’s the right remote origin, it can checked with the following command:

$ git remote -v
origin (fetch)
origin (push)


It’s also possible to pull changes from a repo:

$ git pull


Cloning is basically a fancy term for downloading, kinda.

In GitHub the clone URL can be easily found from the sidebar, same goes For BitBucket. The syntax is apt:

$ git clone

Or with HTTPS:

$ git clone

That’ll clone the project into a directory called foo-bar, in your working directory. If you want to clone it straight into the root use dot in the end:

$ git clone .

Or change the dir name:

$ git clone something-amazing

Local repo can also be cloned, change the URL to absolute path:

$ git clone /path/to/local/repo/foo-bar


That’s the very, very basics. But those commands cover about 80% of everyday Git usage (roughly [for me at least {sometimes}]).

Club-Mate, the beverage →