ExpanDrive

Here is a great post by Mathieu Martin about how to use Git to maintain and extend a long term fork of a project.

Recently at GiraffeSoft we started a new project, based on another existing project we already had going. We could call this a long term fork.

I’m sure you’ve done this before. You were probably using Subversion, and your project is probably 2 years behind HEAD of the original project.

Your invariants probably looked something like this:

• * These projects will both keep being actively developed in the future;
• * They will have some fundamental differences that will not be reconciled;
• * They will however keep many similarities and we expect that they will benefit from the exchange of some specific patches, as development on both moves forward.

This happens all the time, especially in web development. You find a fantastic open source project to base your project on, but you need to customize and extend it. You also want to easily incorporate future features and bug fixes from the original project as they’re developed.

In days past, this problem could have been solved reasonably well by cloning the central repository and then exchanging patches and applying them manually.

I’ve tried this before. Remember that scene in the Dark Knight where the Joker makes the pencil disappear? It’s kinda like that.

As you’ve guessed already, we’ve decided to try using Git to help manage this long term relationship.

It’s still not going to be easy unless you control both projects, but using a setup like Martin describes will be much easier than checking the man page for patch as you try to merge in new features by hand.

Getting started with Git? Git for the lazy is one of the better starting points we’ve seen [via SvN].

There are a million Git cheat-sheets out there, but this one does a pretty good job at picking the more intuitive way of performing a particular task, and showing some sample commands to get it done. The How To Fix Mistakes section is particularly useful, and succint:

Haven't committed yet, but don't want to save the changes? 
You can throw them away:   
git reset --hard   

You can also do it for individual files, but it's a bit different:   
git checkout myfile.txt   

Forgot something in your last commit? That's easy to fix.   
git reset --soft HEAD^   

Then write over the last commit:   
git commit --amend   

Don't make a habit of overwriting/changing history if 
it's a public repo you're working with, though.

If I read another post with a laundry list of why git is useful, each bullet linking me to the man page, I’m going to scream. How much time do you think I have?

There is no shortage programmers coming over from Subversion who feel confused and perplexed by all that Git has to offer. My biggest complaint about Git is that there are quite a number of ways to accomplish a specific task, and it’s not always clear that the best practices are.