226
236
You must be in the top directory of your project to start (or continue)
227
237
a rebase. Upon completion, <branch> will be the current branch.
242
Rebasing interactively means that you have a chance to edit the commits
243
which are rebased. You can reorder the commits, and you can
244
remove them (weeding out bad or otherwise unwanted patches).
246
The interactive mode is meant for this type of workflow:
248
1. have a wonderful idea
250
3. prepare a series for submission
253
where point 2. consists of several instances of
256
1. finish something worthy of a commit
259
1. realize that something does not work
263
Sometimes the thing fixed in b.2. cannot be amended to the not-quite
264
perfect commit it fixes, because that commit is buried deeply in a
265
patch series. That is exactly what interactive rebase is for: use it
266
after plenty of "a"s and "b"s, by rearranging and editing
267
commits, and squashing multiple commits into one.
269
Start it with the last commit you want to retain as-is:
271
git rebase -i <after-this-commit>
273
An editor will be fired up with all the commits in your current branch
274
(ignoring merge commits), which come after the given commit. You can
275
reorder the commits in this list to your heart's content, and you can
276
remove them. The list looks more or less like this:
278
-------------------------------------------
279
pick deadbee The oneline of this commit
280
pick fa1afe1 The oneline of the next commit
282
-------------------------------------------
284
The oneline descriptions are purely for your pleasure; `git-rebase` will
285
not look at them but at the commit names ("deadbee" and "fa1afe1" in this
286
example), so do not delete or edit the names.
288
By replacing the command "pick" with the command "edit", you can tell
289
`git-rebase` to stop after applying that commit, so that you can edit
290
the files and/or the commit message, amend the commit, and continue
293
If you want to fold two or more commits into one, replace the command
294
"pick" with "squash" for the second and subsequent commit. If the
295
commits had different authors, it will attribute the squashed commit to
296
the author of the first commit.
298
In both cases, or when a "pick" does not succeed (because of merge
299
errors), the loop will stop to let you fix things, and you can continue
300
the loop with `git rebase --continue`.
302
For example, if you want to reorder the last 5 commits, such that what
303
was HEAD~4 becomes the new HEAD. To achieve that, you would call
304
`git-rebase` like this:
306
----------------------
307
$ git rebase -i HEAD~5
308
----------------------
310
And move the first patch to the end of the list.
312
You might want to preserve merges, if you have a history like this:
322
Suppose you want to rebase the side branch starting at "A" to "Q". Make
323
sure that the current HEAD is "B", and call
325
-----------------------------
326
$ git rebase -i -p --onto Q O
327
-----------------------------
333
In interactive mode, you can mark commits with the action "edit". However,
334
this does not necessarily mean that 'git rebase' expects the result of this
335
edit to be exactly one commit. Indeed, you can undo the commit, or you can
336
add other commits. This can be used to split a commit into two:
338
- Start an interactive rebase with 'git rebase -i <commit>^', where
339
<commit> is the commit you want to split. In fact, any commit range
340
will do, as long as it contains that commit.
342
- Mark the commit you want to split with the action "edit".
344
- When it comes to editing that commit, execute 'git reset HEAD^'. The
345
effect is that the HEAD is rewound by one, and the index follows suit.
346
However, the working tree stays the same.
348
- Now add the changes to the index that you want to have in the first
349
commit. You can use gitlink:git-add[1] (possibly interactively) and/or
350
gitlink:git-gui[1] to do that.
352
- Commit the now-current index with whatever commit message is appropriate
355
- Repeat the last two steps until your working tree is clean.
357
- Continue the rebase with 'git rebase --continue'.
359
If you are not absolutely sure that the intermediate revisions are
360
consistent (they compile, pass the testsuite, etc.) you should use
361
gitlink:git-stash[1] to stash away the not-yet-committed changes
362
after each commit, test, and amend the commit if fixes are necessary.
231
Written by Junio C Hamano <junkio@cox.net>
367
Written by Junio C Hamano <junkio@cox.net> and
368
Johannes E. Schindelin <johannes.schindelin@gmx.de>
added
removed
Documentation/git-rebase.txt
