You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
163 lines
4.7 KiB
163 lines
4.7 KiB
git-pull(1) |
|
=========== |
|
|
|
NAME |
|
---- |
|
git-pull - Pull and merge from another repository. |
|
|
|
|
|
SYNOPSIS |
|
-------- |
|
'git-pull' <options> <repository> <refspec>... |
|
|
|
|
|
DESCRIPTION |
|
----------- |
|
Runs `git-fetch` with the given parameters, and calls `git-merge` |
|
to merge the retrieved head(s) into the current branch. |
|
|
|
Note that you can use `.` (current directory) as the |
|
<repository> to pull from the local repository -- this is useful |
|
when merging local branches into the current branch. |
|
|
|
OPTIONS |
|
------- |
|
include::pull-fetch-param.txt[] |
|
|
|
-a, \--append:: |
|
Append ref names and object names of fetched refs to the |
|
existing contents of `$GIT_DIR/FETCH_HEAD`. Without this |
|
option old data in `$GIT_DIR/FETCH_HEAD` will be overwritten. |
|
|
|
include::merge-pull-opts.txt[] |
|
|
|
|
|
MERGE STRATEGIES |
|
---------------- |
|
|
|
resolve:: |
|
This can only resolve two heads (i.e. the current branch |
|
and another branch you pulled from) using 3-way merge |
|
algorithm. It tries to carefully detect criss-cross |
|
merge ambiguities and is considered generally safe and |
|
fast. This is the default merge strategy when pulling |
|
one branch. |
|
|
|
recursive:: |
|
This can only resolve two heads using 3-way merge |
|
algorithm. When there are more than one common |
|
ancestors that can be used for 3-way merge, it creates a |
|
merged tree of the common ancestores and uses that as |
|
the reference tree for the 3-way merge. This has been |
|
reported to result in fewer merge conflicts without |
|
causing mis-merges by tests done on actual merge commits |
|
taken from Linux 2.6 kernel development history. |
|
Additionally this can detect and handle merges involving |
|
renames. |
|
|
|
octopus:: |
|
This resolves more than two-head case, but refuses to do |
|
complex merge that needs manual resolution. It is |
|
primarily meant to be used for bundling topic branch |
|
heads together. This is the default merge strategy when |
|
pulling more than one branch. |
|
|
|
ours:: |
|
This resolves any number of heads, but the result of the |
|
merge is always the current branch head. It is meant to |
|
be used to supersede old development history of side |
|
branches. |
|
|
|
|
|
EXAMPLES |
|
-------- |
|
|
|
git pull, git pull origin:: |
|
Fetch the default head from the repository you cloned |
|
from and merge it into your current branch. |
|
|
|
git pull -s ours . obsolete:: |
|
Merge local branch `obsolete` into the current branch, |
|
using `ours` merge strategy. |
|
|
|
git pull . fixes enhancements:: |
|
Bundle local branch `fixes` and `enhancements` on top of |
|
the current branch, making an Octopus merge. |
|
|
|
git pull --no-commit . maint:: |
|
Merge local branch `maint` into the current branch, but |
|
do not make a commit automatically. This can be used |
|
when you want to include further changes to the merge, |
|
or want to write your own merge commit message. |
|
+ |
|
You should refrain from abusing this option to sneak substantial |
|
changes into a merge commit. Small fixups like bumping |
|
release/version name would be acceptable. |
|
|
|
Command line pull of multiple branches from one repository:: |
|
+ |
|
------------------------------------------------ |
|
$ cat .git/remotes/origin |
|
URL: git://git.kernel.org/pub/scm/git/git.git |
|
Pull: master:origin |
|
|
|
$ git checkout master |
|
$ git fetch origin master:origin +pu:pu maint:maint |
|
$ git pull . origin |
|
------------------------------------------------ |
|
+ |
|
Here, a typical `$GIT_DIR/remotes/origin` file from a |
|
`git-clone` operation is used in combination with |
|
command line options to `git-fetch` to first update |
|
multiple branches of the local repository and then |
|
to merge the remote `origin` branch into the local |
|
`master` branch. The local `pu` branch is updated |
|
even if it does not result in a fast forward update. |
|
Here, the pull can obtain its objects from the local |
|
repository using `.`, as the previous `git-fetch` is |
|
known to have already obtained and made available |
|
all the necessary objects. |
|
|
|
|
|
Pull of multiple branches from one repository using `$GIT_DIR/remotes` file:: |
|
+ |
|
------------------------------------------------ |
|
$ cat .git/remotes/origin |
|
URL: git://git.kernel.org/pub/scm/git/git.git |
|
Pull: master:origin |
|
Pull: +pu:pu |
|
Pull: maint:maint |
|
|
|
$ git checkout master |
|
$ git pull origin |
|
------------------------------------------------ |
|
+ |
|
Here, a typical `$GIT_DIR/remotes/origin` file from a |
|
`git-clone` operation has been hand-modified to include |
|
the branch-mapping of additional remote and local |
|
heads directly. A single `git-pull` operation while |
|
in the `master` branch will fetch multiple heads and |
|
merge the remote `origin` head into the current, |
|
local `master` branch. |
|
|
|
|
|
SEE ALSO |
|
-------- |
|
gitlink:git-fetch[1], gitlink:git-merge[1] |
|
|
|
|
|
Author |
|
------ |
|
Written by Linus Torvalds <torvalds@osdl.org> |
|
and Junio C Hamano <junkio@cox.net> |
|
|
|
Documentation |
|
-------------- |
|
Documentation by Jon Loeliger, |
|
David Greaves, |
|
Junio C Hamano and the git-list <git@vger.kernel.org>. |
|
|
|
GIT |
|
--- |
|
Part of the gitlink:git[7] suite |
|
|
|
|