Track your changes to an open-source project with git: Difference between revisions
No edit summary |
|||
| (4 intermediate revisions by the same user not shown) | |||
| Line 13: | Line 13: | ||
== Overview == | == 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. | 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 | 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 == | == Implementation == | ||
I have used | 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. | |||
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.