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