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