| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" | |
| "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> | |
| <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> | |
| <head> | |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> | |
| <meta name="generator" content="AsciiDoc 8.2.5" /> | |
| <style type="text/css"> | |
| /* Debug borders */ | |
| p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 { | |
| /* | |
| border: 1px solid red; | |
| */ | |
| } | |
| body { | |
| margin: 1em 5% 1em 5%; | |
| } | |
| a { | |
| color: blue; | |
| text-decoration: underline; | |
| } | |
| a:visited { | |
| color: fuchsia; | |
| } | |
| em { | |
| font-style: italic; | |
| } | |
| strong { | |
| font-weight: bold; | |
| } | |
| tt { | |
| color: navy; | |
| } | |
| h1, h2, h3, h4, h5, h6 { | |
| color: #527bbd; | |
| font-family: sans-serif; | |
| margin-top: 1.2em; | |
| margin-bottom: 0.5em; | |
| line-height: 1.3; | |
| } | |
| h1, h2, h3 { | |
| border-bottom: 2px solid silver; | |
| } | |
| h2 { | |
| padding-top: 0.5em; | |
| } | |
| h3 { | |
| float: left; | |
| } | |
| h3 + * { | |
| clear: left; | |
| } | |
| div.sectionbody { | |
| font-family: serif; | |
| margin-left: 0; | |
| } | |
| hr { | |
| border: 1px solid silver; | |
| } | |
| p { | |
| margin-top: 0.5em; | |
| margin-bottom: 0.5em; | |
| } | |
| pre { | |
| padding: 0; | |
| margin: 0; | |
| } | |
| span#author { | |
| color: #527bbd; | |
| font-family: sans-serif; | |
| font-weight: bold; | |
| font-size: 1.1em; | |
| } | |
| span#email { | |
| } | |
| span#revision { | |
| font-family: sans-serif; | |
| } | |
| div#footer { | |
| font-family: sans-serif; | |
| font-size: small; | |
| border-top: 2px solid silver; | |
| padding-top: 0.5em; | |
| margin-top: 4.0em; | |
| } | |
| div#footer-text { | |
| float: left; | |
| padding-bottom: 0.5em; | |
| } | |
| div#footer-badges { | |
| float: right; | |
| padding-bottom: 0.5em; | |
| } | |
| div#preamble, | |
| div.tableblock, div.imageblock, div.exampleblock, div.verseblock, | |
| div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock, | |
| div.admonitionblock { | |
| margin-right: 10%; | |
| margin-top: 1.5em; | |
| margin-bottom: 1.5em; | |
| } | |
| div.admonitionblock { | |
| margin-top: 2.5em; | |
| margin-bottom: 2.5em; | |
| } | |
| div.content { /* Block element content. */ | |
| padding: 0; | |
| } | |
| /* Block element titles. */ | |
| div.title, caption.title { | |
| font-family: sans-serif; | |
| font-weight: bold; | |
| text-align: left; | |
| margin-top: 1.0em; | |
| margin-bottom: 0.5em; | |
| } | |
| div.title + * { | |
| margin-top: 0; | |
| } | |
| td div.title:first-child { | |
| margin-top: 0.0em; | |
| } | |
| div.content div.title:first-child { | |
| margin-top: 0.0em; | |
| } | |
| div.content + div.title { | |
| margin-top: 0.0em; | |
| } | |
| div.sidebarblock > div.content { | |
| background: #ffffee; | |
| border: 1px solid silver; | |
| padding: 0.5em; | |
| } | |
| div.listingblock { | |
| margin-right: 0%; | |
| } | |
| div.listingblock > div.content { | |
| border: 1px solid silver; | |
| background: #f4f4f4; | |
| padding: 0.5em; | |
| } | |
| div.quoteblock > div.content { | |
| padding-left: 2.0em; | |
| } | |
| div.attribution { | |
| text-align: right; | |
| } | |
| div.verseblock + div.attribution { | |
| text-align: left; | |
| } | |
| div.admonitionblock .icon { | |
| vertical-align: top; | |
| font-size: 1.1em; | |
| font-weight: bold; | |
| text-decoration: underline; | |
| color: #527bbd; | |
| padding-right: 0.5em; | |
| } | |
| div.admonitionblock td.content { | |
| padding-left: 0.5em; | |
| border-left: 2px solid silver; | |
| } | |
| div.exampleblock > div.content { | |
| border-left: 2px solid silver; | |
| padding: 0.5em; | |
| } | |
| div.verseblock div.content { | |
| white-space: pre; | |
| } | |
| div.imageblock div.content { padding-left: 0; } | |
| div.imageblock img { border: 1px solid silver; } | |
| span.image img { border-style: none; } | |
| dl { | |
| margin-top: 0.8em; | |
| margin-bottom: 0.8em; | |
| } | |
| dt { | |
| margin-top: 0.5em; | |
| margin-bottom: 0; | |
| font-style: italic; | |
| } | |
| dd > *:first-child { | |
| margin-top: 0; | |
| } | |
| ul, ol { | |
| list-style-position: outside; | |
| } | |
| div.olist2 ol { | |
| list-style-type: lower-alpha; | |
| } | |
| div.tableblock > table { | |
| border: 3px solid #527bbd; | |
| } | |
| thead { | |
| font-family: sans-serif; | |
| font-weight: bold; | |
| } | |
| tfoot { | |
| font-weight: bold; | |
| } | |
| div.hlist { | |
| margin-top: 0.8em; | |
| margin-bottom: 0.8em; | |
| } | |
| div.hlist td { | |
| padding-bottom: 5px; | |
| } | |
| td.hlist1 { | |
| vertical-align: top; | |
| font-style: italic; | |
| padding-right: 0.8em; | |
| } | |
| td.hlist2 { | |
| vertical-align: top; | |
| } | |
| @media print { | |
| div#footer-badges { display: none; } | |
| } | |
| div#toctitle { | |
| color: #527bbd; | |
| font-family: sans-serif; | |
| font-size: 1.1em; | |
| font-weight: bold; | |
| margin-top: 1.0em; | |
| margin-bottom: 0.1em; | |
| } | |
| div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 { | |
| margin-top: 0; | |
| margin-bottom: 0; | |
| } | |
| div.toclevel2 { | |
| margin-left: 2em; | |
| font-size: 0.9em; | |
| } | |
| div.toclevel3 { | |
| margin-left: 4em; | |
| font-size: 0.9em; | |
| } | |
| div.toclevel4 { | |
| margin-left: 6em; | |
| font-size: 0.9em; | |
| } | |
| include1::./stylesheets/xhtml11-manpage.css[] | |
| /* Workarounds for IE6's broken and incomplete CSS2. */ | |
| div.sidebar-content { | |
| background: #ffffee; | |
| border: 1px solid silver; | |
| padding: 0.5em; | |
| } | |
| div.sidebar-title, div.image-title { | |
| font-family: sans-serif; | |
| font-weight: bold; | |
| margin-top: 0.0em; | |
| margin-bottom: 0.5em; | |
| } | |
| div.listingblock div.content { | |
| border: 1px solid silver; | |
| background: #f4f4f4; | |
| padding: 0.5em; | |
| } | |
| div.quoteblock-content { | |
| padding-left: 2.0em; | |
| } | |
| div.exampleblock-content { | |
| border-left: 2px solid silver; | |
| padding-left: 0.5em; | |
| } | |
| /* IE6 sets dynamically generated links as visited. */ | |
| div#toc a:visited { color: blue; } | |
| </style> | |
| <title>git-rebase(1)</title> | |
| </head> | |
| <body> | |
| <div id="header"> | |
| <h1> | |
| git-rebase(1) Manual Page | |
| </h1> | |
| <h2>NAME</h2> | |
| <div class="sectionbody"> | |
| <p>git-rebase - | |
| Forward-port local commits to the updated upstream head | |
| </p> | |
| </div> | |
| </div> | |
| <h2>SYNOPSIS</h2> | |
| <div class="sectionbody"> | |
| <div class="verseblock"> | |
| <div class="content"><em>git rebase</em> [-i | --interactive] [options] [--onto <newbase>] | |
| <upstream> [<branch>] | |
| <em>git rebase</em> [-i | --interactive] [options] --onto <newbase> | |
| --root [<branch>]</div></div> | |
| <div class="para"><p><em>git rebase</em> --continue | --skip | --abort</p></div> | |
| </div> | |
| <h2 id="_description">DESCRIPTION</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>If <branch> is specified, <em>git-rebase</em> will perform an automatic | |
| <tt>git checkout <branch></tt> before doing anything else. Otherwise | |
| it remains on the current branch.</p></div> | |
| <div class="para"><p>All changes made by commits in the current branch but that are not | |
| in <upstream> are saved to a temporary area. This is the same set | |
| of commits that would be shown by <tt>git log <upstream>..HEAD</tt> (or | |
| <tt>git log HEAD</tt>, if --root is specified).</p></div> | |
| <div class="para"><p>The current branch is reset to <upstream>, or <newbase> if the | |
| --onto option was supplied. This has the exact same effect as | |
| <tt>git reset --hard <upstream></tt> (or <newbase>). ORIG_HEAD is set | |
| to point at the tip of the branch before the reset.</p></div> | |
| <div class="para"><p>The commits that were previously saved into the temporary area are | |
| then reapplied to the current branch, one by one, in order. Note that | |
| any commits in HEAD which introduce the same textual changes as a commit | |
| in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream | |
| with a different commit message or timestamp will be skipped).</p></div> | |
| <div class="para"><p>It is possible that a merge failure will prevent this process from being | |
| completely automatic. You will have to resolve any such merge failure | |
| and run <tt>git rebase --continue</tt>. Another option is to bypass the commit | |
| that caused the merge failure with <tt>git rebase --skip</tt>. To restore the | |
| original <branch> and remove the .git/rebase-apply working files, use the | |
| command <tt>git rebase --abort</tt> instead.</p></div> | |
| <div class="para"><p>Assume the following history exists and the current branch is "topic":</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> A---B---C topic | |
| / | |
| D---E---F---G master</tt></pre> | |
| </div></div> | |
| <div class="para"><p>From this point, the result of either of the following commands:</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><tt>git rebase master | |
| git rebase master topic</tt></pre> | |
| </div></div> | |
| <div class="para"><p>would be:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> A'--B'--C' topic | |
| / | |
| D---E---F---G master</tt></pre> | |
| </div></div> | |
| <div class="para"><p>The latter form is just a short-hand of <tt>git checkout topic</tt> | |
| followed by <tt>git rebase master</tt>.</p></div> | |
| <div class="para"><p>If the upstream branch already contains a change you have made (e.g., | |
| because you mailed a patch which was applied upstream), then that commit | |
| will be skipped. For example, running <tt>git rebase master</tt> on the | |
| following history (in which A' and A introduce the same set of changes, | |
| but have different committer information):</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> A---B---C topic | |
| / | |
| D---E---A'---F master</tt></pre> | |
| </div></div> | |
| <div class="para"><p>will result in:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> B'---C' topic | |
| / | |
| D---E---A'---F master</tt></pre> | |
| </div></div> | |
| <div class="para"><p>Here is how you would transplant a topic branch based on one | |
| branch to another, to pretend that you forked the topic branch | |
| from the latter branch, using <tt>rebase --onto</tt>.</p></div> | |
| <div class="para"><p>First let's assume your <em>topic</em> is based on branch <em>next</em>. | |
| For example, a feature developed in <em>topic</em> depends on some | |
| functionality which is found in <em>next</em>.</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> o---o---o---o---o master | |
| \ | |
| o---o---o---o---o next | |
| \ | |
| o---o---o topic</tt></pre> | |
| </div></div> | |
| <div class="para"><p>We want to make <em>topic</em> forked from branch <em>master</em>; for example, | |
| because the functionality on which <em>topic</em> depends was merged into the | |
| more stable <em>master</em> branch. We want our tree to look like this:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> o---o---o---o---o master | |
| | \ | |
| | o'--o'--o' topic | |
| \ | |
| o---o---o---o---o next</tt></pre> | |
| </div></div> | |
| <div class="para"><p>We can get this using the following command:</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><tt>git rebase --onto master next topic</tt></pre> | |
| </div></div> | |
| <div class="para"><p>Another example of --onto option is to rebase part of a | |
| branch. If we have the following situation:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> H---I---J topicB | |
| / | |
| E---F---G topicA | |
| / | |
| A---B---C---D master</tt></pre> | |
| </div></div> | |
| <div class="para"><p>then the command</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><tt>git rebase --onto master topicA topicB</tt></pre> | |
| </div></div> | |
| <div class="para"><p>would result in:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> H'--I'--J' topicB | |
| / | |
| | E---F---G topicA | |
| |/ | |
| A---B---C---D master</tt></pre> | |
| </div></div> | |
| <div class="para"><p>This is useful when topicB does not depend on topicA.</p></div> | |
| <div class="para"><p>A range of commits could also be removed with rebase. If we have | |
| the following situation:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> E---F---G---H---I---J topicA</tt></pre> | |
| </div></div> | |
| <div class="para"><p>then the command</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><tt>git rebase --onto topicA~5 topicA~3 topicA</tt></pre> | |
| </div></div> | |
| <div class="para"><p>would result in the removal of commits F and G:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> E---H'---I'---J' topicA</tt></pre> | |
| </div></div> | |
| <div class="para"><p>This is useful if F and G were flawed in some way, or should not be | |
| part of topicA. Note that the argument to --onto and the <upstream> | |
| parameter can be any valid commit-ish.</p></div> | |
| <div class="para"><p>In case of conflict, <em>git-rebase</em> will stop at the first problematic commit | |
| and leave conflict markers in the tree. You can use <em>git-diff</em> to locate | |
| the markers (<<<<<<) and make edits to resolve the conflict. For each | |
| file you edit, you need to tell git that the conflict has been resolved, | |
| typically this would be done with</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><tt>git add <filename></tt></pre> | |
| </div></div> | |
| <div class="para"><p>After resolving the conflict manually and updating the index with the | |
| desired resolution, you can continue the rebasing process with</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><tt>git rebase --continue</tt></pre> | |
| </div></div> | |
| <div class="para"><p>Alternatively, you can undo the <em>git-rebase</em> with</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><tt>git rebase --abort</tt></pre> | |
| </div></div> | |
| </div> | |
| <h2 id="_options">OPTIONS</h2> | |
| <div class="sectionbody"> | |
| <div class="vlist"><dl> | |
| <dt> | |
| <newbase> | |
| </dt> | |
| <dd> | |
| <p> | |
| Starting point at which to create the new commits. If the | |
| --onto option is not specified, the starting point is | |
| <upstream>. May be any valid commit, and not just an | |
| existing branch name. | |
| </p> | |
| </dd> | |
| <dt> | |
| <upstream> | |
| </dt> | |
| <dd> | |
| <p> | |
| Upstream branch to compare against. May be any valid commit, | |
| not just an existing branch name. | |
| </p> | |
| </dd> | |
| <dt> | |
| <branch> | |
| </dt> | |
| <dd> | |
| <p> | |
| Working branch; defaults to HEAD. | |
| </p> | |
| </dd> | |
| <dt> | |
| --continue | |
| </dt> | |
| <dd> | |
| <p> | |
| Restart the rebasing process after having resolved a merge conflict. | |
| </p> | |
| </dd> | |
| <dt> | |
| --abort | |
| </dt> | |
| <dd> | |
| <p> | |
| Restore the original branch and abort the rebase operation. | |
| </p> | |
| </dd> | |
| <dt> | |
| --skip | |
| </dt> | |
| <dd> | |
| <p> | |
| Restart the rebasing process by skipping the current patch. | |
| </p> | |
| </dd> | |
| <dt> | |
| -m | |
| </dt> | |
| <dt> | |
| --merge | |
| </dt> | |
| <dd> | |
| <p> | |
| Use merging strategies to rebase. When the recursive (default) merge | |
| strategy is used, this allows rebase to be aware of renames on the | |
| upstream side. | |
| </p> | |
| </dd> | |
| <dt> | |
| -s <strategy> | |
| </dt> | |
| <dt> | |
| --strategy=<strategy> | |
| </dt> | |
| <dd> | |
| <p> | |
| Use the given merge strategy; can be supplied more than | |
| once to specify them in the order they should be tried. | |
| If there is no <tt>-s</tt> option, a built-in list of strategies | |
| is used instead (<em>git-merge-recursive</em> when merging a single | |
| head, <em>git-merge-octopus</em> otherwise). This implies --merge. | |
| </p> | |
| </dd> | |
| <dt> | |
| -v | |
| </dt> | |
| <dt> | |
| --verbose | |
| </dt> | |
| <dd> | |
| <p> | |
| Display a diffstat of what changed upstream since the last rebase. | |
| </p> | |
| </dd> | |
| <dt> | |
| --no-verify | |
| </dt> | |
| <dd> | |
| <p> | |
| This option bypasses the pre-rebase hook. See also <a href="githooks.html">githooks(5)</a>. | |
| </p> | |
| </dd> | |
| <dt> | |
| -C<n> | |
| </dt> | |
| <dd> | |
| <p> | |
| Ensure at least <n> lines of surrounding context match before | |
| and after each change. When fewer lines of surrounding | |
| context exist they all must match. By default no context is | |
| ever ignored. | |
| </p> | |
| </dd> | |
| <dt> | |
| --whitespace=<nowarn|warn|error|error-all|strip> | |
| </dt> | |
| <dd> | |
| <p> | |
| This flag is passed to the <em>git-apply</em> program | |
| (see <a href="git-apply.html">git-apply(1)</a>) that applies the patch. | |
| Incompatible with the --interactive option. | |
| </p> | |
| </dd> | |
| <dt> | |
| -i | |
| </dt> | |
| <dt> | |
| --interactive | |
| </dt> | |
| <dd> | |
| <p> | |
| Make a list of the commits which are about to be rebased. Let the | |
| user edit that list before rebasing. This mode can also be used to | |
| split commits (see SPLITTING COMMITS below). | |
| </p> | |
| </dd> | |
| <dt> | |
| -p | |
| </dt> | |
| <dt> | |
| --preserve-merges | |
| </dt> | |
| <dd> | |
| <p> | |
| Instead of ignoring merges, try to recreate them. | |
| </p> | |
| </dd> | |
| <dt> | |
| --root | |
| </dt> | |
| <dd> | |
| <p> | |
| Rebase all commits reachable from <branch>, instead of | |
| limiting them with an <upstream>. This allows you to rebase | |
| the root commit(s) on a branch. Must be used with --onto, and | |
| will skip changes already contained in <newbase> (instead of | |
| <upstream>). When used together with --preserve-merges, <em>all</em> | |
| root commits will be rewritten to have <newbase> as parent | |
| instead. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| </div> | |
| <h2 id="_merge_strategies">MERGE STRATEGIES</h2> | |
| <div class="sectionbody"> | |
| <div class="vlist"><dl> | |
| <dt> | |
| resolve | |
| </dt> | |
| <dd> | |
| <p> | |
| This can only resolve two heads (i.e. the current branch | |
| and another branch you pulled from) using 3-way merge | |
| algorithm. It tries to carefully detect criss-cross | |
| merge ambiguities and is considered generally safe and | |
| fast. | |
| </p> | |
| </dd> | |
| <dt> | |
| recursive | |
| </dt> | |
| <dd> | |
| <p> | |
| This can only resolve two heads using 3-way merge | |
| algorithm. When there are more than one common | |
| ancestors that can be used for 3-way merge, it creates a | |
| merged tree of the common ancestors and uses that as | |
| the reference tree for the 3-way merge. This has been | |
| reported to result in fewer merge conflicts without | |
| causing mis-merges by tests done on actual merge commits | |
| taken from Linux 2.6 kernel development history. | |
| Additionally this can detect and handle merges involving | |
| renames. This is the default merge strategy when | |
| pulling or merging one branch. | |
| </p> | |
| </dd> | |
| <dt> | |
| octopus | |
| </dt> | |
| <dd> | |
| <p> | |
| This resolves more than two-head case, but refuses to do | |
| complex merge that needs manual resolution. It is | |
| primarily meant to be used for bundling topic branch | |
| heads together. This is the default merge strategy when | |
| pulling or merging more than one branches. | |
| </p> | |
| </dd> | |
| <dt> | |
| ours | |
| </dt> | |
| <dd> | |
| <p> | |
| This resolves any number of heads, but the result of the | |
| merge is always the current branch head. It is meant to | |
| be used to supersede old development history of side | |
| branches. | |
| </p> | |
| </dd> | |
| <dt> | |
| subtree | |
| </dt> | |
| <dd> | |
| <p> | |
| This is a modified recursive strategy. When merging trees A and | |
| B, if B corresponds to a subtree of A, B is first adjusted to | |
| match the tree structure of A, instead of reading the trees at | |
| the same level. This adjustment is also done to the common | |
| ancestor tree. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| </div> | |
| <h2 id="_notes">NOTES</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>You should understand the implications of using <em>git-rebase</em> on a | |
| repository that you share. See also RECOVERING FROM UPSTREAM REBASE | |
| below.</p></div> | |
| <div class="para"><p>When the git-rebase command is run, it will first execute a "pre-rebase" | |
| hook if one exists. You can use this hook to do sanity checks and | |
| reject the rebase if it isn't appropriate. Please see the template | |
| pre-rebase hook script for an example.</p></div> | |
| <div class="para"><p>Upon completion, <branch> will be the current branch.</p></div> | |
| </div> | |
| <h2 id="_interactive_mode">INTERACTIVE MODE</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>Rebasing interactively means that you have a chance to edit the commits | |
| which are rebased. You can reorder the commits, and you can | |
| remove them (weeding out bad or otherwise unwanted patches).</p></div> | |
| <div class="para"><p>The interactive mode is meant for this type of workflow:</p></div> | |
| <div class="olist"><ol> | |
| <li> | |
| <p> | |
| have a wonderful idea | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| hack on the code | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| prepare a series for submission | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| submit | |
| </p> | |
| </li> | |
| </ol></div> | |
| <div class="para"><p>where point 2. consists of several instances of</p></div> | |
| <div class="olist2"><ol> | |
| <li> | |
| <p> | |
| regular use | |
| </p> | |
| <div class="olist"><ol> | |
| <li> | |
| <p> | |
| finish something worthy of a commit | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| commit | |
| </p> | |
| </li> | |
| </ol></div> | |
| </li> | |
| <li> | |
| <p> | |
| independent fixup | |
| </p> | |
| <div class="olist"><ol> | |
| <li> | |
| <p> | |
| realize that something does not work | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| fix that | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| commit it | |
| </p> | |
| </li> | |
| </ol></div> | |
| </li> | |
| </ol></div> | |
| <div class="para"><p>Sometimes the thing fixed in b.2. cannot be amended to the not-quite | |
| perfect commit it fixes, because that commit is buried deeply in a | |
| patch series. That is exactly what interactive rebase is for: use it | |
| after plenty of "a"s and "b"s, by rearranging and editing | |
| commits, and squashing multiple commits into one.</p></div> | |
| <div class="para"><p>Start it with the last commit you want to retain as-is:</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><tt>git rebase -i <after-this-commit></tt></pre> | |
| </div></div> | |
| <div class="para"><p>An editor will be fired up with all the commits in your current branch | |
| (ignoring merge commits), which come after the given commit. You can | |
| reorder the commits in this list to your heart's content, and you can | |
| remove them. The list looks more or less like this:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>pick deadbee The oneline of this commit | |
| pick fa1afe1 The oneline of the next commit | |
| ...</tt></pre> | |
| </div></div> | |
| <div class="para"><p>The oneline descriptions are purely for your pleasure; <em>git-rebase</em> will | |
| not look at them but at the commit names ("deadbee" and "fa1afe1" in this | |
| example), so do not delete or edit the names.</p></div> | |
| <div class="para"><p>By replacing the command "pick" with the command "edit", you can tell | |
| <em>git-rebase</em> to stop after applying that commit, so that you can edit | |
| the files and/or the commit message, amend the commit, and continue | |
| rebasing.</p></div> | |
| <div class="para"><p>If you want to fold two or more commits into one, replace the command | |
| "pick" with "squash" for the second and subsequent commit. If the | |
| commits had different authors, it will attribute the squashed commit to | |
| the author of the first commit.</p></div> | |
| <div class="para"><p>In both cases, or when a "pick" does not succeed (because of merge | |
| errors), the loop will stop to let you fix things, and you can continue | |
| the loop with <tt>git rebase --continue</tt>.</p></div> | |
| <div class="para"><p>For example, if you want to reorder the last 5 commits, such that what | |
| was HEAD~4 becomes the new HEAD. To achieve that, you would call | |
| <em>git-rebase</em> like this:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>$ git rebase -i HEAD~5</tt></pre> | |
| </div></div> | |
| <div class="para"><p>And move the first patch to the end of the list.</p></div> | |
| <div class="para"><p>You might want to preserve merges, if you have a history like this:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> X | |
| \ | |
| A---M---B | |
| / | |
| ---o---O---P---Q</tt></pre> | |
| </div></div> | |
| <div class="para"><p>Suppose you want to rebase the side branch starting at "A" to "Q". Make | |
| sure that the current HEAD is "B", and call</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt>$ git rebase -i -p --onto Q O</tt></pre> | |
| </div></div> | |
| </div> | |
| <h2 id="_splitting_commits">SPLITTING COMMITS</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>In interactive mode, you can mark commits with the action "edit". However, | |
| this does not necessarily mean that <em>git-rebase</em> expects the result of this | |
| edit to be exactly one commit. Indeed, you can undo the commit, or you can | |
| add other commits. This can be used to split a commit into two:</p></div> | |
| <div class="ilist"><ul> | |
| <li> | |
| <p> | |
| Start an interactive rebase with <tt>git rebase -i <commit>^</tt>, where | |
| <commit> is the commit you want to split. In fact, any commit range | |
| will do, as long as it contains that commit. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Mark the commit you want to split with the action "edit". | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| When it comes to editing that commit, execute <tt>git reset HEAD^</tt>. The | |
| effect is that the HEAD is rewound by one, and the index follows suit. | |
| However, the working tree stays the same. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Now add the changes to the index that you want to have in the first | |
| commit. You can use <tt>git add</tt> (possibly interactively) or | |
| <em>git-gui</em> (or both) to do that. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Commit the now-current index with whatever commit message is appropriate | |
| now. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Repeat the last two steps until your working tree is clean. | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Continue the rebase with <tt>git rebase --continue</tt>. | |
| </p> | |
| </li> | |
| </ul></div> | |
| <div class="para"><p>If you are not absolutely sure that the intermediate revisions are | |
| consistent (they compile, pass the testsuite, etc.) you should use | |
| <em>git-stash</em> to stash away the not-yet-committed changes | |
| after each commit, test, and amend the commit if fixes are necessary.</p></div> | |
| </div> | |
| <h2 id="_recovering_from_upstream_rebase">RECOVERING FROM UPSTREAM REBASE</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>Rebasing (or any other form of rewriting) a branch that others have | |
| based work on is a bad idea: anyone downstream of it is forced to | |
| manually fix their history. This section explains how to do the fix | |
| from the downstream's point of view. The real fix, however, would be | |
| to avoid rebasing the upstream in the first place.</p></div> | |
| <div class="para"><p>To illustrate, suppose you are in a situation where someone develops a | |
| <em>subsystem</em> branch, and you are working on a <em>topic</em> that is dependent | |
| on this <em>subsystem</em>. You might end up with a history like the | |
| following:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> o---o---o---o---o---o---o---o---o master | |
| \ | |
| o---o---o---o---o subsystem | |
| \ | |
| *---*---* topic</tt></pre> | |
| </div></div> | |
| <div class="para"><p>If <em>subsystem</em> is rebased against <em>master</em>, the following happens:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> o---o---o---o---o---o---o---o master | |
| \ \ | |
| o---o---o---o---o o'--o'--o'--o'--o' subsystem | |
| \ | |
| *---*---* topic</tt></pre> | |
| </div></div> | |
| <div class="para"><p>If you now continue development as usual, and eventually merge <em>topic</em> | |
| to <em>subsystem</em>, the commits from <em>subsystem</em> will remain duplicated forever:</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> o---o---o---o---o---o---o---o master | |
| \ \ | |
| o---o---o---o---o o'--o'--o'--o'--o'--M subsystem | |
| \ / | |
| *---*---*-..........-*--* topic</tt></pre> | |
| </div></div> | |
| <div class="para"><p>Such duplicates are generally frowned upon because they clutter up | |
| history, making it harder to follow. To clean things up, you need to | |
| transplant the commits on <em>topic</em> to the new <em>subsystem</em> tip, i.e., | |
| rebase <em>topic</em>. This becomes a ripple effect: anyone downstream from | |
| <em>topic</em> is forced to rebase too, and so on!</p></div> | |
| <div class="para"><p>There are two kinds of fixes, discussed in the following subsections:</p></div> | |
| <div class="vlist"><dl> | |
| <dt> | |
| Easy case: The changes are literally the same. | |
| </dt> | |
| <dd> | |
| <p> | |
| This happens if the <em>subsystem</em> rebase was a simple rebase and | |
| had no conflicts. | |
| </p> | |
| </dd> | |
| <dt> | |
| Hard case: The changes are not the same. | |
| </dt> | |
| <dd> | |
| <p> | |
| This happens if the <em>subsystem</em> rebase had conflicts, or used | |
| <tt>--interactive</tt> to omit, edit, or squash commits; or if the | |
| upstream used one of <tt>commit --amend</tt>, <tt>reset</tt>, or | |
| <tt>filter-branch</tt>. | |
| </p> | |
| </dd> | |
| </dl></div> | |
| <h3 id="_the_easy_case">The easy case</h3><div style="clear:left"></div> | |
| <div class="para"><p>Only works if the changes (patch IDs based on the diff contents) on | |
| <em>subsystem</em> are literally the same before and after the rebase | |
| <em>subsystem</em> did.</p></div> | |
| <div class="para"><p>In that case, the fix is easy because <em>git-rebase</em> knows to skip | |
| changes that are already present in the new upstream. So if you say | |
| (assuming you're on <em>topic</em>)</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> $ git rebase subsystem</tt></pre> | |
| </div></div> | |
| <div class="para"><p>you will end up with the fixed history</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> o---o---o---o---o---o---o---o master | |
| \ | |
| o'--o'--o'--o'--o' subsystem | |
| \ | |
| *---*---* topic</tt></pre> | |
| </div></div> | |
| <h3 id="_the_hard_case">The hard case</h3><div style="clear:left"></div> | |
| <div class="para"><p>Things get more complicated if the <em>subsystem</em> changes do not exactly | |
| correspond to the ones before the rebase.</p></div> | |
| <div class="admonitionblock"> | |
| <table><tr> | |
| <td class="icon"> | |
| <div class="title">Note</div> | |
| </td> | |
| <td class="content">While an "easy case recovery" sometimes appears to be successful | |
| even in the hard case, it may have unintended consequences. For | |
| example, a commit that was removed via <tt>git rebase | |
| --interactive</tt> will be <strong>*resurrected</strong>*!</td> | |
| </tr></table> | |
| </div> | |
| <div class="para"><p>The idea is to manually tell <em>git-rebase</em> "where the old <em>subsystem</em> | |
| ended and your <em>topic</em> began", that is, what the old merge-base | |
| between them was. You will have to find a way to name the last commit | |
| of the old <em>subsystem</em>, for example:</p></div> | |
| <div class="ilist"><ul> | |
| <li> | |
| <p> | |
| With the <em>subsystem</em> reflog: after <em>git-fetch</em>, the old tip of | |
| <em>subsystem</em> is at <tt>subsystem@{1}</tt>. Subsequent fetches will | |
| increase the number. (See <a href="git-reflog.html">git-reflog(1)</a>.) | |
| </p> | |
| </li> | |
| <li> | |
| <p> | |
| Relative to the tip of <em>topic</em>: knowing that your <em>topic</em> has three | |
| commits, the old tip of <em>subsystem</em> must be <tt>topic~3</tt>. | |
| </p> | |
| </li> | |
| </ul></div> | |
| <div class="para"><p>You can then transplant the old <tt>subsystem..topic</tt> to the new tip by | |
| saying (for the reflog case, and assuming you are on <em>topic</em> already):</p></div> | |
| <div class="listingblock"> | |
| <div class="content"> | |
| <pre><tt> $ git rebase --onto subsystem subsystem@{1}</tt></pre> | |
| </div></div> | |
| <div class="para"><p>The ripple effect of a "hard case" recovery is especially bad: | |
| <em>everyone</em> downstream from <em>topic</em> will now have to perform a "hard | |
| case" recovery too!</p></div> | |
| </div> | |
| <h2 id="_authors">Authors</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>Written by Junio C Hamano <gitster@pobox.com> and | |
| Johannes E. Schindelin <johannes.schindelin@gmx.de></p></div> | |
| </div> | |
| <h2 id="_documentation">Documentation</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.</p></div> | |
| </div> | |
| <h2 id="_git">GIT</h2> | |
| <div class="sectionbody"> | |
| <div class="para"><p>Part of the <a href="git.html">git(1)</a> suite</p></div> | |
| </div> | |
| <div id="footer"> | |
| <div id="footer-text"> | |
| Last updated 2009-02-14 08:18:30 UTC | |
| </div> | |
| </div> | |
| </body> | |
| </html> |