From: Raman Gupta <raman@rocketraman.com>
The current man page does a reasonable job at describing branch management
during the development process, but it does not contain any guidance as to
how the branches are affected by releases.
Add a basic introduction to the branch management undertaken during a
git.git release, so that a reader may gain some insight into how the
integration, maintenance, and topic branches are affected during the
release transition, and is thus able to better design the process for their
own project.
Other release activities such as reviews, testing, and creating
distributions are currently out of scope.
---
Documentation/gitworkflows.txt | 108 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 108 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 2b021e3..7000930 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -209,6 +209,114 @@ chance to see if their in-progress work will be compatible. `git.git`
has such an official throw-away integration branch called 'pu'.
+Branch management for a release
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Assuming you are using the merge approach discussed above, when you
+are releasing your project you will need to do some additional branch
+management work.
+
+Creating a release is easy. Since 'master' is tracking the commits
+that should go into the next feature release, simply tag the tip of
+'master' with a tag indicating the release version.
+
+.Release tagging
+[caption="Recipe: "]
+=====================================
+`git tag -s -m "GIT X.Y.Z" vX.Y.Z master`
+=====================================
+
+Similarly, for a maintenance release, 'maint' is tracking the commits
+to be released. Therefore, simply replace 'master' above with
+'maint'.
+
+Generally, you should push the new tag to a public git server (see
+"DISTRIBUTED WORKFLOWS" below). This push makes the tag available to
+others ...
