git.oblomov.eu Git - git/blob - Documentation/git-update.txt

   1 git-update(1)
   2 =============
   3
   4 NAME
   5 ----
   6 git-update - update the current branch to the latest remote status
   7
   8 SYNOPSIS
   9 --------
  10 [verse]
  11 'git update' [options]
  12
  13 DESCRIPTION
  14 -----------
  15
  16 Incorporates changes from a remote repository into the current
  17 branch.
  18
  19 `git update` runs `git fetch` and then tries to update the current branch to
  20 the latest status. If you don't have any extra changes, the update operation is
  21 straight-forward, but if you do have them, extra actions are necessary.
  22
  23 Assume the following history exists and the current branch is "master":
  24
  25 ------------
  26          A---B---C origin/master
  27         /
  28     D---E master
  29 ------------
  30
  31 Then `git update` will merge in a fast-foward way up to the new master.
  32
  33 ------------
  34     D---E---A---B---C master, origin/master
  35 ------------
  36
  37 owever, a non-fast-foward case looks very different.
  38
  39 ------------
  40          A---B---C origin/master
  41         /
  42     D---E---F---G master
  43 ------------
  44
  45 This divergence means 'master' cannot be fast-forwarded to 'origin/master' and
  46 that is named a "non-fast-forward". By default `git update` will warn about
  47 these situations, however, most likely you would want a merge, which you can
  48 force with `git update --merge`. This will result in a new commit that combines
  49 the tips of both branches ('C' and 'G'). See linkgit:git-merge[1] for more details.
  50
  51 ------------
  52            origin/master
  53                  |
  54          A---B---C---H master
  55         /           /
  56     D---E---F------G
  57 ------------
  58
  59 You can choose to do a rebase instead by specifying the '--rebase' option,
  60 which is slightly more complicated, but results in a cleaner history. In this
  61 mode the commits that are not present in the remote branch are replayed on top
  62 of it, which results in newer commits. See linkgit:git-rebase[1] for more
  63 details.
  64
  65 ------------
  66                       F---G master
  67                      /
  68     D---E---A---B---C origin/master
  69 ------------
  70
  71 You should make sure you don't have any uncommitted changes before running
  72 `git update`. It is generally best to get any local changes in working order
  73 before pulling or stash them away with linkgit:git-stash[1].
  74
  75 The remote branch
  76 -----------------
  77
  78 By default `git update` will try to use the 'origin' remote and a branch with
  79 the same name as the current branch. So if you are currently in the 'topic'
  80 branch, `git update` will try to incorporate the changes from 'origin/topic'.
  81
  82 If you have configured an upstream tracking branch (e.g. git branch
  83 --set-upstream-to), then that branch will be used instead of the default. To
  84 find out the upstream of your current branch, you can run
  85 `git name-rev @{upstream}`.
  86
  87 OPTIONS
  88 -------
  89
  90 -q::
  91 --quiet::
  92         Be quiet.
  93
  94 -v::
  95 --verbose::
  96         Be verbose.
  97
  98 --[no-]recurse-submodules[=yes|on-demand|no]::
  99         This option controls if new commits of all populated submodules should
 100         be fetched too (see linkgit:git-config[1] and linkgit:gitmodules[5]).
 101         That might be necessary to get the data needed for merging submodule
 102         commits. Notice that the result of a merge will not be checked out in
 103         the submodule, "git submodule update" has to be called afterwards to
 104         bring the work tree up to date with the merge result.
 105
 106 -r::
 107 --rebase[=false|true|preserve]::
 108         When true, rebase the current branch on top of the remote
 109         branch after fetching.
 110 +
 111 When preserve, also rebase the current branch on top of the upstream
 112 branch, but pass `--preserve-merges` along to `git rebase` so that
 113 locally created merge commits will not be flattened.
 114 +
 115 When false, merge the current branch into the upstream branch.
 116 +
 117 See `update.mode`, `branch.<name>.updatemode` and `branch.autosetuprebase` in
 118 linkgit:git-config[1] if you want to make `git update` always use
 119 `--rebase`.
 120 +
 121 [NOTE]
 122 This is a potentially _dangerous_ mode of operation.
 123 It rewrites history, which does not bode well when you
 124 published that history already.  Do *not* use this option
 125 unless you have read linkgit:git-rebase[1] carefully.
 126
 127 -m::
 128 --merge::
 129         Force a merge.
 130 +
 131 See `update.mode`, `branch.<name>.updatemode` in linkgit:git-config[1] if you want
 132 to make `git update` always use `--merge`.
 133
 134 Options related to merging
 135 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 136
 137 :git-pull: 1
 138 include::merge-options.txt[]
 139 include::merge-strategies.txt[]
 140
 141 BUGS
 142 ----
 143 Using --recurse-submodules can only fetch new commits in already checked
 144 out submodules right now. When e.g. upstream added a new submodule in the
 145 just fetched commits of the superproject the submodule itself can not be
 146 fetched, making it impossible to check out that submodule later without
 147 having to do a fetch again. This is expected to be fixed in a future Git
 148 version.
 149
 150 SEE ALSO
 151 --------
 152 linkgit:git-fetch[1], linkgit:git-merge[1], linkgit:git-rebase[1], linkgit:git-config[1]
 153
 154 GIT
 155 ---
 156 Part of the linkgit:git[1] suite