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. 18With `--rebase`, calls 'git rebase' instead of 'git merge'. 19 20Note that you can use `.` (current directory) as the 21<repository> to pull from the local repository -- this is useful 22when merging local branches into the current branch. 23 24Also note that options meant for 'git pull' itself and underlying 25'git merge' must be given before the options meant for 'git fetch'. 26 27*Warning*: Running 'git pull' (actually, the underlying 'git merge') 28with uncommitted changes is discouraged: while possible, it leaves you 29in a state that is hard to back out of in the case of a conflict. 30 31OPTIONS 32------- 33 34-q:: 35--quiet:: 36 This is passed to both underlying git-fetch to squelch reporting of 37 during transfer, and underlying git-merge to squelch output during 38 merging. 39 40-v:: 41--verbose:: 42 Pass --verbose to git-fetch and git-merge. 43 44Options related to merging 45~~~~~~~~~~~~~~~~~~~~~~~~~~ 46 47include::merge-options.txt[] 48 49:git-pull: 1 50 51--rebase:: 52 Instead of a merge, perform a rebase after fetching. If 53 there is a remote ref for the upstream branch, and this branch 54 was rebased since last fetched, the rebase uses that information 55 to avoid rebasing non-local changes. To make this the default 56 for branch `<name>`, set configuration `branch.<name>.rebase` 57 to `true`. 58+ 59[NOTE] 60This is a potentially _dangerous_ mode of operation. 61It rewrites history, which does not bode well when you 62published that history already. Do *not* use this option 63unless you have read linkgit:git-rebase[1] carefully. 64 65--no-rebase:: 66 Override earlier --rebase. 67 68Options related to fetching 69~~~~~~~~~~~~~~~~~~~~~~~~~~~ 70 71include::fetch-options.txt[] 72 73include::pull-fetch-param.txt[] 74 75include::urls-remotes.txt[] 76 77include::merge-strategies.txt[] 78 79DEFAULT BEHAVIOUR 80----------------- 81 82Often people use `git pull` without giving any parameter. 83Traditionally, this has been equivalent to saying `git pull 84origin`. However, when configuration `branch.<name>.remote` is 85present while on branch `<name>`, that value is used instead of 86`origin`. 87 88In order to determine what URL to use to fetch from, the value 89of the configuration `remote.<origin>.url` is consulted 90and if there is not any such variable, the value on `URL: ` line 91in `$GIT_DIR/remotes/<origin>` file is used. 92 93In order to determine what remote branches to fetch (and 94optionally store in the tracking branches) when the command is 95run without any refspec parameters on the command line, values 96of the configuration variable `remote.<origin>.fetch` are 97consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>` 98file is consulted and its `Pull: ` lines are used. 99In addition to the refspec formats described in the OPTIONS 100section, you can have a globbing refspec that looks like this: 101 102------------ 103refs/heads/*:refs/remotes/origin/* 104------------ 105 106A globbing refspec must have a non-empty RHS (i.e. must store 107what were fetched in tracking branches), and its LHS and RHS 108must end with `/*`. The above specifies that all remote 109branches are tracked using tracking branches in 110`refs/remotes/origin/` hierarchy under the same name. 111 112The rule to determine which remote branch to merge after 113fetching is a bit involved, in order not to break backward 114compatibility. 115 116If explicit refspecs were given on the command 117line of `git pull`, they are all merged. 118 119When no refspec was given on the command line, then `git pull` 120uses the refspec from the configuration or 121`$GIT_DIR/remotes/<origin>`. In such cases, the following 122rules apply: 123 124. If `branch.<name>.merge` configuration for the current 125 branch `<name>` exists, that is the name of the branch at the 126 remote site that is merged. 127 128. If the refspec is a globbing one, nothing is merged. 129 130. Otherwise the remote branch of the first refspec is merged. 131 132 133EXAMPLES 134-------- 135 136* Update the remote-tracking branches for the repository 137 you cloned from, then merge one of them into your 138 current branch: 139+ 140------------------------------------------------ 141$ git pull, git pull origin 142------------------------------------------------ 143+ 144Normally the branch merged in is the HEAD of the remote repository, 145but the choice is determined by the branch.<name>.remote and 146branch.<name>.merge options; see linkgit:git-config[1] for details. 147 148* Merge into the current branch the remote branch `next`: 149+ 150------------------------------------------------ 151$ git pull origin next 152------------------------------------------------ 153+ 154This leaves a copy of `next` temporarily in FETCH_HEAD, but 155does not update any remote-tracking branches. Using remote-tracking 156branches, the same can be done by invoking fetch and merge: 157+ 158------------------------------------------------ 159$ git fetch origin 160$ git merge origin/next 161------------------------------------------------ 162 163 164If you tried a pull which resulted in a complex conflicts and 165would want to start over, you can recover with 'git reset'. 166 167 168SEE ALSO 169-------- 170linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-config[1] 171 172 173Author 174------ 175Written by Linus Torvalds <torvalds@osdl.org> 176and Junio C Hamano <gitster@pobox.com> 177 178Documentation 179-------------- 180Documentation by Jon Loeliger, 181David Greaves, 182Junio C Hamano and the git-list <git@vger.kernel.org>. 183 184GIT 185--- 186Part of the linkgit:git[1] suite