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