The Git Vision Control System is usually seen as a way to share code between many distributed programmers. However, most companies are already using and prefer to use a centralized control system such as Subversion or Perforce. Git is still a powerful tool even when you only use it on your own machine.

You can use Git like a ninja, managing complex changes locally, then only checking in clean working code to the shared depot. No one even has to know you are using it at all.

Here are some scenarios where I've found Git handy.

The Quick Fix

How often have you found yourself in this situation? You're midway through on a new feature, and suddenly you need to drop everything to fix something that's blocking the entire team. But the code on your machine is torn apart and broken. You need to quickly get the latest code in order to make the fix.

Git has several ways of accomplishing this. The easiest is git-stash.

> git stash
Saved working directory and index state "WIP on master: 2717a6c... new files"
HEAD is now at 2717a6c new files
(To restore them type "git stash apply")

This saves a patch of your local changes. Now you can sync to the latest shared code and make your bug fixes. Once you've submitted your fix to the shared repository, restore your previous progress using:

> get stash apply

This method works fine if there aren't big differences between the shared depot and your local work. I prefer to use another method if the differences are big.

The Big Change

When you're working on a feature that could take as long as a week to implement, other people are working on the same code, unaware of your pending feature. If you wait until your work is complete before you integrate their changes you'll have a ton of hairy conflicts to resolve.

With Git you can make a local branch of your feature work. This gives you the ability to integrate coworkers changes early and often, saving you pain later.

Here's how I setup my workflow. I have two local branches depot and feature.

At least once a day, I update my depot branch with the current state of the shared repository. If perforce is holding shared depot, this can be done as follows.

> git checkout depot
> p4 sync -f
> git add .
> git submit -a -m "daily sync"

This step can easily be automated.

I'll then use Git to merge the latest changes from the depot branch into my feature branch.

> git checkout feature
> git merge depot

Because this happens at least daily, the conflicts should be small and easy to manage.

Once the work on the feature branch is complete and fully tested it can be directly submitted into the shared repository. At that point, there really isn't any more need to keep the feature branch up to date. I just leave it and create new feature branches as needed.

A/B Comparison

Branches are also useful for quick comparisons between two code snapshots. I've used this often when doing performance tuning. Use git checkout to switch between the original code and an optimized version.

These are just some of the Git features that can be done locally. Even without the networking it's a very useful tool.