Git Pull Default Behavior and Examples

include::merge-strategies.adoc[] DEFAULT BEHAVIOUR ----------------- Often people use `git pull` without giving any parameter. Traditionally, this has been equivalent to saying `git pull origin`. However, when configuration `branch.<name>.remote` is present while on branch `<name>`, that value is used instead of `origin`. In order to determine what URL to use to fetch from, the value of the configuration `remote.<origin>.url` is consulted and if there is not any such variable, the value on the `URL:` line in `$GIT_DIR/remotes/<origin>` is used. In order to determine what remote branches to fetch (and optionally store in the remote-tracking branches) when the command is run without any refspec parameters on the command line, values of the configuration variable `remote.<origin>.fetch` are consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>` is consulted and its `Pull:` lines are used. In addition to the refspec formats described in the OPTIONS section, you can have a globbing refspec that looks like this: ------------ refs/heads/*:refs/remotes/origin/* ------------ A globbing refspec must have a non-empty RHS (i.e. must store what were fetched in remote-tracking branches), and its LHS and RHS must end with `/*`. The above specifies that all remote branches are tracked using remote-tracking branches in `refs/remotes/origin/` hierarchy under the same name. The rule to determine which remote branch to merge after fetching is a bit involved, in order not to break backward compatibility. If explicit refspecs were given on the command line of `git pull`, they are all merged. When no refspec was given on the command line, then `git pull` uses the refspec from the configuration or `$GIT_DIR/remotes/<origin>`. In such cases, the following rules apply: . If `branch.<name>.merge` configuration for the current branch `<name>` exists, that is the name of the branch at the remote site that is merged. . If the refspec is a globbing one, nothing is merged. . Otherwise the remote branch of the first refspec is merged. EXAMPLES -------- * Update the remote-tracking branches for the repository you cloned from, then merge one of them into your current branch: + ------------------------------------------------ $ git pull $ git pull origin ------------------------------------------------ + Normally the branch merged in is the HEAD of the remote repository, but the choice is determined by the branch.<name>.remote and branch.<name>.merge options; see linkgit:git-config[1] for details. * Merge into the current branch the remote branch `next`: + ------------------------------------------------ $ git pull origin next ------------------------------------------------ + This leaves a copy of `next` temporarily in FETCH_HEAD, and updates the remote-tracking branch `origin/next`. The same can be done by invoking fetch and merge: + ------------------------------------------------ $ git fetch origin $ git merge origin/next ------------------------------------------------ If you tried a pull which resulted in complex conflicts and would want to start over, you can recover with 'git reset'. include::transfer-data-leaks.adoc[] BUGS ---- Using --recurse-submodules can only fetch new commits in already checked out submodules right now. When e.g. upstream added a new submodule in the just fetched commits of the superproject the submodule itself cannot be fetched, making it impossible to check out that submodule later without having to do a fetch again. This is expected to be fixed in a future Git version. SEE ALSO -------- linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-config[1] GIT --- Part of the linkgit:git[1] suite

The git-pull command has default behavior for determining the remote repository and branches to fetch when no parameters are specified, and it can also be used with explicit refspecs or configuration options to customize the merging process, with examples provided for common use cases.