Because Git is decentralized, it doesn't require a central repository that only allows access to a privileged few. This significantly lowers the technical barrier to be able to contribute back to an open source project.
However, without the rigid centralized structure, procedures need to be established to effectively share those contributions. Otherwise you're left with a group of individual developers instead of a development community.
The Pull RequestThe standard way of informing other developers that you've completed an update that they should look at and incorporate into their own work is with a pull request. This can be done in any number of ways including:
- Email
- Blog Post
- Pull Request message sent via GitHub
The information that's included in the request should uniquely identify what's to be pulled and where it should be pulled from:
- Commit ID or branch name
- Repository URL
- A brief description of the change
The problem is that communicating updates via pull requests doesn't scale very well. A (very) small project might be able to handle exchanging updates this way but developers in larger projects will find it harder and harder to keep up with the changes.
And if everyone starts cherry picking the requests according to their immediate develop needs, the individual Git repositories will start to diverge, making it harder to share updates.
Creating a Working StructureThe answer is to set up some work hierarchy in which some developers become responsible for merging the code for certain sets of pull requests, collecting and integrating those features, fixes or specific release updates. Instead of having to handle the individual requests, developers in the community can simply pull the "integration" branches from designated repositories and be assured of receiving the updates they need or are just interested in.
(Consequently, the hierarchy does create a de facto central repository, which at first is seemingly in conflict with the spirit of Git. However, nothing is technically special about the repository or the designated integration repositories. As long as the integrations are pulled from them or recreated via the re-processing the appropriate pull requests from the same starting point, any other repository can take its place.)
Small EffortsIn a small team, one developer should take the responsibility for merging updates and have his repository store the "integration" branch. This can either fall naturally (for instance, the leader of the project) or be designated (drawing straws).
If for any reason, this individual decides he doesn't want the integration responsibility, then all that's required is for someone else to pick up the torch. The rest of the team just needs to update their local repository and tracking branches with the new remote repository connection.
Large EffortsA large effort is simply a collection of small effort teams (grouped because of features, project or just association). It can range from fairly flat (a single layer) to a complicated multi-layer structure.
But even at its most complicated, the structure at a single point is simply a designated integration repository taking pull requests from a set of developers.
|
|
