\documentclass{article}
\usepackage{ulem}
\pagestyle{headings}
\begin{document}
This information is aged. Post git split, horde doesn't use a develop branch anymore. Features get developed in feature branches or most times forks and integrated into the master branch via pull requests. I have not checked for other outdated info.

\part{ Branch management}
We follow a branching model that is a very simplified version of http://nvie.com/posts/a-successful-git-branching-model/\footnote{http://nvie.com/posts/a-successful-git-branching-model/}. The main difference is that we do bug fixing and make releases from the \textsl{master} branch, and only use release branches for older, still maintained versions. It is suggested to read this post first, to get an larger view on the ideas behind our branching model.

\section{ Main branches}
There are two main branches, \textsl{master} and \textsl{develop}.

- \textsl{master} is the branch for adding bug fixes. This is the code that will become the next bug fix release.\newline
- \textsl{develop} is the branch for adding new features. This is the code that will become the next major or minor release.

\textsl{develop} has been branched off from \textsl{master} at one point, and from time to time, bug fixes that have been applied to \textsl{master} are merged back into \textsl{develop}:

\begin{verbatim}

$ git checkout develop
$ git merge master
$ git push
\end{verbatim}

It is suggested to do that merging and pushing in a single, separate action, so that "real" work on the \textsl{develop} branch isn't get lost in the large commit messages of the merging.

\section{ Topic branches}
Even though \textsl{develop} is the branch for new development and adding features, larger features should be developed in a topic branch that is branched off \textsl{develop}:

\begin{verbatim}

$ git checkout develop
$ git checkout -b newfeature
\end{verbatim}

This is to avoid breaking code in \textsl{develop}. This is important, because \textsl{develop} is used for the next minor release, which will be created at a set date. To avoid having to revert commits if \textsl{develop} is unstable when the next release is near, such development must be done in topic branches, that can be merged back to develop, once they stabilized:

\begin{verbatim}

$ git checkout develop
$ git merge newfeature
$ git branch -d newfeature
\end{verbatim}

These topic branches can be private, or public if other should participate in development or testing. For creating public branches, see http://www.horde.org/development/git\#creating-managing-remote-branches\footnote{http://www.horde.org/development/git\#creating-managing-remote-branches}.

Topic branches are especially important when developing code that breaks backward compatibility, if it has \textbf{not} been decided yet whether the next release will be a major or minor release.

\section{ Release branches}
Release branches are maintenance branches for older releases. Once the release process for a new minor/major version is starting, the current version's code is branched off \textsl{master} into a release branch, before the current \textsl{develop} branch is merged back into \textsl{master} for the new version:

\begin{verbatim}

$ git checkout master
$ git branch FRAMEWORK_4_0
$ git merge develop
\end{verbatim}

Since we always maintain the two most recent minor versions\footnote{http://example.com/index.php?page=Doc/Dev/ReleaseCycle} with security fixes, there will always be 3 active branches (topic branches aside) at the same time. \textsl{master}, \textsl{develop}, and the release branch for the last minor version.

If for example we already had 4.0, 5.0 and 5.1 releases and are now working on the 6.0 release, we would maintain \textsl{develop}, \textsl{master} and \textsl{FRAMEWORK\_5\_1} branches.

\section{ Tools}
[gitflow https://github.com/nvie/gitflow\footnote{https://github.com/nvie/gitflow}] is a tool for managing the branching model of Vincent (nvie). If necessary, we might be able to fork and adapt it to our simpler needs.

\end{document}
