There is a DM Branching Policy page on Confluence, but it says that it is ancient. Some policies around git branches are listed on the Using Git for LSST Development page, but they're not very specific.
A de facto policy was created by gitolite push restrictions that limited branch names and, to some extent, usage. These restrictions no longer apply on GitHub.
Some developers have felt a tension between maintaining their time-ordered development history and a cleaned-up, reviewable, one-commit-per-feature history within a single branch.
I propose the following to replace the appropriate sections of the above Confluence pages:
- master remains the main integration branch and must always be deployable. No development occurs directly on master in any lsst (DM team) or lsst-dm repository, with the exceptions of documentation and very small fixes.
- The next branch and release branches are created as necessary for integration.
- tickets/DM-NNNN branches are the "official" history of development. All reviews happen on these branches, and all merges to master, next, or a release branch happen from them. These branches should be rebased with cleaned-up (squashed/separated, correctly-commented) history.
- u/username/anything branches are available for developers to do whatever they want. They can start investigative work on a feature without filing a JIRA ticket. They can keep as-developed history separate from the official history. Merges from such branches should not occur, but a tickets/DM-NNNN branch can be created at the tip of such a branch in order to merge it.
- Pull requests from other repos including personal repos are the equivalent of ticket branches. They need to have a DM-NNNN JIRA issue identifier and follow all the policies of in-repo ticket branches.