Git is a free open source distributed version control system. Which sounds incredibly dull, until you need to revert to a prior version of your code, when it’s a godsend.
It’s software that manages your source code, by taking snap shots of it at particular points and stores them. You can view all these intervals as milestones in a timeline. This way it allows you to back track, restore code from particular points, and work in a team simultaneously.
One of the biggest advantages of using Git, is that it is a distributed system. This means everyone can have a copy of the code repository and work on it individually. Each person can push and pull to another repository should they choose to.
Through this tutorial, I’ll guide you through how to install and setup Git and the basic commands to get you started using Git quickly.
Installing Git
The easiest way to install git on a PC or Mac is to use the installer package. Go ahead and download the installer package from http://git-scm.com/downloads. Double click on it and follow the wizard to install Git on your computer.
Git GUI tools
If you don’t want to use the command line when using Git you can always choose one of the following Git GUI clients:
- Source Tree—Free, Mac and Windows
- Tower—$67.80 (approx.), Mac only
- SmartGit—$79 Mac, PC and Linux
- GitX—Free, Mac
- TortoiseGit—Free, Windows
Configuring Git
Now that Git is installed, let’s configure it. Set your own name and default email address:
$ git config --global user.name "Joe Bloggs"
$ git config --global user.email "joe_bloggs@address.com"
Creating your first Git repository
With our Git setup we’re ready to create our first Git repository. Go to your projects directory:
$ cd path/to/project
Run this following command to create a git repository:
$ git init
As you can see its incredibly simple to setup Git for a project. Whenever you need to use Git just run this command to get started.
We can now use the Git status command to check the current status of our repository:
$ git status
Status commands confirm there is nothing to commit, the current directory is clean.
We’ve initialized Git for our project but we need to register our project files for Git to track them. To add files to the project, list them out manually like so:
$ git add index.html style.css
If you prefer to have all your files in the working directory tracked, just type:
$ git add .
This will push all your files into Git’s staging area.
This is just to prepare the files ready to be committed. We have yet to actually commit this for Git to snap shot changes made to each individual file.
With the files/folders now tracked in Git we can move forward and commit our changes. Commits are are the most basic function of Git, they snapshot your changes. Every time we commit we need to supply a short summary to remind us what each commit is about:
$ git commit -m "Initial Commit"
Branching
Branching is a powerful concept in Git. If you wanted to develop new functionality but do not want to risk spoiling your project you create a branch which clones the main branch in a separate environment to safely test and develop new ideas. Once you are happy you can always merge this back into your main master branch.
$ git branch
Currently our project only has one branch as you can see from the output this is the default branch typically named master. It is prefixed with an asterisk to indicate this is the current branch we are on.
Let’s create a new branch to build some new custom features. To do this in the command line run:
$ git checkout -b new-features
We just created a new branch called ‘new-features’ and switched to this branch. If we run Git branch you’ll see this displayed:
In our new branch we’ll add in some new JavaScript files. If we do a git status, it will identify the new JavaScript files are untracked. So we’ll stage it and commit the JavaScript library:
$ git add .
$ git commit -m "JavaScript Library"
Currently these are the project files in our directory:
Now if we switch back to our master branch.
$ git checkout master
If you look at our project directory, you’ll see the JavaScript folder isn’t present. This is because we had committed all this to the new-features branch. That’s the beauty of branching: whatever you commit in one branch will not be visible in other branches.
To help visualise the Git commits in a tree view we can use a visualisation tool that is bundled with Git, called gitk. In the command line run:
$ gitk
This now opens gitk in a new window. Here you can view all the commits made in the top left corner. Each commit is represented as a dot accompanied with the commit message. It also displays the name of who committed this and the date in the next columns. Below are further information regarding the specific commit, what files are committed, and the change set.
You may notice this does not mention anything about the new-features branch. This is because gitk is only executed on the master branch. We can use the —all flag to display all branch commits. Close the gitk window and in the command line run:
$ gitk —all
Now we can see the commits made in all the branches including new-features.
Let’s say we finished working on our new features and are happy with the final result. Let’s merge our new-features branch into the master branch.
Close gitk and in the command line run:
$ git merge new-features
We just merged the new features branch into the main branch. If you look at our project files you will see the JavaScript has been merged in.
There are situations where you do not wish to commit everything to your Git repository—personally I use SublimeText as my text editor, but this software generates a .sublime-project and .sublime-workspace file which I don’t need to commit. Also your operating systems may generate empty files such as .DS_Store or trash files.
In the command line if you run a git status, you will notice Git will highlight these files and specify that they aren’t tracked.
To resolve this, we can use .gitignore, a !le listing all the directories and files you don’t want committed to the repository. Create a new file and name it “.gitignore” (make sure the filename has a dot preceding it). Inside this file add:
# Sublime Text generated files #
###########################
*.sublime-project
*.sublime-workspace
# OS generated files #
##################
.DS_Store
.DS_Store?
._*
.Spotlight-V100
.Trashes
ehthumbs.db
Thumbs.db
Anything prefixed with a hash will be commented out in this file. Now save the file. Run git status again, you’ll noticed both the Sublime Text generated files are no longer listed. The only file untracked is the .gitignore. Let’s add this and commit it:
$ git add .
$ git commit -m "git ignore file"
Once you hit a particular point in your development you’ll want to reference it. You’ll want to make releases, most often versioning your project. This is called tagging in Git. A tag is a static snapshot of the repository at that particular moment in time, referenced with a name. There are two types of tags. One is lightweight, a label to a pointer in your commit history; the other is the annotated tag, which contains more information including who was the original creator of this tag, date created and a short annotation message.
To assign a lightweight tag on the current revision, in the command line run:
$ git tag release-1.0.0.0
This names our tag with the parameter of release-1.0.0.0.
To create a new annotated tag we simply add a -a flag and a -m flag to apply a short annotation:
$ git tag -a release-1.0.0.0 -m "First full public release"
To view all our tags we have in a repository we run:
$ git tag
If you would like to view more information on a particular tag, use git show with the tag parameter:
$ git show release-1.0.0.0
This will show the full details on this particular tag, including the name of tagger, the date it was created and annotation.