Documentation / git-rebase.txton commit cmd-list: add git-remote (727d38d)
   1git-rebase(1)
   2=============
   3
   4NAME
   5----
   6git-rebase - Forward-port local commits to the updated upstream head
   7
   8SYNOPSIS
   9--------
  10'git-rebase' [-v] [--merge] [-C<n>] [--onto <newbase>] <upstream> [<branch>]
  11
  12'git-rebase' --continue | --skip | --abort
  13
  14DESCRIPTION
  15-----------
  16git-rebase replaces <branch> with a new branch of the same name.  When
  17the --onto option is provided the new branch starts out with a HEAD equal
  18to <newbase>, otherwise it is equal to <upstream>.  It then attempts to
  19create a new commit for each commit from the original <branch> that does
  20not exist in the <upstream> branch.
  21
  22It is possible that a merge failure will prevent this process from being
  23completely automatic.  You will have to resolve any such merge failure
  24and run `git rebase --continue`.  Another option is to bypass the commit
  25that caused the merge failure with `git rebase --skip`.  To restore the
  26original <branch> and remove the .dotest working files, use the command
  27`git rebase --abort` instead.
  28
  29Note that if <branch> is not specified on the command line, the currently
  30checked out branch is used.
  31
  32Assume the following history exists and the current branch is "topic":
  33
  34------------
  35          A---B---C topic
  36         /
  37    D---E---F---G master
  38------------
  39
  40From this point, the result of either of the following commands:
  41
  42
  43    git-rebase master
  44    git-rebase master topic
  45
  46would be:
  47
  48------------
  49                  A'--B'--C' topic
  50                 /
  51    D---E---F---G master
  52------------
  53
  54The latter form is just a short-hand of `git checkout topic`
  55followed by `git rebase master`.
  56
  57Here is how you would transplant a topic branch based on one
  58branch to another, to pretend that you forked the topic branch
  59from the latter branch, using `rebase --onto`.
  60
  61First let's assume your 'topic' is based on branch 'next'.
  62For example feature developed in 'topic' depends on some
  63functionality which is found in 'next'.
  64
  65------------
  66    o---o---o---o---o  master
  67         \
  68          o---o---o---o---o  next
  69                           \
  70                            o---o---o  topic
  71------------
  72
  73We would want to make 'topic' forked from branch 'master',
  74for example because the functionality 'topic' branch depend on
  75got merged into more stable 'master' branch, like this:
  76
  77------------
  78    o---o---o---o---o  master
  79        |            \
  80        |             o'--o'--o'  topic
  81         \
  82          o---o---o---o---o  next
  83------------
  84
  85We can get this using the following command:
  86
  87    git-rebase --onto master next topic
  88
  89
  90Another example of --onto option is to rebase part of a
  91branch.  If we have the following situation:
  92
  93------------
  94                            H---I---J topicB
  95                           /
  96                  E---F---G  topicA
  97                 /
  98    A---B---C---D  master
  99------------
 100
 101then the command
 102
 103    git-rebase --onto master topicA topicB
 104
 105would result in:
 106
 107------------
 108                 H'--I'--J'  topicB
 109                /
 110                | E---F---G  topicA
 111                |/
 112    A---B---C---D  master
 113------------
 114
 115This is useful when topicB does not depend on topicA.
 116
 117A range of commits could also be removed with rebase.  If we have
 118the following situation:
 119
 120------------
 121    E---F---G---H---I---J  topicA
 122------------
 123
 124then the command
 125
 126    git-rebase --onto topicA~5 topicA~2 topicA
 127
 128would result in the removal of commits F and G:
 129
 130------------
 131    E---H'---I'---J'  topicA
 132------------
 133
 134This is useful if F and G were flawed in some way, or should not be
 135part of topicA.  Note that the argument to --onto and the <upstream>
 136parameter can be any valid commit-ish.
 137
 138In case of conflict, git-rebase will stop at the first problematic commit
 139and leave conflict markers in the tree.  You can use git diff to locate
 140the markers (<<<<<<) and make edits to resolve the conflict.  For each
 141file you edit, you need to tell git that the conflict has been resolved,
 142typically this would be done with
 143
 144
 145    git update-index <filename>
 146
 147
 148After resolving the conflict manually and updating the index with the
 149desired resolution, you can continue the rebasing process with
 150
 151
 152    git rebase --continue
 153
 154
 155Alternatively, you can undo the git-rebase with
 156
 157
 158    git rebase --abort
 159
 160OPTIONS
 161-------
 162<newbase>::
 163        Starting point at which to create the new commits. If the
 164        --onto option is not specified, the starting point is
 165        <upstream>.  May be any valid commit, and not just an
 166        existing branch name.
 167
 168<upstream>::
 169        Upstream branch to compare against.  May be any valid commit,
 170        not just an existing branch name.
 171
 172<branch>::
 173        Working branch; defaults to HEAD.
 174
 175--continue::
 176        Restart the rebasing process after having resolved a merge conflict.
 177
 178--abort::
 179        Restore the original branch and abort the rebase operation.
 180
 181--skip::
 182        Restart the rebasing process by skipping the current patch.
 183
 184--merge::
 185        Use merging strategies to rebase.  When the recursive (default) merge
 186        strategy is used, this allows rebase to be aware of renames on the
 187        upstream side.
 188
 189-s <strategy>, \--strategy=<strategy>::
 190        Use the given merge strategy; can be supplied more than
 191        once to specify them in the order they should be tried.
 192        If there is no `-s` option, a built-in list of strategies
 193        is used instead (`git-merge-recursive` when merging a single
 194        head, `git-merge-octopus` otherwise).  This implies --merge.
 195
 196-v, \--verbose::
 197        Display a diffstat of what changed upstream since the last rebase.
 198
 199-C<n>::
 200        Ensure at least <n> lines of surrounding context match before
 201        and after each change.  When fewer lines of surrounding
 202        context exist they all must match.  By default no context is
 203        ever ignored.
 204
 205include::merge-strategies.txt[]
 206
 207NOTES
 208-----
 209When you rebase a branch, you are changing its history in a way that
 210will cause problems for anyone who already has a copy of the branch
 211in their repository and tries to pull updates from you.  You should
 212understand the implications of using 'git rebase' on a repository that
 213you share.
 214
 215When the git rebase command is run, it will first execute a "pre-rebase"
 216hook if one exists.  You can use this hook to do sanity checks and
 217reject the rebase if it isn't appropriate.  Please see the template
 218pre-rebase hook script for an example.
 219
 220You must be in the top directory of your project to start (or continue)
 221a rebase.  Upon completion, <branch> will be the current branch.
 222
 223Author
 224------
 225Written by Junio C Hamano <junkio@cox.net>
 226
 227Documentation
 228--------------
 229Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
 230
 231GIT
 232---
 233Part of the gitlink:git[7] suite
 234