X-Git-Url: https://git.phdru.name/?a=blobdiff_plain;f=pep-git.txt;h=db703eb15e3f69c2e1ee31bfc9b72b000b5c95ed;hb=0f336f194e546c229b2ff7cbac92910a4bb749f6;hp=968aa329d2f85ba9232ec2e37b3054a6f9af37c6;hpb=789c33f68705f65d4c8b480211e972df8dc82e89;p=git-wiki.git

diff --git a/pep-git.txt b/pep-git.txt
index 968aa32..db703eb 100644
--- a/pep-git.txt
+++ b/pep-git.txt
@@ -7,7 +7,7 @@ Status: Draft
 Type: Informational
 Content-Type: text/x-rst
 Created: 01-Jun-2015
-Post-History: 
+Post-History: 12-Sep-2015
 
 Abstract
 ========
@@ -43,7 +43,7 @@ Git Tutorial: `part 1
 `Git User's manual
 <https://www.kernel.org/pub/software/scm/git/docs/user-manual.html>`_.
 `Everyday GIT With 20 Commands Or So
-<https://www.kernel.org/pub/software/scm/git/docs/everyday.html>`_.
+<https://www.kernel.org/pub/software/scm/git/docs/giteveryday.html>`_.
 `Git workflows
 <https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html>`_.
 
@@ -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
+<https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html>`_
+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
+<https://git-scm.com/book/en/Git-Branching-Branching-Workflows>`_ and
+`Distributed Git - Contributing to a Project
+<https://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project>`_.
+
+There is also a well-known article `A successful Git branching model
+<http://nvie.com/posts/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 <https://github.com/nvie/gitflow>`_
+extension.
+
+
 Advanced configuration
 ======================
 
@@ -842,27 +869,27 @@ repositories can be made user- or group-writeable (see parameter
 ``core.sharedRepository`` in ``git help config``). If that's too
 permissive or too restrictive for some project's needs there is a
 wrapper `gitolite <http://gitolite.com/gitolite/index.html>`_ that can
-be configured to allow access with great granularity; gitolite has a
-lot of documentation.
+be configured to allow access with great granularity; gitolite is
+written in Perl and has a lot of documentation.
 
 Web interface to browse repositories can be created using `gitweb
-<https://git.kernel.org/cgit/git/git.git/tree/gitweb>`_ and `cgit
+<https://git.kernel.org/cgit/git/git.git/tree/gitweb>`_ or `cgit
 <http://git.zx2c4.com/cgit/about/>`_. Both are CGI scripts (written in
 Perl and C). In addition to web interface both provide read-only dumb
 http access for git (http(s):// URLs).
 
 There are also more advanced web-based development environments that
-include ability to manage users, groups and projects; private, group
-and public repositories; they often include issue trackers, wiki
-pages, pull requests and other tools for development and
-communication. Among these environments are `Kallithea
+include ability to manage users, groups and projects; private,
+group-accessible and public repositories; they often include issue
+trackers, wiki pages, pull requests and other tools for development
+and communication. Among these environments are `Kallithea
 <https://kallithea-scm.org/>`_ and `pagure <https://pagure.io/>`_,
 both are written in Python; pagure was written by Fedora developers
 and is being used to develop some Fedora projects. `Gogs
 <http://gogs.io/>`_ is written in Go; there is a fork `Gitea
 <http://gitea.io/>`_.
 
-And last but not least `Gitlab <https://about.gitlab.com/>`_. It's
+And last but not least, `Gitlab <https://about.gitlab.com/>`_. It's
 perhaps the most advanced web-based development environment for git.
 Written in Ruby, community edition is free and open source (MIT
 license).
@@ -872,16 +899,16 @@ From Mercurial to git
 =====================
 
 There are many tools to convert Mercurial repositories to git. The
-most famous are, perhaps, `hg-git <https://hg-git.github.io/>`_ and
+most famous are, probably, `hg-git <https://hg-git.github.io/>`_ and
 `fast-export <http://repo.or.cz/w/fast-export.git>`_ (many years ago
 it was known under the name ``hg2git``).
 
 But a better tool, perhaps the best, is `git-remote-hg
 <https://github.com/felipec/git-remote-hg>`_. It provides transparent
-bidirectional access (pull and push) to Mercurial repositories from
-git. The author wrote a `comparison of alternatives
+bidirectional (pull and push) access to Mercurial repositories from
+git. Its author wrote a `comparison of alternatives
 <https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives>`_
-that seems to be mostly unbiased.
+that seems to be mostly objective.
 
 To use git-remote-hg, install or clone it, add to your PATH (or copy
 script ``git-remote-hg`` to a directory that's already in PATH) and
@@ -901,6 +928,10 @@ At the second half of the page there is a table that lists
 corresponding Mercurial and git commands. Should work perfectly in
 both directions.
 
+Python Developer's Guide also has a chapter `Mercurial for git
+developers <https://docs.python.org/devguide/gitdevs.html>`_ that
+documents a few differences between git and hg.
+
 
 Copyright
 =========