0 Members and 1 Guest are viewing this topic.
https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txtgit-subtree(1)==============NAME----git-subtree - Merge subtrees together and split repository into subtreesSYNOPSIS--------[verse]'git subtree' add -P <prefix> <commit>'git subtree' add -P <prefix> <repository> <ref>'git subtree' pull -P <prefix> <repository> <ref>'git subtree' push -P <prefix> <repository> <ref>'git subtree' merge -P <prefix> <commit>'git subtree' split -P <prefix> [OPTIONS] [<commit>]DESCRIPTION-----------Subtrees allow subprojects to be included within a subdirectoryof the main project, optionally including the subproject'sentire history.For example, you could include the source code for a libraryas a subdirectory of your application.Subtrees are not to be confused with submodules, which are meant forthe same task. Unlike submodules, subtrees do not need any specialconstructions (like .gitmodule files or gitlinks) be present inyour repository, and do not force end-users of yourrepository to do anything special or to understand how subtreeswork. A subtree is just a subdirectory that can becommitted to, branched, and merged along with your project inany way you want.They are also not to be confused with using the subtree mergestrategy. The main difference is that, besides mergingthe other project as a subdirectory, you can also extract theentire history of a subdirectory from your project and make itinto a standalone project. Unlike the subtree merge strategyyou can alternate back and forth between thesetwo operations. If the standalone library gets updated, you canautomatically merge the changes into your project; if youupdate the library inside your project, you can "split" thechanges back out again and merge them back into the libraryproject.For example, if a library you made for one application ends up beinguseful elsewhere, you can extract its entire history and publishthat as its own git repository, without accidentallyintermingling the history of your application project.[TIP]In order to keep your commit messages clean, we recommend thatpeople split their commits between the subtrees and the mainproject as much as possible. That is, if you make a change thataffects both the library and the main application, commit it intwo pieces. That way, when you split the library commits outlater, their descriptions will still make sense. But if thisisn't important to you, it's not *necessary*. git subtree willsimply leave out the non-library-related parts of the commitwhen it splits it out into the subproject later.