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 23Also note that options meant for `git-pull` itself and underlying 24`git-merge` must be given before the options meant for `git-fetch`. 25 26OPTIONS 27------- 28include::merge-options.txt[] 29 30:git-pull: 1 31include::fetch-options.txt[] 32 33include::pull-fetch-param.txt[] 34 35include::urls-remotes.txt[] 36 37include::merge-strategies.txt[] 38 39\--rebase:: 40 Instead of a merge, perform a rebase after fetching. If 41 there is a remote ref for the upstream branch, and this branch 42 was rebased since last fetched, the rebase uses that information 43 to avoid rebasing non-local changes. 44+ 45*NOTE:* This is a potentially _dangerous_ mode of operation. 46It rewrites history, which does not bode well when you 47published that history already. Do *not* use this option 48unless you have read linkgit:git-rebase[1] carefully. 49 50\--no-rebase:: 51 Override earlier \--rebase. 52 53DEFAULT BEHAVIOUR 54----------------- 55 56Often people use `git pull` without giving any parameter. 57Traditionally, this has been equivalent to saying `git pull 58origin`. However, when configuration `branch.<name>.remote` is 59present while on branch `<name>`, that value is used instead of 60`origin`. 61 62In order to determine what URL to use to fetch from, the value 63of the configuration `remote.<origin>.url` is consulted 64and if there is not any such variable, the value on `URL: ` line 65in `$GIT_DIR/remotes/<origin>` file is used. 66 67In order to determine what remote branches to fetch (and 68optionally store in the tracking branches) when the command is 69run without any refspec parameters on the command line, values 70of the configuration variable `remote.<origin>.fetch` are 71consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>` 72file is consulted and its `Pull: ` lines are used. 73In addition to the refspec formats described in the OPTIONS 74section, you can have a globbing refspec that looks like this: 75 76------------ 77refs/heads/*:refs/remotes/origin/* 78------------ 79 80A globbing refspec must have a non-empty RHS (i.e. must store 81what were fetched in tracking branches), and its LHS and RHS 82must end with `/*`. The above specifies that all remote 83branches are tracked using tracking branches in 84`refs/remotes/origin/` hierarchy under the same name. 85 86The rule to determine which remote branch to merge after 87fetching is a bit involved, in order not to break backward 88compatibility. 89 90If explicit refspecs were given on the command 91line of `git pull`, they are all merged. 92 93When no refspec was given on the command line, then `git pull` 94uses the refspec from the configuration or 95`$GIT_DIR/remotes/<origin>`. In such cases, the following 96rules apply: 97 98. If `branch.<name>.merge` configuration for the current 99 branch `<name>` exists, that is the name of the branch at the 100 remote site that is merged. 101 102. If the refspec is a globbing one, nothing is merged. 103 104. Otherwise the remote branch of the first refspec is merged. 105 106 107EXAMPLES 108-------- 109 110git pull, git pull origin:: 111 Update the remote-tracking branches for the repository 112 you cloned from, then merge one of them into your 113 current branch. Normally the branch merged in is 114 the HEAD of the remote repository, but the choice is 115 determined by the branch.<name>.remote and 116 branch.<name>.merge options; see linkgit:git-config[1] 117 for details. 118 119git pull origin next:: 120 Merge into the current branch the remote branch `next`; 121 leaves a copy of `next` temporarily in FETCH_HEAD, but 122 does not update any remote-tracking branches. 123 124git pull . fixes enhancements:: 125 Bundle local branch `fixes` and `enhancements` on top of 126 the current branch, making an Octopus merge. This `git pull .` 127 syntax is equivalent to `git merge`. 128 129git pull -s ours . obsolete:: 130 Merge local branch `obsolete` into the current branch, 131 using `ours` merge strategy. 132 133git pull --no-commit . maint:: 134 Merge local branch `maint` into the current branch, but 135 do not make a commit automatically. This can be used 136 when you want to include further changes to the merge, 137 or want to write your own merge commit message. 138+ 139You should refrain from abusing this option to sneak substantial 140changes into a merge commit. Small fixups like bumping 141release/version name would be acceptable. 142 143Command line pull of multiple branches from one repository:: 144+ 145------------------------------------------------ 146$ git checkout master 147$ git fetch origin +pu:pu maint:tmp 148$ git pull . tmp 149------------------------------------------------ 150+ 151This updates (or creates, as necessary) branches `pu` and `tmp` 152in the local repository by fetching from the branches 153(respectively) `pu` and `maint` from the remote repository. 154+ 155The `pu` branch will be updated even if it is does not 156fast-forward; the others will not be. 157+ 158The final command then merges the newly fetched `tmp` into master. 159 160 161If you tried a pull which resulted in a complex conflicts and 162would want to start over, you can recover with 163linkgit:git-reset[1]. 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 <junkio@cox.net> 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[7] suite