Git IzPack workflow
Branches and tags conventions
For the Codehaus repository:
masterrefers to the main development branch (equivalent to a Subversion trunk)
a.brefers to a branch for the
5.1is the parent branch to prepare the
5.1.1and so on releases)
va.b.crefers to a release tag (e.g.,
Each developer is free to name his/her topic branches as they want as long as the name remains meaningful. We strongly advise to use the related JIRA issue name if possible (e.g., name your branch
IZPACK-123 if it refers to
Given that Git is a distributed system, anyone can clone a Git repository and maintain changes locally. This is fundamentally different compared to a centralized system like Subversion where only commiters can put their changes under version control.
We distinguish 3 types of Git repositories:
- the blessed repository where only IzPack developers have write access (like with any centralized system)
- IzPack developers repository which allows them to collaborate and publish changes before they can make it to the blessed repository
- external people repositories that can be used to maintain customized versions against upstream changes, and that can
also be used to offer new contributions to the IzPack developers that can easily pull them from their repositories.
The following figure shows how the peer-to-peer interactions happen in the IzPack Git workflow:
As you can see, a distributed system like Git puts various types of people of the IzPack community on equal foot.
Anyone can get and maintain his/her very own copy of the IzPack source code with the whole history.
The blessed repository must only feature the development branch (master), the stable release branches and the release tags (an exception is made only for those recovered from the CVS to Subversion then Subversion to Git conversions).
IzPack developers willing to share work in progress and experiments should have a public repository to push their own branches to. GitHub and Gitorious are excellent public repository hosting platforms.
Do not directly work on master or stable version branches that match those of the blessed reposotory.
Tip: do not hesitate to have a staging / integration branch between your master and feature branches, as this can sometimes be helpful in complex merge situations.
What you can do... or not