BranchPolicy
On LensKit and Grapht, we use a branching policy based on git-flow. We use the master branch in place of git-flow's develop branch, and stable takes the place of master. So master is always the current trunk of development, with all completed features merged in.
We have five types of branches:
master
: The main line of new development.
stable
: The current release.
feature/user-issue-name
: A feature-in-progress, to be merged into default.
release/version
: Branch for preparing a new release. These branches only exist for major-minor releases, not bugfix releases (e.g. there is release/2.1, but not release/2.1.1). Bug fixes for 2.1.1 will treat release/2.1 as their master/develop branch.
hotfix/release-dscr
: A hotfix-in-progress, to be released.
New features, and bugfixes for the main line of development, are developed in feature branches. These branches are initiated from the default branch, and are named feature/<user>-<issue>-description. The description should be very short, with words separated by hyphens. The issue is the ticket number associated with the feature or change, if there is one; if there is no ticket, just name it feature/user-description. The user is just a user identifier, typically your GitHub username. It should be short and alphanumeric.
While you are developing the feature, you can push it to either the master repository or your personal fork. Michael Ekstrand likes pushing to personal forks until the feature is ready for review.
Once the feature is ready for review, push its branch to the master repository, if you have access, and submit a pull request to merge the feature branch into the default branch. If you do not have write access to the master LensKit repository, push the change to your own fork on GitHub and submit a pull request for merging into the LensKit default branch. In either case, Travis will proceed to try to build the code and report back to the pull request on its success.
If there is a bug we need to fix in the released version of LensKit, this will happen in a branch called hotfix/<version>-description. Branch it off of the release/VER branch for the release it's patching and start making the fix(es). Release happens like it does for a real release from default, except it happens from the hotfix branch and the hotfix branch is closed after release. Hotfixes also need to be cherry-picked into the master branch (with git cherry-pick).
Do not rebase any branches pushed to the grouplens/lenskit repository. If you need to rebase, do it only on local branches (or, with great care, in branches pushed to your personal LensKit fork).