+++ b/contrib/subtree/git-subtree.1
+.\" Author: [see the "AUTHOR" section]
+.\" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/>
+.TH "GIT\-SUBTREE" "1" "10/30/2017" "Git 2\&.17\&.0" "Git Manual"
+.\" -----------------------------------------------------------------
+.\" * Define some portability stuff
+.\" -----------------------------------------------------------------
+.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.\" http://bugs.debian.org/507673
+.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
+.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.\" -----------------------------------------------------------------
+.\" * set default formatting
+.\" -----------------------------------------------------------------
+.\" disable justification (adjust text to left margin only)
+.\" -----------------------------------------------------------------
+.\" * MAIN CONTENT STARTS HERE *
+.\" -----------------------------------------------------------------
+git-subtree \- Merge subtrees together and split repository into subtrees
+\fIgit subtree\fR add \-P <prefix> <commit>
+\fIgit subtree\fR add \-P <prefix> <repository> <ref>
+\fIgit subtree\fR pull \-P <prefix> <repository> <ref>
+\fIgit subtree\fR push \-P <prefix> <repository> <ref>
+\fIgit subtree\fR merge \-P <prefix> <commit>
+\fIgit subtree\fR split \-P <prefix> [OPTIONS] [<commit>]
+Subtrees allow subprojects to be included within a subdirectory of the main project, optionally including the subproject\(cqs entire history\&.
+For example, you could include the source code for a library as a subdirectory of your application\&.
+Subtrees are not to be confused with submodules, which are meant for the same task\&. Unlike submodules, subtrees do not need any special constructions (like \&.gitmodule files or gitlinks) be present in your repository, and do not force end\-users of your repository to do anything special or to understand how subtrees work\&. A subtree is just a subdirectory that can be committed to, branched, and merged along with your project in any way you want\&.
+They are also not to be confused with using the subtree merge strategy\&. The main difference is that, besides merging the other project as a subdirectory, you can also extract the entire history of a subdirectory from your project and make it into a standalone project\&. Unlike the subtree merge strategy you can alternate back and forth between these two operations\&. If the standalone library gets updated, you can automatically merge the changes into your project; if you update the library inside your project, you can "split" the changes back out again and merge them back into the library project\&.
+For example, if a library you made for one application ends up being useful elsewhere, you can extract its entire history and publish that as its own git repository, without accidentally intermingling the history of your application project\&.
+In order to keep your commit messages clean, we recommend that people split their commits between the subtrees and the main project as much as possible\&. That is, if you make a change that affects both the library and the main application, commit it in two pieces\&. That way, when you split the library commits out later, their descriptions will still make sense\&. But if this isn\(cqt important to you, it\(cqs not \fBnecessary\fR\&. git subtree will simply leave out the non\-library\-related parts of the commit when it splits it out into the subproject later\&.
+Create the <prefix> subtree by importing its contents from the given <commit> or <repository> and remote <ref>\&. A new commit is created automatically, joining the imported project\(cqs history with your own\&. With
+\fI\-\-squash\fR, imports only a single commit from the subproject, rather than its entire history\&.
+Merge recent changes up to <commit> into the <prefix> subtree\&. As with normal
+\fIgit merge\fR, this doesn\(cqt remove your own local changes; it just merges those changes into the latest <commit>\&. With
+\fI\-\-squash\fR, creates only one commit that contains all the changes, rather than merging in the entire history\&.
+\fI\-\-squash\fR, the merge direction doesn\(cqt always have to be forward; you can use this command to go back in time from v2\&.5 to v2\&.4, for example\&. If your merge introduces a conflict, you can resolve it in the usual ways\&.