Git in 15 minutes

Git is a fantastic but complex source code management system. It allows for complex tasks and because of that, it is often regarded as too complex for simple, daily routine tasks. Let’s be honest for a minute: Git is complicated, let’s not pretend it is not. Still, I will try to teach you the (my) basic workflow of working with Git and remote repositories. In no more than 15 minutes.

Workflow

I will demonstrate the following workflow, which usually accommodates me when I work alone on a project on one or multiple machines:

1. Create a remote, empty repository (using BitBucket)
2. Add a project to a local repository
3. Work on new feature within a branch
4. a) keep the new feature or b) discard it
5. Maybe, come back at an earlier point in time
6. Push the local repository to the remote one
7. Get the content of the remote repository on another machine

Install Git

On most *nix systems (Linux, OS X, …), Git will already be installed. You can update it to the latest development release (not recommended) from Git itself by issuing the following command:

git clone https://github.com/git/git

On Windows, you can download the Git installer here. If you really need installers for other systems, the Mac OS X installer is here and the Linux instructions are here.

Create a remote repository

Many people like to use Github. I personally prefer BitBucket as it offers unlimited private repositories and that’s what I need the most. You can translate the following instructions to Github, the process is the same.

So, go to www.bitbucket.org and sign up for an account. Once done, log in and click on the ‘create’ button at the top. Fill in the form accordingly and make it a private repository. You wouldn’t want anybody to take a peek at the source code of your Facebook killer app now, would you?

You can now leave BitBucket, we have everything we need there.

Setting up Git

Before we can work with Git, we need to do a one-off configuration. In order for Git to track who made a change, we need to set up your user. I strongly recommend that you use the same username and e-mail address you used for registering your BitBucket account. Issue these commands replacing your_username and your_email@domain.com accordingly (notice the single quotes around the username):

git config --global user.name 'your_username'
git config --global user.email your_email@domain.com

We will also set the push default to ‘simple’. To understand what this means, have a quick read here (you don’t have to). Issue this command:

git config --global push.default simple

We are all set. You won’t need to repeat this config anymore on your machine but don’t forget it if you work on another computer. If you forget to do the initial set up, Git won’t let you commit anything and will nag you.

Create a local repository

For this example, we will pretend we have a website (the technology doesn’t matter) located in a ‘my_site’ directory within a ‘workspace’ directory on our machine. From the command line, go into your site’s root folder. On OS X and Linux:

cd ~/workspace/my_site/

…and on Windows:

cd c:\workspace\my_site

We first need to tell Git that this directory is a project we want to track. So we initialize a new local Git repository by issuing this:

git init

Git will create a hidden directory within my_site named .git and that’s your local repository.

Stage files

We now need to instruct Git that we want to stage all the files in the project. Issue this:

git add -A .

The ‘.’ at the end means ‘all the files, folders and subfolders’. If we wanted to only add certain files to source control, we could have specified them with:

git add my_file, my_other_file

Commit the files

Now, we want to commit the staged files. Read ‘add a point in time where your files are in a state you can revert to’. We always commit our files with a helpful comment, describing their current status. I always use ‘initial commit’ as a comment for the first commit.

git commit -m 'initial commit'

That’s it. At any time, you can now roll back to this commit. If you ever need to check the current status of your staged or unstaged files, commits, etc, you can ask for the git status:

git status

Branching

Branching is the act of creating a separate version of your source code, independent of your main branch. By default, each time you commit your files in Git, they’ll get stored in the ‘master’ branch.

Let’s say that now, you want to add a feature to your project but you want to be able to roll back to its current version in case something goes wrong or you decide to discard the feature. That’s when you create a branch. To create it and switch to your newly created branch, you issue this:

git checkout -b new_feature

Alternatively, you can create a branch first and then manually switch to it like this:

git branch new_feature
git checkout new_feature

To see all the branches of your current project, issue this:

git branch

You can now do whatever you want with your project without fear: at anytime, you can go back to a state before you created your branch. Note that you can have multiple branches at once and even create a branch from a branch.

