]>
Commit | Line | Data |
---|---|---|
215a7ad1 JH |
1 | git-rebase(1) |
2 | ============= | |
7fc9d69f JH |
3 | |
4 | NAME | |
5 | ---- | |
c3f0baac | 6 | git-rebase - Forward-port local commits to the updated upstream head |
7fc9d69f JH |
7 | |
8 | SYNOPSIS | |
9 | -------- | |
e448ff87 | 10 | [verse] |
b1889c36 | 11 | 'git rebase' [-i | --interactive] [-v | --verbose] [-m | --merge] |
fd631d58 | 12 | [-s <strategy> | --strategy=<strategy>] [--no-verify] |
059f446d BF |
13 | [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges] |
14 | [--onto <newbase>] <upstream> [<branch>] | |
b1889c36 | 15 | 'git rebase' --continue | --skip | --abort |
031321c6 | 16 | |
7fc9d69f JH |
17 | DESCRIPTION |
18 | ----------- | |
ba020ef5 | 19 | If <branch> is specified, 'git-rebase' will perform an automatic |
5ca2db53 SP |
20 | `git checkout <branch>` before doing anything else. Otherwise |
21 | it remains on the current branch. | |
22 | ||
23 | All changes made by commits in the current branch but that are not | |
24 | in <upstream> are saved to a temporary area. This is the same set | |
25 | of commits that would be shown by `git log <upstream>..HEAD`. | |
26 | ||
27 | The current branch is reset to <upstream>, or <newbase> if the | |
28 | --onto option was supplied. This has the exact same effect as | |
9869099b BG |
29 | `git reset --hard <upstream>` (or <newbase>). ORIG_HEAD is set |
30 | to point at the tip of the branch before the reset. | |
5ca2db53 SP |
31 | |
32 | The commits that were previously saved into the temporary area are | |
ff905462 JK |
33 | then reapplied to the current branch, one by one, in order. Note that |
34 | any commits in HEAD which introduce the same textual changes as a commit | |
35 | in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream | |
36 | with a different commit message or timestamp will be skipped). | |
69a60af5 | 37 | |
031321c6 SE |
38 | It is possible that a merge failure will prevent this process from being |
39 | completely automatic. You will have to resolve any such merge failure | |
cc120056 SE |
40 | and run `git rebase --continue`. Another option is to bypass the commit |
41 | that caused the merge failure with `git rebase --skip`. To restore the | |
51ef1daa JS |
42 | original <branch> and remove the .git/rebase-apply working files, use the |
43 | command `git rebase --abort` instead. | |
031321c6 | 44 | |
69a60af5 CW |
45 | Assume the following history exists and the current branch is "topic": |
46 | ||
031321c6 | 47 | ------------ |
69a60af5 CW |
48 | A---B---C topic |
49 | / | |
50 | D---E---F---G master | |
031321c6 | 51 | ------------ |
69a60af5 | 52 | |
228382ae | 53 | From this point, the result of either of the following commands: |
69a60af5 | 54 | |
031321c6 | 55 | |
b1889c36 JN |
56 | git rebase master |
57 | git rebase master topic | |
69a60af5 CW |
58 | |
59 | would be: | |
60 | ||
031321c6 | 61 | ------------ |
69a60af5 CW |
62 | A'--B'--C' topic |
63 | / | |
64 | D---E---F---G master | |
031321c6 | 65 | ------------ |
69a60af5 | 66 | |
e52775f4 JN |
67 | The latter form is just a short-hand of `git checkout topic` |
68 | followed by `git rebase master`. | |
69a60af5 | 69 | |
ff905462 JK |
70 | If the upstream branch already contains a change you have made (e.g., |
71 | because you mailed a patch which was applied upstream), then that commit | |
b1889c36 | 72 | will be skipped. For example, running `git rebase master` on the |
ff905462 JK |
73 | following history (in which A' and A introduce the same set of changes, |
74 | but have different committer information): | |
75 | ||
76 | ------------ | |
77 | A---B---C topic | |
78 | / | |
79 | D---E---A'---F master | |
80 | ------------ | |
81 | ||
82 | will result in: | |
83 | ||
84 | ------------ | |
85 | B'---C' topic | |
86 | / | |
87 | D---E---A'---F master | |
88 | ------------ | |
89 | ||
e52775f4 JN |
90 | Here is how you would transplant a topic branch based on one |
91 | branch to another, to pretend that you forked the topic branch | |
92 | from the latter branch, using `rebase --onto`. | |
69a60af5 | 93 | |
e52775f4 | 94 | First let's assume your 'topic' is based on branch 'next'. |
e2b850b2 | 95 | For example, a feature developed in 'topic' depends on some |
e52775f4 | 96 | functionality which is found in 'next'. |
69a60af5 | 97 | |
031321c6 | 98 | ------------ |
e52775f4 JN |
99 | o---o---o---o---o master |
100 | \ | |
101 | o---o---o---o---o next | |
102 | \ | |
103 | o---o---o topic | |
104 | ------------ | |
105 | ||
e2b850b2 GD |
106 | We want to make 'topic' forked from branch 'master'; for example, |
107 | because the functionality on which 'topic' depends was merged into the | |
108 | more stable 'master' branch. We want our tree to look like this: | |
e52775f4 JN |
109 | |
110 | ------------ | |
111 | o---o---o---o---o master | |
112 | | \ | |
113 | | o'--o'--o' topic | |
114 | \ | |
115 | o---o---o---o---o next | |
031321c6 | 116 | ------------ |
7fc9d69f | 117 | |
e52775f4 JN |
118 | We can get this using the following command: |
119 | ||
b1889c36 | 120 | git rebase --onto master next topic |
e52775f4 JN |
121 | |
122 | ||
123 | Another example of --onto option is to rebase part of a | |
124 | branch. If we have the following situation: | |
125 | ||
126 | ------------ | |
127 | H---I---J topicB | |
128 | / | |
129 | E---F---G topicA | |
130 | / | |
131 | A---B---C---D master | |
132 | ------------ | |
133 | ||
134 | then the command | |
135 | ||
b1889c36 | 136 | git rebase --onto master topicA topicB |
e52775f4 JN |
137 | |
138 | would result in: | |
139 | ||
140 | ------------ | |
141 | H'--I'--J' topicB | |
142 | / | |
143 | | E---F---G topicA | |
144 | |/ | |
145 | A---B---C---D master | |
146 | ------------ | |
147 | ||
148 | This is useful when topicB does not depend on topicA. | |
149 | ||
ea81fcc5 SP |
150 | A range of commits could also be removed with rebase. If we have |
151 | the following situation: | |
152 | ||
153 | ------------ | |
154 | E---F---G---H---I---J topicA | |
155 | ------------ | |
156 | ||
157 | then the command | |
158 | ||
b1889c36 | 159 | git rebase --onto topicA~5 topicA~3 topicA |
ea81fcc5 SP |
160 | |
161 | would result in the removal of commits F and G: | |
162 | ||
163 | ------------ | |
164 | E---H'---I'---J' topicA | |
165 | ------------ | |
166 | ||
167 | This is useful if F and G were flawed in some way, or should not be | |
168 | part of topicA. Note that the argument to --onto and the <upstream> | |
169 | parameter can be any valid commit-ish. | |
170 | ||
ba020ef5 JN |
171 | In case of conflict, 'git-rebase' will stop at the first problematic commit |
172 | and leave conflict markers in the tree. You can use 'git-diff' to locate | |
031321c6 SE |
173 | the markers (<<<<<<) and make edits to resolve the conflict. For each |
174 | file you edit, you need to tell git that the conflict has been resolved, | |
175 | typically this would be done with | |
176 | ||
177 | ||
d7f078b8 | 178 | git add <filename> |
031321c6 SE |
179 | |
180 | ||
181 | After resolving the conflict manually and updating the index with the | |
182 | desired resolution, you can continue the rebasing process with | |
183 | ||
184 | ||
185 | git rebase --continue | |
8978d043 | 186 | |
8978d043 | 187 | |
ba020ef5 | 188 | Alternatively, you can undo the 'git-rebase' with |
8978d043 | 189 | |
031321c6 SE |
190 | |
191 | git rebase --abort | |
8978d043 | 192 | |
7fc9d69f JH |
193 | OPTIONS |
194 | ------- | |
69a60af5 CW |
195 | <newbase>:: |
196 | Starting point at which to create the new commits. If the | |
197 | --onto option is not specified, the starting point is | |
ea81fcc5 SP |
198 | <upstream>. May be any valid commit, and not just an |
199 | existing branch name. | |
69a60af5 | 200 | |
52a22d1e | 201 | <upstream>:: |
ea81fcc5 SP |
202 | Upstream branch to compare against. May be any valid commit, |
203 | not just an existing branch name. | |
7fc9d69f | 204 | |
228382ae | 205 | <branch>:: |
52a22d1e | 206 | Working branch; defaults to HEAD. |
7fc9d69f | 207 | |
031321c6 SE |
208 | --continue:: |
209 | Restart the rebasing process after having resolved a merge conflict. | |
210 | ||
211 | --abort:: | |
212 | Restore the original branch and abort the rebase operation. | |
213 | ||
58634dbf EW |
214 | --skip:: |
215 | Restart the rebasing process by skipping the current patch. | |
58634dbf | 216 | |
3240240f SB |
217 | -m:: |
218 | --merge:: | |
58634dbf EW |
219 | Use merging strategies to rebase. When the recursive (default) merge |
220 | strategy is used, this allows rebase to be aware of renames on the | |
221 | upstream side. | |
222 | ||
3240240f SB |
223 | -s <strategy>:: |
224 | --strategy=<strategy>:: | |
58634dbf EW |
225 | Use the given merge strategy; can be supplied more than |
226 | once to specify them in the order they should be tried. | |
227 | If there is no `-s` option, a built-in list of strategies | |
ba020ef5 JN |
228 | is used instead ('git-merge-recursive' when merging a single |
229 | head, 'git-merge-octopus' otherwise). This implies --merge. | |
58634dbf | 230 | |
3240240f SB |
231 | -v:: |
232 | --verbose:: | |
b758789c RS |
233 | Display a diffstat of what changed upstream since the last rebase. |
234 | ||
fd631d58 NS |
235 | --no-verify:: |
236 | This option bypasses the pre-rebase hook. See also linkgit:githooks[5]. | |
237 | ||
67dad687 MT |
238 | -C<n>:: |
239 | Ensure at least <n> lines of surrounding context match before | |
240 | and after each change. When fewer lines of surrounding | |
241 | context exist they all must match. By default no context is | |
242 | ever ignored. | |
243 | ||
059f446d | 244 | --whitespace=<nowarn|warn|error|error-all|strip>:: |
ba020ef5 | 245 | This flag is passed to the 'git-apply' program |
5162e697 | 246 | (see linkgit:git-apply[1]) that applies the patch. |
059f446d | 247 | |
3240240f SB |
248 | -i:: |
249 | --interactive:: | |
1b1dce4b | 250 | Make a list of the commits which are about to be rebased. Let the |
f0fd889d JS |
251 | user edit that list before rebasing. This mode can also be used to |
252 | split commits (see SPLITTING COMMITS below). | |
1b1dce4b | 253 | |
3240240f SB |
254 | -p:: |
255 | --preserve-merges:: | |
f8cca019 | 256 | Instead of ignoring merges, try to recreate them. |
f09c9b8c | 257 | |
58634dbf EW |
258 | include::merge-strategies.txt[] |
259 | ||
031321c6 SE |
260 | NOTES |
261 | ----- | |
90d1c08e TR |
262 | |
263 | You should understand the implications of using 'git-rebase' on a | |
264 | repository that you share. See also RECOVERING FROM UPSTREAM REBASE | |
265 | below. | |
031321c6 | 266 | |
467c0197 | 267 | When the git-rebase command is run, it will first execute a "pre-rebase" |
031321c6 SE |
268 | hook if one exists. You can use this hook to do sanity checks and |
269 | reject the rebase if it isn't appropriate. Please see the template | |
270 | pre-rebase hook script for an example. | |
271 | ||
702088af | 272 | Upon completion, <branch> will be the current branch. |
031321c6 | 273 | |
1b1dce4b JS |
274 | INTERACTIVE MODE |
275 | ---------------- | |
276 | ||
277 | Rebasing interactively means that you have a chance to edit the commits | |
278 | which are rebased. You can reorder the commits, and you can | |
279 | remove them (weeding out bad or otherwise unwanted patches). | |
280 | ||
281 | The interactive mode is meant for this type of workflow: | |
282 | ||
283 | 1. have a wonderful idea | |
284 | 2. hack on the code | |
285 | 3. prepare a series for submission | |
286 | 4. submit | |
287 | ||
288 | where point 2. consists of several instances of | |
289 | ||
290 | a. regular use | |
291 | 1. finish something worthy of a commit | |
292 | 2. commit | |
293 | b. independent fixup | |
294 | 1. realize that something does not work | |
295 | 2. fix that | |
296 | 3. commit it | |
297 | ||
298 | Sometimes the thing fixed in b.2. cannot be amended to the not-quite | |
299 | perfect commit it fixes, because that commit is buried deeply in a | |
300 | patch series. That is exactly what interactive rebase is for: use it | |
301 | after plenty of "a"s and "b"s, by rearranging and editing | |
302 | commits, and squashing multiple commits into one. | |
303 | ||
304 | Start it with the last commit you want to retain as-is: | |
305 | ||
306 | git rebase -i <after-this-commit> | |
307 | ||
308 | An editor will be fired up with all the commits in your current branch | |
309 | (ignoring merge commits), which come after the given commit. You can | |
310 | reorder the commits in this list to your heart's content, and you can | |
311 | remove them. The list looks more or less like this: | |
312 | ||
313 | ------------------------------------------- | |
314 | pick deadbee The oneline of this commit | |
315 | pick fa1afe1 The oneline of the next commit | |
316 | ... | |
317 | ------------------------------------------- | |
318 | ||
ba020ef5 | 319 | The oneline descriptions are purely for your pleasure; 'git-rebase' will |
1b1dce4b JS |
320 | not look at them but at the commit names ("deadbee" and "fa1afe1" in this |
321 | example), so do not delete or edit the names. | |
322 | ||
323 | By replacing the command "pick" with the command "edit", you can tell | |
ba020ef5 | 324 | 'git-rebase' to stop after applying that commit, so that you can edit |
1b1dce4b JS |
325 | the files and/or the commit message, amend the commit, and continue |
326 | rebasing. | |
327 | ||
328 | If you want to fold two or more commits into one, replace the command | |
329 | "pick" with "squash" for the second and subsequent commit. If the | |
330 | commits had different authors, it will attribute the squashed commit to | |
81ab1cb4 | 331 | the author of the first commit. |
1b1dce4b JS |
332 | |
333 | In both cases, or when a "pick" does not succeed (because of merge | |
334 | errors), the loop will stop to let you fix things, and you can continue | |
335 | the loop with `git rebase --continue`. | |
336 | ||
337 | For example, if you want to reorder the last 5 commits, such that what | |
338 | was HEAD~4 becomes the new HEAD. To achieve that, you would call | |
ba020ef5 | 339 | 'git-rebase' like this: |
1b1dce4b JS |
340 | |
341 | ---------------------- | |
342 | $ git rebase -i HEAD~5 | |
343 | ---------------------- | |
344 | ||
345 | And move the first patch to the end of the list. | |
346 | ||
f09c9b8c JS |
347 | You might want to preserve merges, if you have a history like this: |
348 | ||
349 | ------------------ | |
350 | X | |
351 | \ | |
352 | A---M---B | |
353 | / | |
354 | ---o---O---P---Q | |
355 | ------------------ | |
356 | ||
357 | Suppose you want to rebase the side branch starting at "A" to "Q". Make | |
358 | sure that the current HEAD is "B", and call | |
359 | ||
360 | ----------------------------- | |
361 | $ git rebase -i -p --onto Q O | |
362 | ----------------------------- | |
363 | ||
f0fd889d JS |
364 | |
365 | SPLITTING COMMITS | |
366 | ----------------- | |
367 | ||
368 | In interactive mode, you can mark commits with the action "edit". However, | |
ba020ef5 | 369 | this does not necessarily mean that 'git-rebase' expects the result of this |
f0fd889d JS |
370 | edit to be exactly one commit. Indeed, you can undo the commit, or you can |
371 | add other commits. This can be used to split a commit into two: | |
372 | ||
483bc4f0 | 373 | - Start an interactive rebase with `git rebase -i <commit>^`, where |
f0fd889d JS |
374 | <commit> is the commit you want to split. In fact, any commit range |
375 | will do, as long as it contains that commit. | |
376 | ||
377 | - Mark the commit you want to split with the action "edit". | |
378 | ||
483bc4f0 | 379 | - When it comes to editing that commit, execute `git reset HEAD^`. The |
f0fd889d JS |
380 | effect is that the HEAD is rewound by one, and the index follows suit. |
381 | However, the working tree stays the same. | |
382 | ||
383 | - Now add the changes to the index that you want to have in the first | |
483bc4f0 | 384 | commit. You can use `git add` (possibly interactively) or |
ba020ef5 | 385 | 'git-gui' (or both) to do that. |
f0fd889d JS |
386 | |
387 | - Commit the now-current index with whatever commit message is appropriate | |
388 | now. | |
389 | ||
390 | - Repeat the last two steps until your working tree is clean. | |
391 | ||
483bc4f0 | 392 | - Continue the rebase with `git rebase --continue`. |
f0fd889d JS |
393 | |
394 | If you are not absolutely sure that the intermediate revisions are | |
395 | consistent (they compile, pass the testsuite, etc.) you should use | |
ba020ef5 | 396 | 'git-stash' to stash away the not-yet-committed changes |
f0fd889d JS |
397 | after each commit, test, and amend the commit if fixes are necessary. |
398 | ||
399 | ||
90d1c08e TR |
400 | RECOVERING FROM UPSTREAM REBASE |
401 | ------------------------------- | |
402 | ||
403 | Rebasing (or any other form of rewriting) a branch that others have | |
404 | based work on is a bad idea: anyone downstream of it is forced to | |
405 | manually fix their history. This section explains how to do the fix | |
406 | from the downstream's point of view. The real fix, however, would be | |
407 | to avoid rebasing the upstream in the first place. | |
408 | ||
409 | To illustrate, suppose you are in a situation where someone develops a | |
410 | 'subsystem' branch, and you are working on a 'topic' that is dependent | |
411 | on this 'subsystem'. You might end up with a history like the | |
412 | following: | |
413 | ||
414 | ------------ | |
415 | o---o---o---o---o---o---o---o---o master | |
416 | \ | |
417 | o---o---o---o---o subsystem | |
418 | \ | |
419 | *---*---* topic | |
420 | ------------ | |
421 | ||
422 | If 'subsystem' is rebased against 'master', the following happens: | |
423 | ||
424 | ------------ | |
425 | o---o---o---o---o---o---o---o master | |
426 | \ \ | |
427 | o---o---o---o---o o'--o'--o'--o'--o' subsystem | |
428 | \ | |
429 | *---*---* topic | |
430 | ------------ | |
431 | ||
432 | If you now continue development as usual, and eventually merge 'topic' | |
433 | to 'subsystem', the commits from 'subsystem' will remain duplicated forever: | |
434 | ||
435 | ------------ | |
436 | o---o---o---o---o---o---o---o master | |
437 | \ \ | |
438 | o---o---o---o---o o'--o'--o'--o'--o'--M subsystem | |
439 | \ / | |
440 | *---*---*-..........-*--* topic | |
441 | ------------ | |
442 | ||
443 | Such duplicates are generally frowned upon because they clutter up | |
444 | history, making it harder to follow. To clean things up, you need to | |
445 | transplant the commits on 'topic' to the new 'subsystem' tip, i.e., | |
446 | rebase 'topic'. This becomes a ripple effect: anyone downstream from | |
447 | 'topic' is forced to rebase too, and so on! | |
448 | ||
449 | There are two kinds of fixes, discussed in the following subsections: | |
450 | ||
451 | Easy case: The changes are literally the same.:: | |
452 | ||
453 | This happens if the 'subsystem' rebase was a simple rebase and | |
454 | had no conflicts. | |
455 | ||
456 | Hard case: The changes are not the same.:: | |
457 | ||
458 | This happens if the 'subsystem' rebase had conflicts, or used | |
459 | `\--interactive` to omit, edit, or squash commits; or if the | |
460 | upstream used one of `commit \--amend`, `reset`, or | |
461 | `filter-branch`. | |
462 | ||
463 | ||
464 | The easy case | |
465 | ~~~~~~~~~~~~~ | |
466 | ||
467 | Only works if the changes (patch IDs based on the diff contents) on | |
468 | 'subsystem' are literally the same before and after the rebase | |
469 | 'subsystem' did. | |
470 | ||
471 | In that case, the fix is easy because 'git-rebase' knows to skip | |
472 | changes that are already present in the new upstream. So if you say | |
473 | (assuming you're on 'topic') | |
474 | ------------ | |
475 | $ git rebase subsystem | |
476 | ------------ | |
477 | you will end up with the fixed history | |
478 | ------------ | |
479 | o---o---o---o---o---o---o---o master | |
480 | \ | |
481 | o'--o'--o'--o'--o' subsystem | |
482 | \ | |
483 | *---*---* topic | |
484 | ------------ | |
485 | ||
486 | ||
487 | The hard case | |
488 | ~~~~~~~~~~~~~ | |
489 | ||
490 | Things get more complicated if the 'subsystem' changes do not exactly | |
491 | correspond to the ones before the rebase. | |
492 | ||
493 | NOTE: While an "easy case recovery" sometimes appears to be successful | |
494 | even in the hard case, it may have unintended consequences. For | |
495 | example, a commit that was removed via `git rebase | |
496 | \--interactive` will be **resurrected**! | |
497 | ||
498 | The idea is to manually tell 'git-rebase' "where the old 'subsystem' | |
499 | ended and your 'topic' began", that is, what the old merge-base | |
500 | between them was. You will have to find a way to name the last commit | |
501 | of the old 'subsystem', for example: | |
502 | ||
503 | * With the 'subsystem' reflog: after 'git-fetch', the old tip of | |
504 | 'subsystem' is at `subsystem@\{1}`. Subsequent fetches will | |
505 | increase the number. (See linkgit:git-reflog[1].) | |
506 | ||
507 | * Relative to the tip of 'topic': knowing that your 'topic' has three | |
508 | commits, the old tip of 'subsystem' must be `topic~3`. | |
509 | ||
510 | You can then transplant the old `subsystem..topic` to the new tip by | |
511 | saying (for the reflog case, and assuming you are on 'topic' already): | |
512 | ------------ | |
513 | $ git rebase --onto subsystem subsystem@{1} | |
514 | ------------ | |
515 | ||
516 | The ripple effect of a "hard case" recovery is especially bad: | |
517 | 'everyone' downstream from 'topic' will now have to perform a "hard | |
518 | case" recovery too! | |
519 | ||
520 | ||
1b1dce4b | 521 | Authors |
7fc9d69f | 522 | ------ |
59eb68aa | 523 | Written by Junio C Hamano <gitster@pobox.com> and |
1b1dce4b | 524 | Johannes E. Schindelin <johannes.schindelin@gmx.de> |
7fc9d69f JH |
525 | |
526 | Documentation | |
527 | -------------- | |
528 | Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. | |
529 | ||
530 | GIT | |
531 | --- | |
9e1f0a85 | 532 | Part of the linkgit:git[1] suite |