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