1git-pull(1) 2=========== 3 4NAME 5---- 6git-pull - Fetch from and merge with another repository or a local branch 7 8 9SYNOPSIS 10-------- 11'git-pull' <options> <repository> <refspec>... 12 13 14DESCRIPTION 15----------- 16Runs `git-fetch` with the given parameters, and calls `git-merge` 17to merge the retrieved head(s) into the current branch. 18 19Note that you can use `.` (current directory) as the 20<repository> to pull from the local repository -- this is useful 21when merging local branches into the current branch. 22 23 24OPTIONS 25------- 26include::merge-options.txt[] 27 28include::fetch-options.txt[] 29 30include::pull-fetch-param.txt[] 31 32include::urls.txt[] 33 34include::merge-strategies.txt[] 35 36DEFAULT BEHAVIOUR 37----------------- 38 39Often people use `git pull` without giving any parameter. 40Traditionally, this has been equivalent to saying `git pull 41origin`. However, when configuration `branch.<name>.remote` is 42present while on branch `<name>`, that value is used instead of 43`origin`. 44 45In order to determine what URL to use to fetch from, the value 46of the configuration `remote.<origin>.url` is consulted 47and if there is not any such variable, the value on `URL: ` line 48in `$GIT_DIR/remotes/<origin>` file is used. 49 50In order to determine what remote branches to fetch (and 51optionally store in the tracking branches) when the command is 52run without any refspec parameters on the command line, values 53of the configuration variable `remote.<origin>.fetch` are 54consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>` 55file is consulted and its `Pull: ` lines are used. 56In addition to the refspec formats described in the OPTIONS 57section, you can have a globbing refspec that looks like this: 58 59------------ 60refs/heads/*:refs/remotes/origin/* 61------------ 62 63A globbing refspec must have a non-empty RHS (i.e. must store 64what were fetched in tracking branches), and its LHS and RHS 65must end with `/*`. The above specifies that all remote 66branches are tracked using tracking branches in 67`refs/remotes/origin/` hierarchy under the same name. 68 69The rule to determine which remote branch to merge after 70fetching is a bit involved, in order not to break backward 71compatibility. 72 73If explicit refspecs were given on the command 74line of `git pull`, they are all merged. 75 76When no refspec was given on the command line, then `git pull` 77uses the refspec from the configuration or 78`$GIT_DIR/remotes/<origin>`. In such cases, the following 79rules apply: 80 81. If `branch.<name>.merge` configuration for the current 82 branch `<name>` exists, that is the name of the branch at the 83 remote site that is merged. 84 85. If the refspec is a globbing one, nothing is merged. 86 87. Otherwise the remote branch of the first refspec is merged. 88 89 90EXAMPLES 91-------- 92 93git pull, git pull origin:: 94 Update the remote-tracking branches for the repository 95 you cloned from, then merge one of them into your 96 current branch. Normally the branch merged in is 97 the HEAD of the remote repository, but the choice is 98 determined by the branch.<name>.remote and 99 branch.<name>.merge options; see gitlink:git-config[1] 100 for details. 101 102git pull origin next:: 103 Merge into the current branch the remote branch `next`; 104 leaves a copy of `next` temporarily in FETCH_HEAD, but 105 does not update any remote-tracking branches. 106 107git pull . fixes enhancements:: 108 Bundle local branch `fixes` and `enhancements` on top of 109 the current branch, making an Octopus merge. This `git pull .` 110 syntax is equivalent to `git merge`. 111 112git pull -s ours . obsolete:: 113 Merge local branch `obsolete` into the current branch, 114 using `ours` merge strategy. 115 116git pull --no-commit . maint:: 117 Merge local branch `maint` into the current branch, but 118 do not make a commit automatically. This can be used 119 when you want to include further changes to the merge, 120 or want to write your own merge commit message. 121+ 122You should refrain from abusing this option to sneak substantial 123changes into a merge commit. Small fixups like bumping 124release/version name would be acceptable. 125 126Command line pull of multiple branches from one repository:: 127+ 128------------------------------------------------ 129$ git checkout master 130$ git fetch origin +pu:pu maint:tmp 131$ git pull . tmp 132------------------------------------------------ 133+ 134This updates (or creates, as necessary) branches `pu` and `tmp` 135in the local repository by fetching from the branches 136(respectively) `pu` and `maint` from the remote repository. 137+ 138The `pu` branch will be updated even if it is does not 139fast-forward; the others will not be. 140+ 141The final command then merges the newly fetched `tmp` into master. 142 143 144If you tried a pull which resulted in a complex conflicts and 145would want to start over, you can recover with 146gitlink:git-reset[1]. 147 148 149SEE ALSO 150-------- 151gitlink:git-fetch[1], gitlink:git-merge[1], gitlink:git-config[1] 152 153 154Author 155------ 156Written by Linus Torvalds <torvalds@osdl.org> 157and Junio C Hamano <junkio@cox.net> 158 159Documentation 160-------------- 161Documentation by Jon Loeliger, 162David Greaves, 163Junio C Hamano and the git-list <git@vger.kernel.org>. 164 165GIT 166--- 167Part of the gitlink:git[7] suite 168