This page describes the internal layout of our git repositories.
This branch is the common development branch. The majority of development will happen here. It is expected to remain in a generally usable state. All new development topics that are not intended to be backported to older versions should be started from this branch. There is no restriction to the scope of peer reviews on this branch — correctness, design, readability, and style comments are allowed.
Depending on the state of the master branch, it may be useful to start branches for stabilizing releases. These branches are intended to be short-lived and will be merged back to the master branch after the release is tagged, then deleted. Release candidate branches are always started from the master branch — they do not contain experimental changes. Peer reviews should be restricted to the scope of the release — this is not the place to make design changes or general cosmetic fixups, but commits should still be correct and readable.
The experimental branch is a place for long running changes that aren’t considered for immediate inclusion in the master branch. It is often desirable to try something without knowing if it will be a beneficial change. This branch provides a relaxed environment to make these sort of experiments without having to conform to the more stringent rules applied to the master branch. Peer reviews should focus on catching bugs and that the change being implemented is well understood (adequately commented). Changes made on this branch will never be merged (in the Git sense) to the master branch — they must be resubmitted (with new Change-Ids) for inclusion in the master branch, so they get the full scope of peer review applied to them. Anyone may start a new experimental branch.
