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

From Bitpost wiki
No edit summary
No edit summary
Line 7: Line 7:
# Before you can start making changes to a project, you should get the code and make sure you can compile and run it.
# Before you can start making changes to a project, you should get the code and make sure you can compile and run it.
# The next requirement is pretty simple:
# The next requirement is pretty simple:
** access to the code in the svn development branch
* access to the code in the svn development branch
** my own branch off of the svn development branch
* my own branch off of the svn development branch
**ability to overlay the latest svn changes on top of changes in my branch
*ability to overlay the latest svn changes 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.
*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.


Notice how simple this is - I'm 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.
== Setup ==


<ul>
  I started looking into better ways to solve my problem, and ran into Linus Torvald's solution (git).   
<li>ability to work from several locations, pushing/pulling my changes to a central repo</li>
</ul>
 
Another basic source control requirement.
 
But <strong>try</strong> to meet this set of requirements with CVS or subversion (SVN).  No longer simple.  I started looking into better ways to solve my problem, and ran into Linus Torvald's solution (git).   


It's definitely a change to think in distributed terms when you're used to using CVS/SVN centralized repos
It's definitely a change to think in distributed terms when you're used to using CVS/SVN centralized repos

Revision as of 16:44, 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

  1. Before you can start making changes to a project, you should get the code and make sure you can compile and run it.
  2. The next requirement is pretty simple:
  • access to the code in the svn development branch
  • my own branch off of the svn development branch
  • ability to overlay the latest svn changes 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.

  1. 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. But try to meet this set of requirements with CVS or subversion (SVN). No longer simple.


Setup

 I started looking into better ways to solve my problem, and ran into Linus Torvald's solution (git).  

It's definitely a change to think in distributed terms when you're used to using CVS/SVN centralized repos