+Branches in the DOC Project
+---------------------------
+
+The DOC project 'master' branch aggregates the 'latest' content
+from all ONAP project repositories contributing documentation into a
+single tree file structure as described in the previous section. This
+branch is continuously integrated and deployed at Read The
+Docs as the 'latest' ONAP Documentation by:
+
+* Jenkins doc-verify-rtd and doc-merge-rtd jobs triggered whenever patches on
+ contributing repositories contain rst files at or below a top level
+ 'docs' folder.
+
+* Subscription in the DOC project to changes in submodule repositories.
+ These changes appear in the DOC project as commits with title
+ 'Updated git submodules' when a change to a contributing project
+ repository is merged. No DOC project code review occurs, only a
+ submodule repository commit hash is updated to track the head of each
+ contributing master branch.
+
+For each ONAP named release the DOC project creates a branch with the
+release name. The timing of the release branch is determined by
+work needed in the DOC project to prepare the release branch and the
+amount of change unrelated to the release in the master branch.
+For example contributing projects that create named release branches
+early to begin work on the next release and/or contributing projects
+to the master that are not yet part of the named release would result
+in an earlier named release branch to cleanly separate work to stabilize
+a release from other changes in the master branch.
+
+A named release branch is integrated and deployed at Read The Docs
+as the 'named release' by aggregating content from contributing
+project repositories. A contributing project repository can
+choose one of the following for the 'named release' branch:
+
+* Remove the contributing project repository submodule and RST
+ references when not part of the named release.
+
+* Provide a commit hash or tag for the contributing project master
+ branch to be used for the life of the release branch or until a
+ request is submitted to change the commit hash or tag.
+
+* Provide the commit hash for the head of a named release branch
+ created in the contributing project repository. This option
+ may be appropriate if frequent changes are expected over the
+ life of the named release and work the same way as the continuous
+ integration and deployment described for the master branch.
+
+The decision on option for each contributing project repository
+can be made or changed before the final release is approved. The
+amount of change and expected differences between master and a
+named release branch for each repository should drive the choice of
+option and timing.
+
+About GIT branches
+------------------
+
+GIT is a powerful tool allowing many actions, but without respecting some rules
+the GIT structure can be quickly hard to maintain.
+
+Here are some conventions about GIT branches:
+
+ - ALWAYS create a local branch to edit or create any file. This local branch
+ will be considered as a topic in Gerrit and allow contributors to
+ work at the same time on the same project.
+
+ - 1 feature = 1 branch. In the case of documentation, a new chapter
+ or page about a new code feature can be considered as a 'doc feature'
+
+ - 1 bug = 1 branch. In the case of documentation, a correction on an
+ existing sentence can be considered as a 'doc bug'
+
+ - the master branch is considered as "unstable", containing new features that
+ will converge to a stable situation for the release date.
+
+The day of the release, the repository owner will create a new branch to
+fix the code and documentation. This will represent the 'stable' code of the
+release. In this context:
+
+ - NEVER push a new feature on a stable branch
+
+ - Only bug correction are authorized on a stable branch using
+ cherry pick method
+
+.. image:: git_branches.png
+