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