37 строки
1.6 KiB
ReStructuredText
37 строки
1.6 KiB
ReStructuredText
.. _branching:
|
|
|
|
===================
|
|
How We Do Branching
|
|
===================
|
|
|
|
We manage our branches in a similar manner to `nvie's branching model`_. The
|
|
main difference is that we develop all code on the `master`_ branch and use the
|
|
`next`_ branch as the place for staging releases.
|
|
|
|
New development happens on ``master``, and is visible on
|
|
https://preview.addons.mozilla.org. When we have a code freeze (every one or
|
|
two weeks), the ``next`` branch is synced with master and is visible on
|
|
https://next.addons.mozilla.org.
|
|
|
|
Tags should be created off of the ``next`` branch. If we need to release a
|
|
hotfix, it should be applied to the ``next`` branch and tagged from there.
|
|
|
|
|
|
Local Branches
|
|
--------------
|
|
|
|
Most new code is developed in local one-off branches, usually encompassing one
|
|
or two patches to fix a bug. Upstream doesn't care how you do local
|
|
development, but we don't want to see a merge commit every time you merge a
|
|
single patch from a branch. Merge commits make for a noisy history, which is
|
|
not fun to look at and can make it difficult to cherry-pick hotfixes to a
|
|
release branch. We do like to see merge commits when you're committing a set
|
|
of related patches from a feature branch. The rule of thumb is to rebase and
|
|
use fast-forward merge for single patches or a branch of unrelated bug fixes,
|
|
but to use a merge commit if you have multiple commits that form a cohesive unit.
|
|
|
|
|
|
.. _nvie's branching model: http://nvie.com/posts/a-successful-git-branching-model/
|
|
.. _master: http://github.com/jbalogh/zamboni/tree/master
|
|
.. _next: http://github.com/jbalogh/zamboni/tree/next
|