git-pull <root
GIT-PULL(1)                                 Git Manual                                GIT-PULL(1)

NAME
       git-pull - Fetch from and integrate with another repository or a local branch

SYNOPSIS
       git pull [options] [ [...]]

DESCRIPTION
       Incorporates changes from a remote repository into the current branch. In its default
       mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

       More precisely, git pull runs git fetch with the given parameters and calls git merge to
       merge the retrieved branch heads into the current branch. With --rebase, it runs git
       rebase instead of git merge.

        should be the name of a remote repository as passed to git-fetch(1).
        can name an arbitrary remote ref (for example, the name of a tag) or even a
       collection of refs with corresponding remote-tracking branches (e.g.,
       refs/heads/*:refs/remotes/origin/*), but usually it is the name of a branch in the remote
       repository.

       Default values for  and  are read from the "remote" and "merge"
       configuration for the current branch as set by git-branch(1) --track.

       Assume the following history exists and the current branch is "master":

                     A---B---C master on origin
                    /
               D---E---F---G master
                   ^
                   origin/master in your repository

       Then "git pull" will fetch and replay the changes from the remote master branch since it
       diverged from the local master (i.e., E) until its current commit (C) on top of master and
       record the result in a new commit along with the names of the two parent commits and a log
       message from the user describing the changes.

                     A---B---C origin/master
                    /         \
               D---E---F---G---H master

       See git-merge(1) for details, including how conflicts are presented and handled.

       In Git 1.7.0 or later, to cancel a conflicting merge, use git reset --merge. Warning: In
       older versions of Git, running git pull with uncommitted changes is discouraged: while
       possible, it leaves you in a state that may be hard to back out of in the case of a
       conflict.

       If any of the remote changes overlap with local uncommitted changes, the merge will be
       automatically cancelled and the work tree untouched. It is generally best to get any local
       changes in working order before pulling or stash them away with git-stash(1).

OPTIONS
       -q, --quiet
           This is passed to both underlying git-fetch to squelch reporting of during transfer,
           and underlying git-merge to squelch output during merging.

       -v, --verbose
           Pass --verbose to git-fetch and git-merge.

       --[no-]recurse-submodules[=yes|on-demand|no]
           This option controls if new commits of all populated submodules should be fetched too
           (see git-config(1) and gitmodules(5)). That might be necessary to get the data needed
           for merging submodule commits, a feature Git learned in 1.7.3. Notice that the result
           of a merge will not be checked out in the submodule, "git submodule update" has to be
           called afterwards to bring the work tree up to date with the merge result.

   Options related to merging
       --commit, --no-commit
           Perform the merge and commit the result. This option can be used to override
           --no-commit.

           With --no-commit perform the merge but pretend the merge failed and do not autocommit,
           to give the user a chance to inspect and further tweak the merge result before
           committing.

       --edit, -e, --no-edit
           Invoke an editor before committing successful mechanical merge to further edit the
           auto-generated merge message, so that the user can explain and justify the merge. The
           --no-edit option can be used to accept the auto-generated message (this is generally
           discouraged).

           Older scripts may depend on the historical behaviour of not allowing the user to edit
           the merge log message. They will see an editor opened when they run git merge. To make
           it easier to adjust such scripts to the updated behaviour, the environment variable
           GIT_MERGE_AUTOEDIT can be set to no at the beginning of them.

       --ff
           When the merge resolves as a fast-forward, only update the branch pointer, without
           creating a merge commit. This is the default behavior.

       --no-ff
           Create a merge commit even when the merge resolves as a fast-forward. This is the
           default behaviour when merging an annotated (and possibly signed) tag.

       --ff-only
           Refuse to merge and exit with a non-zero status unless the current HEAD is already
           up-to-date or the merge can be resolved as a fast-forward.

       --log[=], --no-log
           In addition to branch names, populate the log message with one-line descriptions from
           at most  actual commits that are being merged. See also git-fmt-merge-msg(1).

           With --no-log do not list one-line descriptions from the actual commits being merged.

       --stat, -n, --no-stat
           Show a diffstat at the end of the merge. The diffstat is also controlled by the
           configuration option merge.stat.

           With -n or --no-stat do not show a diffstat at the end of the merge.

       --squash, --no-squash
           Produce the working tree and index state as if a real merge happened (except for the
           merge information), but do not actually make a commit, move the HEAD, or record
           $GIT_DIR/MERGE_HEAD (to cause the next git commit command to create a merge commit).
           This allows you to create a single commit on top of the current branch whose effect is
           the same as merging another branch (or more in case of an octopus).

           With --no-squash perform the merge and commit the result. This option can be used to
           override --squash.

       -s , --strategy=
           Use the given merge strategy; can be supplied more than once to specify them in the
           order they should be tried. If there is no -s option, a built-in list of strategies is
           used instead (git merge-recursive when merging a single head, git merge-octopus
           otherwise).

       -X 

Go-to-top  




Designed by SanjuD(@ngineerbabu)

<>