Track your changes to an open-source project with git: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
Here are quick and easy steps to track your changes to an open-source project. | Here are quick and easy steps to track your changes to an open-source project. | ||
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. | 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. | ||
| Line 5: | Line 5: | ||
== Requirements == | == Requirements == | ||
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. | |||
* | The next set of requirements is pretty simple: | ||
* I need my own branch off of the svn branch. | |||
*ability to overlay the latest svn changes on top of changes in my 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. | 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. | |||
*ability to work from several locations, pushing/pulling my changes to a central repo | *ability to work from several locations, pushing/pulling my changes to a central repo | ||
Another basic source control requirement. But <strong>try</strong> to meet this set of requirements with CVS or subversion (SVN). No longer simple. | 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. | |||
== Setup == | == Setup == | ||
NOTE: I'm going to use mythtv in this example, because that's what I wanted to work on. | |||
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! | |||
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? | |||
Revision as of 17:12, 28 January 2008
Here are quick and easy steps to track your changes to an open-source project.
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.
Requirements
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.
The next set of requirements is pretty simple:
- 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 need 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.
- ability to work from several locations, pushing/pulling my changes to a central repo
Another basic source control requirement, and we're done.
But try to meet this set of requirements with CVS or subversion (SVN). No longer simple. Enter git.
Setup
NOTE: I'm going to use mythtv in this example, because that's what I wanted to work on.
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!
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?