Merging a branch

Once you are happy with your new feature, you want to add it to your master branch. You first need to stage your files and commit them while being in your new_feature branch:

git add -A .
git commit -m 'Add my new feature'

Then you move to your master branch:

git checkout master

Merging is done like this:

git merge new_feature

At this point, your master branch and your new_feature branch will be equivalent.

Discarding a branch

On the other hand, if you want to discard the changes you made inside a branch, you first need to stage your files and commit them within the branch:

git add .
git commit -m 'feature to be discarded'

and then, you move to your master branch:

git checkout master

Now, your code is in the state it was before you created the branch.

Deleting a branch

If you merged your branch to your master branch, from the master branch, issue this:

git branch -d new_feature

It will only delete the branch if the changes were merged. If the branch was not merged, you’ll get an error message. To delete an unmerged branch (typically, changes you don’t want to keep), you need to issue the same command with an uppercase D. This means ‘force delete the branch, I don’t want it anyway’:

git branch -D new_feature

Rolling back to a previous commit

At some point, you may want to come back to a previous version of your code. First, you need to find which version you want to come back to. To see all the commits that were done, issue this:

git log

It will output your commit history like this:

commit ca82a6d Author: your_username your_email@domain.com Date: Mon Nov 4 12:52:11 2013 -0700 Change the frontpage layout
commit 085bb3b Author: your_username your_email@domain.com Date: Mon Nov 4 11:40:33 2013 -0700 Add my new feature
commit a11bef0 Author: your_username your_email@domain.com Date: Mon Nov 4 10:37:28 2013 -0700 initial commit

If you want to come back to the commit ‘Add my new feature’, simply do a checkout using the commit ID (I usually only use the first 6 or 7 characters of the ID):

git checkout 085bb3b

You can even checkout in a new branch like this:

git checkout -b my_previous_version 085bb3b

Just don’t get too crazy! The more complex your branches, the harder it gets to figure out on what you are exactly working.

Pushing to a remote repository

The first time you want to push a local repository to a remote one, you need to add it to your project configuration. This is done like this:

git remote add origin https://your_username@bitbucket.org/your_username/name_of_remote_repository.git

Note that ‘origin’ here is a convention. It’s the alias of your remote repository but you could use any other word you’d like. You can even have more than one remote repository, you just have to give them different aliases.

Then, you want to push your local repository master branch to your remote one:

git push origin master

If you use Bitbucket, at this point, you will be asked to type in your password. Do it and your local repository will be pushed to your remote one.

Get a copy of your remote repository locally

If you don’t yet have a version of your remote repository locally (for example, if you start working on another machine you haven’t used with this project yet), you first need to clone it. Move to a directory where you want your repository to be copied and issue this:

git clone https://your_username@bitbucket/your_username/name_of_remote_repository.git

On the other hand, if you already worked on your project locally and only want to get its latest version from the remote repository, move into the project root folder and issue this:

git pull origin master

Aliases

Git lets you create shortcuts (aliases) for your most used commands. For example, if you don’t want to type each time git commit -m ‘some comment’ but rather type git c ‘some comment’, you can do so by adding an alias to your global git config like this:

git config --global alias.c 'commit -m'

Here is a list of the aliases I use:

git config --global alias.c 'commit -m'
git config --global alias.co 'checkout'
git config --global alias.cob 'checkout -b'
git config --global alias.br 'branch'
git config --global alias.m 'merge'
git config --global alias.a 'add -A .'
git config --global alias.s 'status'
git config --global alias.dbr 'branch -d'

Go further

Of course, there are many things more to Git than this. Especially if you are working with a team or on an open-source project with other people. If you want to know more about it, I recommend the official documentation and tutorial you can find at http://git-scm.com/documentation.

Have any tips and tricks, questions? Tweet to me or leave a comment!

If you are interested in learning how to code and get certified by one of the world’s top universities, visit exts.epfl.ch.