Git Beginners Guide

In this tutorial I’ll be going through the basics of using Git and covering the following topics:

  • What is Git?
  • Install and Setup
  • Adding and Committing
  • Branching
  • Tags
  • Remote Repositories
  • Resources

What Is Git?

Git is a version-control system that helps you to keep track of any changes that you make when you are working on a project. Git allows you to ‘roll back’ to previous versions and also ‘branch’ your code to test new features without changing your current stable code. Source control is invaluable if you are working in a team and Git is used to deploy Sinatra apps into the cloud at Heroku (more about that in the next post).

Git uses the command line prompt to enter commands, but there are many different GUIs for it on different systems (I’ve never felt the need to use these, but recommendations are welcome in the comments).

Install and Init

First you need to install Git.

If you are using Ubuntu or any form of Debian Linux then you just need to type the following into a terminal prompt:

~>$ sudo aptitude install git-core

If you are using another flavour of Linux, then it should not be too hard to install the git-core package using your built-in package manager.

Instructions for mac users can be found here. Sorry, but I don’t know how to install Git on Windows, perhaps somebody could help out in the comments? but luckily Jon provided a linke to Git for Windows in the comments.

Once you’ve installed Git, you should set up some global configuration values using the following commands:

$> git config –global user.name “yourname” $> git config –global user.email “yourname@email.com”

Now all you need to do is navigate to your project directory. We’ll use the project from my last post - Reverse, which I’ll assume is in a folder called ‘reverse’ in your home folder. Type the following at the command prompt:

~> reverse$ git init

This command creates a .git folder in the project folder which means that Git is now tracking any changes made in that folder.

Adding and Committing

Now we need to add all of the files to the repository we’ve just created. You do this by entering the following command:

~> reverse$ git add .

This will add all the files to the index because of the ”.” character means “all files”. The index is a kind of staging area where files wait to be committed to the repository. Let’s do that now:

~> reverse$ git commit -m "Changed some of the text"

This will commit all the files into the repository. The text in the quote marks after the -m is a message that you need to type with each commit so that you can see what you did at each commit.

Now make a couple of changes to your project - change a few lines of code (just make some simple changes to some of the text in the footer of layout.erb), then enter the following command in the terminal:

~> reverse$ git add layout.erb

Notice that you can specify to only add specific files rather than using ”.” to add all files to the index. Don’t forget to commit the changes to the repository:

~> reverse$ git commit -m "Changed some footer text"

The whole 2-stage process of adding then committing can get a bit annoying, but it allows you to add multiple changes before you actually make a commit. If you want to bypass this you can use the -a flag like so:

~>reverse$ git commit -a -m "some message here"

This will add and commit any changes all at once. But note that it won’t add any new files, you will need to use git add for this.

If you want to remove any files, you can’t just go deleting them from your desktop. You need to remove them from the git repository as well using the rm command. For example, we don’t actually need the file frank.erb, so we can remove it from the code with the following command:

~>git-example-project$ git rm views/frank.erb

This file will be removed from your desktop and the Git repository.

Branching

For me, this is the killer feature of Git. When you branch your code, you basically create a new copy of the current code. You can then make any changes or experiments without affecting the original code. If you want to keep these changes, then you can merge them back into your original code or if you don’t like the changes you can just go back to the original code and delete the branch. You can create as many branches as you like and merge them with each other or just keep them as separate branches.

You start with a default branch called ‘master’. To check which branch you are currently on, just type:

~> reverse$ git branch

You should see the following:

* master

The star next to master, indicates that this is the current branch.

To create a new branch called development just type:

~> reverse$ git branch development

To switch to this branch you need to type:

~> reverse$ git checkout development

Check that this has worked by typing

~> reverse$ git branch

You should see the following:

  master
* development

The star next to development shows that you are now working on the development branch. If you make any changes, they will only affect the development branch, not the master branch.

Try changing a couple of lines, add them, then commit them like before, then change to the master branch:

