What is Git?

From the Git website:

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Some History

In 2005, BitKeeper stopped being free to use — forcing the Linux kernel developers to look for a different versioning system. After analyzing the various other free alternatives they found that none were fast enough for their needs. So right after the 2.6.12-rc2 Linux kernel development release, Linus Torvalds set out to write his own versioning system. Development began in early April 2005, and just before Christmas of that year the first version of Git was released.

Getting Started with Git

The first thing you need to do is get Git (excuse the pun).

Windows

Download the binary and install it like any other program.

Mac OS X

Download the binary, and then install!

Linux

# Ubuntu
sudo apt-get install git

# Fedora (run as root)
yum install git

# Arch (run as root)
pacman -S git

If you don’t use one of those distros, you probably know what you’re doing, but if you get stuck there is always Google DuckDuckGo!

Setting up Git

Now that we have Git installed, the next step is to set it up for our project. To set up Git, open up your terminal (command prompt in Windows) and run the following commands.

cd PATH_TO_PROJECT
git init

This puts a folder named .git in our project directory. This is where our project history and Git settings specific to the project will be stored.

Our first commit

A commit can be compared to saving a file. It saves the changes we have made and stores them in Git. It also gives us a point to go back to should any future changes need to be reverted. But before we make our first commit, we need to tell Git to track our files so that their changes will be recorded in our commits. This is as easy as running the following command.

git add -A

The add part tells git to add the next argument (either a file name or an expression) to commit queue. The -A part tells it to add all the files in this directory and any sub-directories.

Now let’s make a commit.

git commit -m 'initial commit'

commit is self-explanatory, and -m means the next argument is the description of the commit.

Future Commits

Let’s say we changed index.php. Committing this is easy enough.

git commit index.php -m 'changed index.php'

Now let’s say we created a new file called styles.css and we want to commit it. Simple enough, we just do this:

git add styles.css
git commit -m 'added styles.css'

But let’s say we changed a whole bunch of files, and now we want to save all the changes under one commit. To do this, we can use the -a argument, like so.

git commit -a -m 'Lots of changes'

What if we only want to commit changes in one directory? Or what if we only want to commit changes to PHP files? Just do the following:

#Commit changes in one directory only
git commit directory/. -m 'changed changed files in directory'

#Commit changes for PHP files only
git commit *.php -m 'changed PHP files'

Viewing the Git tree

Now that we have made a few commits, we may want to see our history, either for analysis or just to boost your ego. This is pretty easy, all we do is run

gitk

The result for Top Page Design’s Git repository looks like this:

Gitk screenshot

Admittedly, this is a pretty ugly tool, but that’s what alternatives are for! My personal favorite is gitg. The same tree displayed with gitg looks like this:

Gitk screenshot

Reverting changes

So you’ve been using Git for a little while, and now you have made a bad commit and want to get rid of it. To do this you can just run

git checkout <commit_hash>
git commit -m 'reverted changes'

Hey! what’s this about a commit hash? Well, here’s how it works. Every commit you make has a description and a hash as an ID. We can get the hash either with gitk or a similar program (like gitg), or through the command line with

git log

which will output something like this

$ git log
commit 5e6ad44f6a66897d466a0ceba20f18ad2228c1a2
Author: JohnDoe
Date:   Sat Jun 21 22:05:27 2014 -0400

    commit 3

commit 84db7a6556ec5b1709ea651d8a71a2f137b1f11b
Author: JohnDoe
Date:   Sat Jun 21 22:05:27 2014 -0400

    commit 2

commit 10fd644b5a9cc16e6907d0eaab1b8c3077437472
Author: JohnDoe
Date:   Sat Jun 21 22:05:27 2014 -0400

    commit 1

See those long strings after the word commit? Those are your hashes. So, to revert to how things were at commit 1, we can just do

git checkout 10fd644b5a9cc16e6907d0eaab1b8c3077437472
git commit -m 'reverted changes to commit 1'

Then running git log will give us

$ git log
commit 486766b6ea4c4039937db945d26b80c982a4cc26
Author: JohnDoe
Date:   Sat Jun 21 22:05:27 2014 -0400

    reverted changes to commit 1

commit 5e6ad44f6a66897d466a0ceba20f18ad2228c1a2
Author: JohnDoe
Date:   Sat Jun 21 22:01:15 2014 -0400

    commit 3

commit 84db7a6556ec5b1709ea651d8a71a2f137b1f11b
Author: JohnDoe
Date:   Sat Jun 21 20:08:07 2014 -0400

    commit 2

commit 10fd644b5a9cc16e6907d0eaab1b8c3077437472
Author: JohnDoe
Date:   Sat Jun 20 08:06:37 2014 -0400

    commit 1

What to do next: Sample workflows for web developers

Now that we have explained the basics of Git, we can talk about some of the ways web developers can optimize their workflow with it.

First workflow example: Git as a history tracker

This is pretty simple, basically all you do is run git init on your project when you start, and use Git to help you stay organized and to store your history. Here’s the workflow for a sample change:

  1. Make change to file.
  2. Test change.
  3. Commit change.
  4. Upload change.
  5. Test change live.

This is good if you have conventional shared hosting and you are the only developer. If you have multiple developers working on the same project, you should use the next workflow.

Second workflow example: Use a remote repo for collaboration

To achieve this setup you will have to either create a bare Git repository on your own VPS, or you can use an online Git service like GitHub, BitBucket, or Gitorious. BitBucket lets you make private repositories for free (GitHub requires a pro account), so if you want to keep your source code private they would be a good choice.

After you setup the remote repo, you should push your project there, using their ‘Getting Started’ tutorials. Then give the other collaborators access to the repo.

The workflow for a sample change then would be:

  1. Make change to file.
  2. Test change.
  3. Run git pull origin master. This makes sure that you have the latest changes on your local machine. If changes were made by another collaborator to the files you edited, you may need to use a merge tool to make sure your changes aren’t overwritten.
  4. Run git push origin master. This pushes your changes to the remote repository.
  5. Upload your change to the web server.
  6. Test live.

Third workflow example: Git as a deployment method

To setup this workflow you need to have your site hosted on something like Openshift. Top Page Design uses this workflow.

After you have set up your Openshift account and pushed your project there, you can start pushing changes. A sample workflow for this setup would be:

  1. Make change to file.
  2. Test change.
  3. Run git push origin master.
  4. Test it live.

This is nice and seamless, and removes the upload step from the workflow. If you want to collaborate with Openshift, check out their tutorial on it.

Conclusion

Git prevents headaches caused by lost source code, bad changes, and overwritten files by other collaborators. Many web developers overlook it because they do not understand how it can help them, and I hope that this article will throw some light on the ways it can help.

About Mark Fischer, Jr.

Mark is a web developer and programmer. He likes reading classic novels, listening to classical music, skiing, and eating donuts.

Filed under git, tutorial