6 git-rebase - Forward-port local commits to the updated upstream head
10 'git-rebase' [-v] [--merge] [--onto <newbase>] <upstream> [<branch>]
12 'git-rebase' --continue | --skip | --abort
16 git-rebase replaces <branch> with a new branch of the same name. When
17 the --onto option is provided the new branch starts out with a HEAD equal
18 to <newbase>, otherwise it is equal to <upstream>. It then attempts to
19 create a new commit for each commit from the original <branch> that does
20 not exist in the <upstream> branch.
22 It is possible that a merge failure will prevent this process from being
23 completely automatic. You will have to resolve any such merge failure
24 and run `git rebase --continue`. Another option is to bypass the commit
25 that caused the merge failure with `git rebase --skip`. To restore the
26 original <branch> and remove the .dotest working files, use the command
27 `git rebase --abort` instead.
29 Note that if <branch> is not specified on the command line, the currently
30 checked out branch is used.
32 Assume the following history exists and the current branch is "topic":
40 From this point, the result of either of the following commands:
44 git-rebase master topic
54 The latter form is just a short-hand of `git checkout topic`
55 followed by `git rebase master`.
57 Here is how you would transplant a topic branch based on one
58 branch to another, to pretend that you forked the topic branch
59 from the latter branch, using `rebase --onto`.
61 First let's assume your 'topic' is based on branch 'next'.
62 For example feature developed in 'topic' depends on some
63 functionality which is found in 'next'.
66 o---o---o---o---o master
68 o---o---o---o---o next
73 We would want to make 'topic' forked from branch 'master',
74 for example because the functionality 'topic' branch depend on
75 got merged into more stable 'master' branch, like this:
78 o---o---o---o---o master
82 o---o---o---o---o next
85 We can get this using the following command:
87 git-rebase --onto master next topic
90 Another example of --onto option is to rebase part of a
91 branch. If we have the following situation:
103 git-rebase --onto master topicA topicB
115 This is useful when topicB does not depend on topicA.
117 A range of commits could also be removed with rebase. If we have
118 the following situation:
121 E---F---G---H---I---J topicA
126 git-rebase --onto topicA~5 topicA~2 topicA
128 would result in the removal of commits F and G:
131 E---H'---I'---J' topicA
134 This is useful if F and G were flawed in some way, or should not be
135 part of topicA. Note that the argument to --onto and the <upstream>
136 parameter can be any valid commit-ish.
138 In case of conflict, git-rebase will stop at the first problematic commit
139 and leave conflict markers in the tree. You can use git diff to locate
140 the markers (<<<<<<) and make edits to resolve the conflict. For each
141 file you edit, you need to tell git that the conflict has been resolved,
142 typically this would be done with
145 git update-index <filename>
148 After resolving the conflict manually and updating the index with the
149 desired resolution, you can continue the rebasing process with
152 git rebase --continue
155 Alternatively, you can undo the git-rebase with
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.
169 Upstream branch to compare against. May be any valid commit,
170 not just an existing branch name.
173 Working branch; defaults to HEAD.
176 Restart the rebasing process after having resolved a merge conflict.
179 Restore the original branch and abort the rebase operation.
182 Restart the rebasing process by skipping the current patch.
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
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.
197 Display a diffstat of what changed upstream since the last rebase.
199 include::merge-strategies.txt[]
203 When you rebase a branch, you are changing its history in a way that
204 will cause problems for anyone who already has a copy of the branch
205 in their repository and tries to pull updates from you. You should
206 understand the implications of using 'git rebase' on a repository that
209 When the git rebase command is run, it will first execute a "pre-rebase"
210 hook if one exists. You can use this hook to do sanity checks and
211 reject the rebase if it isn't appropriate. Please see the template
212 pre-rebase hook script for an example.
214 You must be in the top directory of your project to start (or continue)
215 a rebase. Upon completion, <branch> will be the current branch.
219 Written by Junio C Hamano <junkio@cox.net>
223 Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
227 Part of the gitlink:git[7] suite