~> reverse$ git commit -a -m "made some changes to master branch"
~> reverse$ git checkout master

You’ll see the changes are not there! Go back to the development branch:

~> reverse$ git checkout development

And your changes are back!

The obvious use of branching is to separate the master and development branch of code, but because it is so quick and easy, you can use it to test out new features. Say I want to add a cool Twitter feed of reversed text in my development branch. First I’d create a new branch:

~> reverse$ git branch feature-twitter

Change over to the new branch (Don’t forget to commit any changes if you have made any):

~> reverse$ git checkout feature-twitter

Next, you would add your cool Twitter feature and test that it works. To save some time, why not just add a link to Twitter in the footer (it’s in layout.erb in the views folder in case you’re wondering). These changes will only affect this new branch. If you like these changes(and your link works) and want them in your development branch then you use merge. First you need to checkout the development branch:

~> reverse$ git checkout development
~> reverse$ git merge feature-twitter

Now the changes you made in the feature-twitter branch will be included the development branch. You don’t need the feature-twitter branch now because it was only used for testing, so you can delete it using the -d flag:

~> reverse$ git branch -d feature-twitter

When your development branch has been tested and is ready for the big time then you would just merge them to the master branch. Remember to first checkout the master branch, then merge in the development branch. Some people like to have separate staging and live branches instead of just a master branch to manage the different stages of a site’s development (you can have as many branches as you like).

Tags

You can tag a project at any time using the following command.

~> reverse$ git tag v1.0 "Version 1.0 of reverse app"

This lets you create snapshots of certain points in development - make sure you have added and committed any changes before tagging. If you want to see all of your tags, just type:

~> reverse$ git tag

If you want to revert to a previous version then you create a new branch for it. Say you want to go back to this version in the future (to make a hot fix for example), you would type:

~> reverse$ git checkout v1.0 -b version1

This will automatically create a new branch called version1 that will be an exact copy of the project when it was tagged v1.0, without losing any of your current work.

Remote Repositories

Github is an amazing service that allows you to keep your code in a remote repository, hosted on their servers. To get started, all you need to do is sign up for a free account, set up a new project and then follow their instructions on creating a new remote repository.

Once you’ve set up a remote repository, all you need to do is enter the following command:

~> reverse$ git push origin master

This will push all your code on the master branch to your github repository. This is useful for backup in the cloud and also sharing your work with others (perfect for open source projects!). If you want to keep your repository private then you would need a paid account on Github.

You can also start using other people’s code from Github by cloning their repositories and using the pull command to pull in any changes they make. They also have the option to pull in any of your changes. This makes git really powerful as a way of collaborating on projects, as it allows people to fix problems in your code, improve your code, or develop a completely new project.

Resources

Here is a list of Git resources that I’ve found useful:

  • Learn.Github - A work in progress, but already looking like it’s going to be a one-stop shop for git info
  • Git Ready- Full of useful tips and already available in 8 languages
  • Git Cheat Sheet - A usful diagram with all the useful commands
  • Another Git Cheat Sheet - an excellent overview of using git
  • Gittutorial- A walk-through tutorial that is very similar to this one, but covers more about shared working
  • Git Docs - Full documentation on each function
  • Gitcasts - excellent screencasts by Scott Chacon on a variety of git topics
  • Git Community Book - An in-depth open-source book (including a free pdf download) that covers almost everything to do with Git
  • Git for Windows - A series specifically aimed at using Git with Windows (Thanks to Jon for this link).
  • (Git Reference)http://gitref.org - Really well explained user guide.
  • (Git Ready)http://gitready.com/ - Full of tips and it’s being translated to several languages. Thanks to Matías Flores for suggesting this in the comments.

Git is an amazingly powerful piece of software that will transform your workflow on projects. It is also essential when it comes to managing and deploying Sinatra apps on the Heroku platform, which I’ll be covering in the next post. Have fun experimenting an leave any comments if you have any questions or suggestions.

blog comments powered by Disqus