From 0f336f194e546c229b2ff7cbac92910a4bb749f6 Mon Sep 17 00:00:00 2001 From: Oleg Broytman Date: Tue, 15 Sep 2015 05:03:30 +0300 Subject: [PATCH] Add a chapter "Branching models" --- pep-git.txt | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/pep-git.txt b/pep-git.txt index 620427a..db703eb 100644 --- a/pep-git.txt +++ b/pep-git.txt @@ -628,6 +628,33 @@ Git has a builtin merge strategy for what Python core developers call $ git merge -s ours v1 # null-merge v1 into master +Branching models +================ + +Git doesn't assume any particular development model regarding +branching and merging. Some projects prefer to graduate patches from +the oldest branch to the newest, some prefer to cherry-pick commits +backwards, some use squashing (combining a number of commits into +one). Anything is possible. + +There are a few examples to start with. `git help workflows +`_ +describes how the very git authors develop git. + +ProGit book has a few chapters devoted to branch management in +different projects: `Git Branching - Branching Workflows +`_ and +`Distributed Git - Contributing to a Project +`_. + +There is also a well-known article `A successful Git branching model +`_ by Vincent +Driessen. It recommends a set of very detailed rules on creating and +managing mainline, topic and bugfix branches. To support the model the +author implemented `git flow `_ +extension. + + Advanced configuration ====================== -- 2.39.5