Track your changes to an open-source project with git: Difference between revisions

Latest revision as of 01:14, 3 May 2012

Purpose

Here are some of the projects on which I have overlaid my code, with the help of git:

mythtv
ampache
wordpressmu (now integrated into wordpress)
recess
a proprietary project hosted privately behind an openvpn connection

All of these currently use subversion, which git can read from and write to. Some of them (read: "mythtv") are insanely active. Git can help you remain sane while you try to overlay your changes on top of a moving target.

Overview

Historically, source control always kept your code in a central location, and each developer checked out file(s) when they wanted to do modifications. Sometimes you could not get access to a file because someone else had checked it out with exclusive access.

Open-source culture has no tolerance for this. Typical source control for open-source projects does not rely on checking out files. Anyone can grab the files and modify them at any time. Then conflicts are dealt with when you want to commit your files back into the central repository. The headaches are left for when you merge changes back into the project that has completely changed from under you.

git was made to ease life within this environment. But you have to step back and adjust your way of thinking. Code flows in every direction, and every developer is her own central repository.

Implementation

I have used three approaches, in reverse chronological order:

Managed publishing of your personal git repository - this is how I currently work, publishing my code in a clean controlled way to a gitorious repo.
Work on an open-source project from anywhere - this was a popular approach for a while, using an SVN-based master repo.
Setting up your own public repo on top of an open-source project - this is a technique useful with an SVN-based master repo but probably overly complex.

@@ Line 1: / Line 1: @@
-Here are quick and easy steps to track your changes to an open-source project.
+== Purpose ==
-Once you get a handle on git, you'll find it very powerful.  But getting started can be the biggest challenge.  Distributed source control requires a different way of thinking than using a central repository.  Use this to get past the first hurdles.
+Here are some of the projects on which I have overlaid my code, with the help of git:
-== Requirements ==
+*[http://www.mythtv.org/ mythtv]
+*[http://ampache.org/ ampache]
+*[http://mu.wordpress.org/ wordpressmu] (now integrated into [http://codex.wordpress.org/Create_A_Network wordpress])
+*[http://recessframework.org/ recess]
+*a proprietary project hosted privately behind an openvpn connection
-Before you can start making changes to a project, you should get the code and make sure you can compile and run it.  In this guide, we assume that the project is currently under SVN control.  Check out a copy and get it up and running.
+All of these currently use subversion, which git can read from and write to.  Some of them (read: "mythtv") are insanely active.  Git can help you remain sane while you try to overlay your changes on top of a moving target.
-The next set of requirements is pretty simple:
+== Overview ==
-* I need my own branch off of the svn branch.
-* I need the ability to overlay the latest svn changes, over time, on top of changes in my branch.
-Notice how simple this is - we're not even asking to commit anything yet.  These are fundamental requirements that any developer on a non-trivial open-source project would have.  You <strong>need</strong> to do this if you are going to bang on an open-source project.
-Now let's add one more requirement.  I'm going to have this code on at least three different machines, so I need to be able to have a common repository for my changes.
+Historically, source control always kept your code in a central location, and each developer checked out file(s) when they wanted to do modifications.  Sometimes you could not get access to a file because someone else had checked it out with exclusive access.
-*ability to work from several locations, pushing/pulling my changes to a central repo
-Another basic source control requirement, and we're done.
-But <strong>try</strong> to meet this set of requirements with CVS or subversion (SVN).  No longer simple.  Enter git.  It was born to do this job.  If you're with me so far, and it sounds like we're on the right track, I promise you: step through the rest of this guide and you'll be happy you did.  Let's get to it.
+Open-source culture has no tolerance for this.  Typical source control for open-source projects does not rely on checking out files.  Anyone can grab the files and modify them at any time.  Then conflicts are dealt with when you want to commit your files back into the central repository.  The headaches are left for when you merge changes back into the project that has completely changed from under you.
-== Setup ==
+git was made to ease life within this environment.  But you have to step back and adjust your way of thinking.  Code flows in every direction, and every developer is her own central repository.
-NOTE: I'm going to use mythtv in this example, because that's what I wanted to work on.
+== Implementation ==
-Create a local git repository of the project's subversion repository, using git-svn.  There are two ways to do this.  If you do not specify a svn revision number, git will grab the entire history of the project as it is available in the svn repo.  WARNING: this may be HUGE for older bigger projects!
+I have used three approaches, in reverse chronological order:
- git svn clone http://svn.mythtv.org/svn/trunk/mythtv mythtv
-If you specify a revision number, git will grab just that version, and then we can grab all changes after that version, too.  It's probably worth digging into the project history to find a reasonable revision number.
- git svn clone -r15502 http://svn.mythtv.org/svn/trunk/mythtv mythtv
-We now have a repo of the project under git control.  Simple, eh?  git uses branches, and named our svn grab the "master" branch in this repo.  See the list of branches:
- git branch
-Now we can easily update our master branch with the latest svn commits at any time.  Do this now to make sure you're completely up-to-date:
- git svn rebase
-Now we create a branch of our own, from the SVN base.  git loves branches!
- git checkout -b mybranch
- git branch
+#[[Managed publishing of your personal git repository]] - this is how I currently work, publishing my code in a clean controlled way to a gitorious repo.
+#[[Work on an open-source project from anywhere]] - this was a popular approach for a while, using an SVN-based master repo.
+#[[Setting up your own public repo on top of an open-source project]] - this is a technique useful with an SVN-based master repo but probably overly complex.
-tbc...