Version: $Revision$
Last-Modified: $Date$
Author: Oleg Broytman <phd@phdru.name>
-Status: Active
+Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 01-Jun-2015
Internet is full of heated discussions on the topic: "merge or
rebase?" Most of them are meaningless. When a DVCS is being used in a
big team with a big and complex project with many branches there is
-simply no way to avoid merges. So the question diminished to "whether
-to use rebase, and if yes - when to use rebase?" Considering that it
-is very much recommended not to rebase published commits the question
-diminished even further: "whether to use rebase on non-pushed
-commits?"
+simply no way to avoid merges. So the question's diminished to
+"whether to use rebase, and if yes - when to use rebase?" Considering
+that it is very much recommended not to rebase published commits the
+question's diminished even further: "whether to use rebase on
+non-pushed commits?"
That small question is for the team to decide. The author of the PEP
recommends to use rebase when pulling, i.e. always do ``git pull
$ git config branch.NAME.rebase true
-After that ``git pull origin v2`` will be equivalent to ``git pull
+For example::
+
+ $ git config branch.v2.rebase true
+
+After that ``git pull origin v2`` becomes equivalent to ``git pull
--rebase origin v2``.
In case when merge is preferred it is recommended to create new
When the topic branch is deleted only the label is removed, commits
are stayed in the database, they are now merged into v2::
- --o--o--o--o--o--o-M-<v2 - it is the mainline branch
- \ /
- --*--*--* - it is the topic branch, now unnamed
+ o--o--o--o--o--M--< v2 - it is the mainline branch
+ \ /
+ --*--*--* - it is the topic branch, now unnamed
The topic branch is deleted to avoid cluttering branch namespace with
small topic branches. Information on what issue was fixed or what