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.
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).
Download the binary and install it like any other program.
Mac OS X
Download the binary, and then install!
# 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
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
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.
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
The result for Top Page Design’s Git repository looks like this:
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:
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
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'
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:
- Make change to file.
- Test change.
- Commit change.
- Upload change.
- 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:
- Make change to file.
- Test change.
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.
git push origin master. This pushes your changes to the remote repository.
- Upload your change to the web server.
- 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:
- Make change to file.
- Test change.
git push origin master.
- 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.
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.