Develop Locally Using Git, Instead of Your Company's Crappy Version Control

At my new company (Ariba), I am forced to use a beastly version control system (Perforce) and it was really cramping my style. I couldn’t easily branch or check in small incremental changes (even locally), so I was going days to weeks without checking in, waiting until my code was production ready. This meant if I made a mistake and had to roll back, or wanted to maintain multiple version of a file, I had to manually maintain version and/or redo/undo work.

This week, I finally had enough, and decided to augment Ariba’s version control system by using Git locally for better control while I developed. The rest of this article describes how to mirror an existing repository with a Git one. We will be building a fictitious repository named example.

How do it…

Create and initialize the remote Git repo

Create the directory:

mkdir -p /pathToDesiredLocation/example.git

Change to that directory:

cd /pathToDesiredLocation/example.git

Initialize the Git repository:

git init --bare

Gitifying your existing version control

When starting a new project, clone the repository and begin coding:

git clone /pathToDesiredLocation/example.git example

Otherwise, if (like me) you are augmenting an existing repository with Git, move to the root of your existing repository or the desired part of the repository that you want to add Git to:

cd /pathToExistingRepoOrPartOfRepo

Activate Git on that directory:

git --init

Connect the remote repository to the local one:

git remote add origin /pathToDesiredLocation/example.git

Add all the existing files to Git and check it in (this may take a few minutes the first time):

git add .
git commit -m "cloning existing repo"
git push origin master

Maintaining your Git repository

Whenever updating the codebase from your company’s version control system, create a new commit with all changes:

# updated local repo from company repository
git add .
git commit -m "syncing to {CompanyRepoSystem} revision {RevisionNum}"
git push origin master

To make finding previous version easier, try tagging the sync commits:

git tag -m "{CompanyRepoSystem} revision {RevisionNum}" {OptionalCodeVersion} {CommitNum}

View existing tags using:

git tag -l -n

Make sure to push the tags to the remote repository:

git push --tags

How it works…

The first group of steps above show how to turn any directory into a Git repository that can be used as the remote for a local git repository. This article puts it on a local disk, but ideally it should be another server. At Ariba I have my remote on a mapped shared drive, in case my hard drive crashes, and so that my coworkers can easily use the remote as well.

The second group of steps show how to initialize your company’s repository (or only part of it) as a Git repository and set the origin to the previously created remote repository. This way, when changes are pushed they live both in the local repository and in the origin repository. If you are not worried about maintaining a remote backup or sharing with peers, then you could get away with only running a local Git repository. I do’t recommend a local only approach, but implementing it would only require the second group of steps and never pushing to the remote.

The last group of steps explains keeping the local Git repository in sync with your company’s version control. Syncing, committing, and pushing is all that needs to be done, but using tagging allows for better tracking of when changes were synced with Git and makes rolling back to previous version easier.

There is not an example of how to check code into your company’s repository, because I do not know your system. However, here are some guidelines that I am using:

  • Do all local development in branches and keep master in sync with your company’s repository to avoid conflicts and make syncing easier.
  • Before checking in, update master to your company’s repository, then merge the development branch and push to your company’s repository system.
  • If your company’s repository requires checkouts, checkout any modified files before merging the development branch.

There’s more…

The solution written here will work for everybody, but requires you to maintain a Git version control that is separate from your company’s version control. For most version control systems (including perforce) somebody has already written a bridge between it and Git. I recommend trying the bridge first, so you have tighter integration, before maintaining two version control systems.

For more Git-related articles, see: