Gitting Started with Git – Quick and Dirty

Git Trunk
I’m sure you guys have heard about Git. It’s been making a lot of waves lately. It seems that I’m always the last to jump on the bandwagon when it comes to things like that, but I’m finally here.

Introduction

There are tons of Version Control Systems (VCS) out there: Source Safe (Microsoft’s Baby, which sucks by the way), CVS, and SVN. Git is different from those in one major way: It’s a distributed system as opposed to a centralized one. That means, there is no central repository that users check out revisions from. There can be a central one, but it’s not a requirement. Every use has a complete copy of the entire repository on his system at any one time.

I’m only (intimately) familiar with SVN. So you can read more on the differences between Git and SVN. They range from faster processing, due to the fact that everything is local; to reduced disk space usage by Git.

Personally, Git is a great choice for my type of work. Sometimes, I just want to have Version Control in one directory for one project. I don’t want to get messy with all the central repositories and servers and everything like that. Also, if you travel, you just slap that entire folder on a USB drive and take it to any other computer and continue working. If that computer has Git installed, you can perform your commits or you can wait to commit when you reach home.

Let’s Get Started – Installation and Setup

First off, let me apologize to the Linux users. I found one simple git tutorial for Ubuntu. Everything else pointed to building from source. I guess that’s not that hard.

Windows and OS X users are in luck. There are prepackaged installers for both systems.

For Windows, download the msysgit package and you’re ready to go. If you think you need more of a UI you can get TortoiseGit, which is a shell extension for Windows Explorer. One plus I’ve noticed with this tool is that it has a great diff viewer. Be advised: I’ve been warned that git is slower on a Windows system, so you might want to avoid Windows for those huge projects.

OS X users also have a great option: OS X Git Installer. Or you can build from source like the other Linux users.

There’s not much to set up after that. Most of the Git usage is from the command line, so there’s no need for any other fancy tools.

Now, there are a ton of tutorials out there on how to get started, so I’m not going to bore you with that, but I will highlight some of the things I’ve found.

Hosting Remote Repositories

One of the great advantages I’ve found with Git is that it doesn’t need a central or remote repository. That’s great if you don’t need to work offline. However, that’s not to say it can’t have one.

I’m sure everyone has heard of GitHub. This is, by far, the major Git hosting service. But, there are limitations (of course). Their free plan doesn’t allow private projects and it’s limited to 300 MB in size. There are some other places where you can host Git projects, however if you already pay for a web hosting service you may have all you need.

The only requirement is that the service allows SSH shell access. After that, you’re good to go. There’s a lovely tutorial on how to install git on a shared host. Even if you don’t want to read the tutorial, you can just copy and paste the commands.

Currently, I’m on HostMonster’s hosting service for $8/month. So tacking Git onto that already existing host just made sense.

Git Work Flow (And Modification) I’ve Adopted

Some time ago, I stumbled across this article on web based work flow for Git.

The key idea in this system is that the web site exists on the server as a pair of repositories; a bare repository alongside a conventional repository containing the live site. Two simple Git hooks link the pair, automatically pushing and pulling changes between them.

It’s actually a great idea. You have one central repository or hub and one “live” site. The hub has is a bare repository; it has no workspace and you can’t checkout any files. The prime, however, has it’s own work space, which hosts your live site.

When you push into the hub the hooks (set article for setup) automatically push those changes over to the prime or live repository. Likewise, the prime has hooks that function when a commit is done: they push changes back to the hub. So ideally, all your major development would be pushed to the hub which, in turn, pushes those changes to the live site. Now if you make a one off change to the live site (who says that never happens) you can hit commit and it will push those changes back to your hub.

I don’t need that level of automation for what I’m doing. So, I do have a central repository, however, I push to my live site directly. I have a branch in my project called live when I merge or rebase stuff from master into. I think push this branch to the live site. My live site has a hook that does a simple git reset --HARD in the working directory to update everything.

That’s all I got for now.

Comments

  1. Not so fast about Linux users and git: Since Linus Torvalds originally wrote git for the Linux kernel and git is primarily developed on Linux then there is in fact tons and tons of git tools available for Linux. In fact, the windows and mac software are merely ports of the original Linux tools. All major distros (and probably all minor distros for that matter) come with git tools available. For example, in Fedora 10 we have the following git tools available to install directly from the standard repos… there is no need to build from source:

    git.x86_64 : Core git tools
    git-all.x86_64 : Meta-package to pull in all git tools
    git-arch.x86_64 : Git tools for importing Arch repositories
    git-cola.noarch : A highly caffeinated git gui
    git-cpan-patch.noarch : Patch CPAN modules using Git
    git-cvs.x86_64 : Git tools for importing CVS repositories
    git-daemon.x86_64 : Git protocol dæmon
    git-email.x86_64 : Git tools for sending email
    git-gui.x86_64 : Git GUI tool
    git-svn.x86_64 : Git tools for importing Subversion repositories
    gitk.x86_64 : Git revision tree visualiser
    gitosis.noarch : Git repository hosting application
    gitweb.x86_64 : Simple web interface to git repositories

    Anyway, nice intro, I keep wondering whether it’s worth moving from SVN but can’t really see that the advantages yet outweigh the cost of learning and setting up a new system. It’s always good to read other people’s experiences though.

    Chris’s last blog post..How-To: Automated incremental daily backups to Amazon S3 using Duplicity

    • The info is much appreciated Mr. Chris. I know Git is Linux (Unix) based (hence the interesting Windows Port). I was talking about the original install. When I Google “Windows git” or “OS X git” the first result is the installer page and you’re off and running with basic tools like “gitk” and “git gui” (which are all you really need, if you ask me).

      The general problem I have with Linux is the lack of Documentation (oh, I’m going to get some pressure for this comment :) ) or the hidden nature of it. It is often assumed that Linux users already know mots of what they need.

      The Ubuntu guide that I did find would suggest that Git would be included in the repository for Debian (and I’m assuming you can also Yum it for Fedora). I just didn’t include those, because I personally have not yet done these myself.

  2. Yes, its sometimes a bit overhead to have a repository (with Git a bare repository) and a working copy (which is at the same time the web-root). I think this comes a bit from the knowledge of other VCS systems like SVN which needs a central repository. But distributed version control systems doesn’t need a central repository.

    For me the master branch is every time the main branch and so also the “live” branch. Testing and other things are done on additional branches which can be later merged with the master.
    This easy handling with branches is the big advantage over SVN. “SVN has not a internal concept of a branch, only copies”.