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