mirror of
https://github.com/fofolee/uTools-Manuals.git
synced 2025-06-30 05:22:44 +08:00
42 lines
51 KiB
HTML
42 lines
51 KiB
HTML
<div class="c-markdown doc-markdown"><div class="doc-postil"><div class="c-markdown"><h2>命名</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>git-rebase - 重新申请提交另一个基本技巧</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>概要</h2></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] [<upstream> [<branch>]]git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] --root [<branch>]git rebase --continue | --skip | --abort | --quit | --edit-todo</pre></div></div><div class="doc-postil"><div class="c-markdown"><h2>描述</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>如果指定 <branch> ，<code>git rebase</code>则在执行其他任何操作之前将执行自动操作<code>git checkout <branch></code>。否则它将保留在当前分支上。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果未指定 <upstream> ，则将使用在分支。<name> .remote和分支。<name> .merge 选项中配置的上游（有关详细信息，请参阅 git-config [1]），且<code>--fork-point</code>假定该选项。如果您当前没有在任何分支上，或者当前分支没有配置上游，那么 rebase 会中止。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>所有由当前分支提交但不在 <upstream> 中的更改都保存到临时区域。这与将要显示的一组提交相同<code>git log <upstream>..HEAD</code>; 或者通过<code>git log 'fork_point'..HEAD</code>，如果<code>--fork-point</code>处于活动状态（请参阅<code>--fork-point</code>下面的说明）; 或者，如果<code>--root</code>指定了选项，则<code>git log HEAD</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果提供了 --onto 选项，则当前分支将重置为 <upstream> 或 <newbase> 。这与<code>git reset --hard <upstream></code>（或<newbase>）具有完全相同的效果。ORIG_HEAD 被设置为在复位之前指向分支的尖端。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>之前保存到临时区域的提交按顺序依次重新应用到当前分支。请注意，HEAD 中提交的任何提交与 HEAD .. <upstream> 中的提交相同的文本更改均被省略（即，已经接受上游提供不同提交消息或时间戳的补丁将被跳过）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>合并失败可能会阻止此过程完全自动化。您将不得不解决任何此类合并失败并运行<code>git rebase --continue</code>。另一种选择是绕过导致合并失败的提交<code>git rebase --skip</code>。要检出原始 <branch> 并删除 .git / rebase-apply 工作文件，请改用命令<code>git rebase --abort</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>假设存在以下历史记录，并且当前分支是“topic”：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> A---B---C topic /
|
||
|
||
D---E---F---G master</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>从这一点来看，以下任一命令的结果：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">git rebase master
|
||
|
||
git rebase master topic</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>将会是：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> A'--B'--C' topic /
|
||
|
||
D---E---F---G master</pre></div></div><div class="doc-postil"><div class="c-markdown"><p><strong>注：</strong>后一种形式只是一个速记<code>git checkout topic</code>，接着<code>git rebase master</code>。退出<code>topic</code>分支时仍保留退出分支。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果上游分支已经包含您所做的更改（例如，因为您邮寄了上游应用的补丁），则该提交将被跳过。例如，运行<code>git rebase master</code>以下历史记录（其中<code>A'</code>并<code>A</code>引入相同的一组更改，但具有不同的提交者信息）：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> A---B---C topic /
|
||
|
||
D---E---A'---F master</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>结果会是：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> B'---C' topic /
|
||
|
||
D---E---A'---F master</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这里是如何将基于一个分支的主题分支移植到另一个分支，假装你使用后者分支从后一分支分支的主题分支<code>rebase --onto</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>首先让我们假设你<code>topic</code>是基于分支的<code>next</code>。例如，开发的功能<code>topic</code>取决于可以在其中找到的某些功能<code>next</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> o---o---o---o---o master
|
||
|
||
\
|
||
|
||
o---o---o---o---o next
|
||
|
||
\
|
||
|
||
o---o---o topic</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>我们想<code>topic</code>从分支中分出来<code>master</code>; 例如，因为<code>topic</code>依赖的功能被合并到更稳定的<code>master</code>分支中。我们希望我们的树看起来像这样：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> o---o---o---o---o master | \ | o'--o'--o' topic
|
||
|
||
\
|
||
|
||
o---o---o---o---o next</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>我们可以使用以下命令来获取它：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">git rebase --onto master next topic</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>另一个例子 --onto 选项是重新绑定分支的一部分。如果我们有以下情况：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> H---I---J topicB /
|
||
|
||
E---F---G topicA /
|
||
|
||
A---B---C---D master</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>然后命令</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">git rebase --onto master topicA topicB</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>会导致：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> H'--I'--J' topicB / | E---F---G topicA |/
|
||
|
||
A---B---C---D master</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>当 topicB 不依赖于 topicA 时，这很有用。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>一系列的提交也可以用 rebase 去除。如果我们有以下情况：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> E---F---G---H---I---J topicA</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>然后命令</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">git rebase --onto topicA~5 topicA~3 topicA</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>会导致提交 F 和 G 被移除：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> E---H'---I'---J' topicA</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>如果 F 和 G 以某种方式存在缺陷，或者不应该成为 topicA 的一部分，这很有用。请注意，--onto 和 <upstream> 参数的参数可以是任何有效的 commit-ish 。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果发生冲突，<code>git rebase</code>将停在第一个有问题的提交并在树中留下冲突标记。您可以使用<code>git diff</code>找到标记（<<<<<<）并进行编辑以解决冲突。对于你编辑的每一个文件，你都需要告诉 Git 冲突已经解决，通常这是可以完成的</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">git add <filename></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>手动解决冲突并以所需的分辨率更新索引后，您可以继续使用重新绑定过程</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">git rebase --continue</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>另外，您也可以撤消<code>git rebase</code></p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">git rebase --abort</pre></div></div><div class="doc-postil"><div class="c-markdown"><h2>组态</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>rebase.stat</p></div></div><div class="doc-postil"><div class="c-markdown"><p>是否显示自上次变基期以来上游变化的差异。默认为 False 。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>rebase.autoSquash</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果<code>--autosquash</code>默认设置为 true 启用选项。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>rebase.autoStash</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果<code>--autostash</code>默认设置为 true 启用选项。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>rebase.missingCommitsCheck</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果设置为 “warn” ，则在交互模式下打印有关移除提交的警告。如果设置为 “error” ，请打印警告并停止重设。如果设置为 “ignore” ，则不进行检查。默认情况下 “ignore” 。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>rebase.instructionFormat</p></div></div><div class="doc-postil"><div class="c-markdown"><p>自定义提交列表格式，用于重新<code>--interactive</code>绑定。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>选项</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>--onto <newbase></p></div></div><div class="doc-postil"><div class="c-markdown"><p>创建新提交的起点。如果没有指定 --onto 选项，起点是 <upstream> 。可以是任何有效的提交，而不仅仅是现有的分支名称。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>作为特例，如果只有一个合并基础，则可以使用“A ... B”作为 A 和 B 合并基的快捷方式。您最多可以省略 A 和 B 中的一个，在这种情况下，它默认为 HEAD 。</p></div></div><div class="doc-postil"><div class="c-markdown"><p><upstream></p></div></div><div class="doc-postil"><div class="c-markdown"><p>上游分支进行比较。可以是任何有效的提交，而不仅仅是现有的分支名称。默认为当前分支的配置上游。</p></div></div><div class="doc-postil"><div class="c-markdown"><p><branch></p></div></div><div class="doc-postil"><div class="c-markdown"><p>工作分部; 默认为 HEAD 。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--continue</p></div></div><div class="doc-postil"><div class="c-markdown"><p>解决了合并冲突后重新启动重新绑定过程。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--abort</p></div></div><div class="doc-postil"><div class="c-markdown"><p>中止 rebase 操作并将 HEAD 重置为原始分支。如果 <reb> 操作开始时提供 <branch> ，则 HEAD 将重置为 <branch> 。否则 HEAD 将重置为启动 rebase 操作时的位置。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--quit</p></div></div><div class="doc-postil"><div class="c-markdown"><p>放弃 rebase 操作，但 HEAD 不会重置回原始分支。索引和工作树也因此保持不变。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--keep-empty</p></div></div><div class="doc-postil"><div class="c-markdown"><p>在结果中保留不改变父项的任何提交。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--skip</p></div></div><div class="doc-postil"><div class="c-markdown"><p>通过跳过当前补丁重新启动重新绑定过程。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--edit-todo</p></div></div><div class="doc-postil"><div class="c-markdown"><p>在交互式重新绑定期间编辑待办事项列表。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-m --merge</p></div></div><div class="doc-postil"><div class="c-markdown"><p>使用合并策略来重新分配。当使用递归（默认）合并策略时，这允许 rebase 知道上游端的重命名。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>请注意，通过在 <upstream> 分支顶部重播来自工作分支的每个提交，合并索引合并工作。正因为如此，当合并冲突发生时，该方报告的<code>ours</code>是迄今为止重新分类的系列，从 <upstream> 开始，并且<code>theirs</code>是工作分支。换句话说，双方交换。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-s <strategy> --strategy=<strategy></p></div></div><div class="doc-postil"><div class="c-markdown"><p>使用给定的合并策略。如果没有<code>-s</code>选项<code>git merge-recursive</code>用来代替。这意味着 - 合并。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>因为<code>git rebase</code>使用给定的策略，重播每个都会在 <upstream> 分支之上的工作分支提交，所以使用该<code>ours</code>策略只会丢弃 <branch> 中的所有修补程序，这没有多大意义。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-X <strategy-option> --strategy-option=<strategy-option></p></div></div><div class="doc-postil"><div class="c-markdown"><p>将 <strategy-option> 传递给合并策略。这意味着<code>--merge</code>，如果没有明确说明战略<code>-s recursive</code>。请注意该选项的逆转<code>ours</code>和<code>theirs</code>上面所述<code>-m</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-S<keyid> --gpg-sign=<keyid></p></div></div><div class="doc-postil"><div class="c-markdown"><p>GPG 标志提交。该<code>keyid</code>参数是可选的，并且默认为提交者身份; 如果指定，它必须粘贴到选项没有空格。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-q --quiet</p></div></div><div class="doc-postil"><div class="c-markdown"><p>be quiet。意味着 -- 无统计。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-v --verbose</p></div></div><div class="doc-postil"><div class="c-markdown"><p>详细。意味着--要统计。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--stat</p></div></div><div class="doc-postil"><div class="c-markdown"><p>显示自上次 rebase 以来上游变化的差异。diffstat 也由配置选项 rebase.stat 控制。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-n --no-stat</p></div></div><div class="doc-postil"><div class="c-markdown"><p>不要将 diffstat 显示为 rebase 过程的一部分。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--no-verify</p></div></div><div class="doc-postil"><div class="c-markdown"><p>此选项绕过预先重新绑定钩子。另见 githooks [5]。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--verify</p></div></div><div class="doc-postil"><div class="c-markdown"><p>允许预重贴挂钩运行，这是默认设置。这个选项可以用来覆盖--no-verify 。另见 githooks [5] 。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-C<n></p></div></div><div class="doc-postil"><div class="c-markdown"><p>确保每次更改之前和之后至少有 <n> 行周围环境匹配。当存在较少的周围环境线时，它们都必须匹配。默认情况下，不会忽略上下文。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-f --force-rebase</p></div></div><div class="doc-postil"><div class="c-markdown"><p>即使当前分支是最新的，并且<code>--force</code>没有做任何事情的命令也不会返回，强制重新分配。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>你可能会发现这个（或者 --no-ff 带有交互式底座）在恢复主题分支合并之后很有用，因为这个选项用新提交重新创建了主题分支，所以它可以在不需要“还原返回”的情况下成功地重新建立。在<a href="https://git-scm.com/docs/howto/revert-a-faulty-merge.html" target="_blank">还原-A-错误的合并操作方法</a>的详细说明）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--fork-point --no-fork-point</p></div></div><div class="doc-postil"><div class="c-markdown"><p>计算 <branch> 引入的提交时，使用 reflog 可以在 <upstream> 和 <branch> 之间找到更好的共同祖先。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>当 --fork-point 被激活时，<code>fork_point</code>将被用来代替<upstream>来计算 rebase 的提交集合<code>fork_point</code>，<code>git merge-base --fork-point <upstream> <branch></code>命令的结果在哪里（参见 git-merge-base [1]）。如果<code>fork_point</code>结果为空，<upstream> 将用作后备。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果在命令行中给出了 <upstream> 或 --root ，则默认为<code>--no-fork-point</code>，否则为默认值<code>--fork-point</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--ignore-whitespace --whitespace=<option></p></div></div><div class="doc-postil"><div class="c-markdown"><p>这些标志被传递给<code>git apply</code>应用该补丁的程序（参见 git-apply [1]）。与 --interactive 选项不兼容。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--committer-date-is-author-date --ignore-date</p></div></div><div class="doc-postil"><div class="c-markdown"><p>这些标志被传递给<code>git am</code>轻松更改重定义的提交的日期（请参阅 git-am [1]）。与 --interactive 选项不兼容。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--signoff</p></div></div><div class="doc-postil"><div class="c-markdown"><p>这个标志被传递来<code>git am</code>签署所有重新发布的提交（参见 git-am [1]）。与 --interactive 选项不兼容。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-i --interactive</p></div></div><div class="doc-postil"><div class="c-markdown"><p>列出将要重新分配的提交列表。让用户在重新绑定之前编辑该列表。该模式也可用于分割提交（请参阅下面的分割提交）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>提交列表格式可以通过设置配置选项 rebase.instructionFormat 进行更改。自定义的指令格式会自动将格式中的长提交哈希值作为前缀。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-p --preserve-merges</p></div></div><div class="doc-postil"><div class="c-markdown"><p>重新创建合并提交，而不是通过重播合并提交引入的提交来平坦化历史。不保留合并冲突解决方案或手动修改合并提交。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>这在<code>--interactive</code>内部使用机制，但<code>--interactive</code>明确地将其与选项结合通常不是一个好主意，除非您知道自己在做什么（请参阅下面的 BUGS ）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>-x <cmd> --exec <cmd></p></div></div><div class="doc-postil"><div class="c-markdown"><p>在每行在最终历史记录中创建提交后附加 “exec <cmd>” 。<cmd> 将被解释为一个或多个 shell 命令。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>您可以通过使用几个命令的一个实例来<code>--exec</code>执行几个命令：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">git rebase -i --exec "cmd1 && cmd2 && ..."</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>或者通过给予多个<code>--exec</code>：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">git rebase -i --exec "cmd1" --exec "cmd2" --exec ...</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>如果<code>--autosquash</code>使用，中间提交不会追加 “exec” 行，并且只会出现在 squash / fixup 系列的末尾。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>这在<code>--interactive</code>内部使用机制，但它可以在没有明确的情况下运行<code>--interactive</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--root</p></div></div><div class="doc-postil"><div class="c-markdown"><p>重新规划从 <branch> 可访问的所有提交，而不是用 <upstream> 限制它们。这允许您重新分支分支上的根提交。当与 --onto 一起使用时，它将跳过已包含在 <newbase>（而不是 <upstream> ）中的更改，而不使用 - 将在每次更改时运行。当与 --onto 和 --preserve-merges 一起使用时，<code>all</code>根提交将被重写为具有 <newbase> 作为父代。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--autosquash --no-autosquash</p></div></div><div class="doc-postil"><div class="c-markdown"><p>当提交日志消息以“squash！...”（或“fixup！...”）开始，并且存在一个标题以相同的开头的提交时，自动修改 rebase -i 的待办事项列表，以便提交标记为压扁，在提交被修改后立即出现，并将移动的提交的操作从（或）<code>pick</code>改为。在第一次之后忽略随后的“fixup！”或“squash！”，以防您提到之前的 fixup / squash 。<code>squashfixupgit commit --fixup/--squash</code></p></div></div><div class="doc-postil"><div class="c-markdown"><p>该选项仅在使用该<code>--interactive</code>选项时有效。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果该<code>--autosquash</code>选项默认情况下使用配置变量启用<code>rebase.autoSquash</code>，则此选项可用于覆盖和禁用此设置。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--autostash --no-autostash</p></div></div><div class="doc-postil"><div class="c-markdown"><p>在操作开始之前自动创建临时存储条目，并在操作结束后应用它。这意味着你可以在肮脏的工作树上运行 rebase 。但是，谨慎使用：成功重新绑定后的最终隐藏应用程序可能会导致不平凡的冲突。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>--no-ff</p></div></div><div class="doc-postil"><div class="c-markdown"><p>使用 -interactive ，cherry-pick 所有重新提交的提交，而不是对未更改的提交进行快速转发。这确保了重新分支的整个历史由新的提交组成。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>Without --interactive ，这是 --force-rebase 的同义词。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>在恢复主题分支合并之后，您可能会发现这很有帮助，因为此选项重新创建了具有新提交的主题分支，因此可以在不需要“还原返回”的情况下成功重新分配（请参阅<a href="https://git-scm.com/docs/howto/revert-a-faulty-merge.html" target="_blank">恢复 - 错误 - 合并的</a>方法细节）。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>合并策略</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>合并机制（<code>git merge</code>和<code>git pull</code>命令）允许<code>merge strategies</code>使用<code>-s</code>选项选择后端。一些策略也可以采取他们自己的选择，可以通过给<code>git merge</code>和/或<code>git pull</code>给出<code>-X<option></code>参数来传递。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>resolve</p></div></div><div class="doc-postil"><div class="c-markdown"><p>这只能使用3路合并算法来解析两个头（即当前分支和您从其中取出的另一个分支）。它试图仔细检测交叉融合歧义，并被认为通常是安全和快速的。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>recursive</p></div></div><div class="doc-postil"><div class="c-markdown"><p>这只能使用3路合并算法来解析两个头。当有多个可用于3路合并的共同祖先时，它将创建共同祖先的合并树并将其用作3路合并的参考树。据报道，这会导致更少的合并冲突，而不会因从 Linux 2.6内核开发历史记录中进行的实际合并提交所做的测试而导致混淆。此外，这可以检测并处理涉及重命名的合并。这是拉取或合并一个分支时的默认合并策略。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>该<code>recursive</code>策略可以采取以下选择：</p></div></div><div class="doc-postil"><div class="c-markdown"><p>ours</p></div></div><div class="doc-postil"><div class="c-markdown"><p>该选项强制冲突的 hunk 通过支持<code>our</code>版本自动解决。来自另一棵与我们不冲突的树的变化反映到合并结果。对于二进制文件，整个内容都是从我们这边拿来的。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>这不应与<code>ours</code>合并策略混淆，合并策略甚至不会考虑其他树包含的内容。它丢弃了其他树的所有内容，声明<code>our</code>历史包含发生在其中的所有事情。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>theirs</p></div></div><div class="doc-postil"><div class="c-markdown"><p>这是与<code>ours</code>相反的; 请注意，与此不同的<code>ours</code>是，没有<code>theirs</code>融合策略来混淆这个合并选项。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>patience</p></div></div><div class="doc-postil"><div class="c-markdown"><p>使用此选项，<code>merge-recursive</code>花费一点额外的时间来避免由于不重要的匹配行（例如，来自不同功能的括号）而导致的混淆。当要合并的分支疯狂地分歧时使用它。另请参阅 git-diff [1] <code>--patience</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>diff-algorithm=patience|minimal|histogram|myers</p></div></div><div class="doc-postil"><div class="c-markdown"><p>告诉<code>merge-recursive</code>使用不同的差异算法，这可以帮助避免由于不重要的匹配行（例如不同功能的花括号）而发生误合。另请参阅 git-diff [1] <code>--diff-algorithm</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>ignore-space-change ignore-all-space ignore-space-at-eol</p></div></div><div class="doc-postil"><div class="c-markdown"><p>为了三路合并的目的，将指定类型的空白的行对待不变。空白变化与其他变化混合在一起不会被忽略。另见 GIT-DIFF [1] ，<code>-b</code>，<code>-w</code>和<code>--ignore-space-at-eol</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>如果<code>their</code>版本只对一行引入空白变化，<code>our</code>则使用版本;</p></li><li><p>如果<code>our</code>版本引入空白变化，但<code>their</code>版本包含实质性更改，<code>their</code>则使用版本;</p></li><li><p>否则，合并按照通常的方式进行。</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><p>renormalize</p></div></div><div class="doc-postil"><div class="c-markdown"><p>这将在解析三路合并时运行虚拟检出和检入文件的所有三个阶段。此选项用于合并具有不同干净过滤器或行结束标准化规则的分支时使用。有关详细信息，请参阅 gitattributes [5]中的“合并不同签入/签出属性的分支”。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>no-renormalize</p></div></div><div class="doc-postil"><div class="c-markdown"><p>禁用该<code>renormalize</code>选项。这覆盖<code>merge.renormalize</code>配置变量。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>no-renames</p></div></div><div class="doc-postil"><div class="c-markdown"><p>关闭重命名检测。另请参阅 git-diff [1] <code>--no-renames</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>find-renames=<n></p></div></div><div class="doc-postil"><div class="c-markdown"><p>打开重命名检测，可选择设置相似性阈值。这是默认设置。另请参阅 git-diff [1] <code>--find-renames</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>rename-threshold=<n></p></div></div><div class="doc-postil"><div class="c-markdown"><p>已弃用的同义词<code>find-renames=<n></code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>subtree=<path></p></div></div><div class="doc-postil"><div class="c-markdown"><p>该选项是一种更高级的<code>subtree</code>策略形式，该策略可以猜测两个树在合并时必须如何移动以相互匹配。相反，指定的路径是前缀（或从开始剥离）以使两棵树的形状匹配。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>octopus</p></div></div><div class="doc-postil"><div class="c-markdown"><p>这解决了两个以上负责人的情况，但拒绝执行需要手动解决的复杂合并。它主要用于将主题分支主题捆绑在一起。这是拉取或合并多个分支时的默认合并策略。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>ours</p></div></div><div class="doc-postil"><div class="c-markdown"><p>这可以解析任意数量的头，但合并结果树始终是当前分支头的树，有效地忽略了来自所有其他分支的所有更改。它是用来取代侧枝的旧发展历史。请注意，这与<code>recursive</code>合并策略的 -Xours 选项不同。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>subtree</p></div></div><div class="doc-postil"><div class="c-markdown"><p>这是一个修改后的递归策略。当合并树 A 和 B 时，如果 B 对应于 A 的子树，则首先调整 B 以匹配 A 的树结构，而不是读取处于相同级别的树。这种调整也对共同的祖先树进行。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>对于使用3路合并（包括默认值<code>recursive</code>）的策略，如果在两个分支上进行了更改，但稍后在其中一个分支上进行了恢复，则该更改将出现在合并结果中; 有些人觉得这种行为很混乱。这是因为在执行合并时仅考虑头部和合并基础，而不是个别提交。因此，合并算法将恢复的更改视为完全没有更改，而是替换更改的版本。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>Notes</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>您应该了解在<code>git rebase</code>共享的存储库上使用的含义。请参阅下面的“从上游重新启动”中恢复。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>当 git-rebase 命令运行时，它会首先执行一个 “pre-rebase” 挂钩（如果存在）。您可以使用此挂钩进行健全性检查，并在不合适的情况下拒绝 rebase 。有关示例，请参阅模板 pre-rebase 挂钩脚本。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>完成后，<branch> 将成为当前分支。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>交互模式</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>交互式重新定位意味着您有机会编辑重新提交的提交。您可以对提交进行重新排序，并且可以将其删除（清除不良或其他不需要的修补程序）。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>交互模式适用于这种类型的工作流程：</p></div></div><div class="doc-postil"><div class="c-markdown"><ol class="ol-level-0 list-paddingleft-2"><li><p>有一个奇妙的想法</p></li><li><p>破解代码</p></li><li><p>准备一系列提交</p></li><li><p>提交</p></li></ol></div></div><div class="doc-postil"><div class="c-markdown"><p>point 2. 由几个实例组成</p></div></div><div class="doc-postil"><div class="c-markdown"><p>a）常规使用</p></div></div><div class="doc-postil"><div class="c-markdown"><ol class="ol-level-0 list-paddingleft-2"><li><p>完成值得一提的东西</p></li><li><p>递交</p></li></ol></div></div><div class="doc-postil"><div class="c-markdown"><p>b）独立修复</p></div></div><div class="doc-postil"><div class="c-markdown"><ol class="ol-level-0 list-paddingleft-2"><li><p>意识到某些事情不起作用</p></li><li><p>解决该问题</p></li><li><p>提交它</p></li></ol></div></div><div class="doc-postil"><div class="c-markdown"><p>有时候在 b.2 中固定的东西。不能修改为它所修复的不完美的提交，因为该提交深深地埋入了补丁系列中。这正是交互式底座的用途：在大量的 “a” 和 “b” 之后使用它，重新安排和编辑提交，并将多个提交压缩成一个。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>按照原样保留的最后一次提交启动它：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">git rebase -i <after-this-commit></pre></div></div><div class="doc-postil"><div class="c-markdown"><p>编辑器将会触发当前分支中的所有提交（忽略合并提交），这些提交会在给定的提交之后提交。您可以将此列表中的提交重新排序，直至您的内容为准，并且可以将其删除。该列表看起来或多或少像这样：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">pick deadbee The oneline of this commit
|
||
|
||
pick fa1afe1 The oneline of the next commit...</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>在线描述纯粹是为了乐趣; <code>git rebase</code>将不会看到它们，而是以提交名称（本例中为 “deadbee” 和 “fa1afe1” ），因此不要删除或编辑名称。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>通过使用命令 “edit” 替换命令 “pick” ，您可以告诉<code>git rebase</code>在应用该提交后停止，以便您可以编辑文件和/或提交消息，修改提交并继续重新绑定。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果您只想编辑提交的提交消息，请将命令 “pick” 替换为 “reword” 命令。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>要删除提交，请将 “pick” 命令替换为 “drop” ，或者只删除匹配的行。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果要将两个或多个提交合并为一个，请将第二个提交和后续提交的命令替换为 “squash ”或 “fixup” 。如果提交具有不同的作者，则折叠提交将归于第一次提交的作者。对于已提交的提交，建议的提交消息是第一次提交的提交消息和那些使用 “squash” 命令的提交消息的连接，但省略了使用 “fixup” 命令提交的提交消息。</p></div></div><div class="doc-postil"><div class="c-markdown"><p><code>git rebase</code>将 “pick” 替换为 “edit” 或由于合并错误而导致命令失败时停止。当您完成编辑和/或解决冲突时，您可以继续<code>git rebase --continue</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>例如，如果您想重新排序最后5次提交，那么 HEAD〜4会 成为新的 HEAD 。要达到这个目标，你可以这样调用<code>git rebase</code>：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">$ git rebase -i HEAD~5</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>并将第一个补丁移动到列表的末尾。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果您有这样的历史记录，您可能想要保留合并：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> X
|
||
|
||
\
|
||
|
||
A---M---B /---o---O---P---Q</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>假设你想重新分支从 “A” 开始到 “Q” 的分支。确保当前 HEAD 是 “B” ，然后调用</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">$ git rebase -i -p --onto Q O</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>重新排序和编辑提交通常会创建未经测试的中间步骤。您可能需要检查历史编辑是否通过运行测试，或至少使用 “exec” 命令（快捷方式 “x” ）在历史中间点重新编译来破坏任何内容。你可以通过创建一个像这样的待办事项列表来实现：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">pick deadbee Implement feature XXX
|
||
|
||
fixup f1a5c00 Fix to feature XXX
|
||
|
||
exec make
|
||
|
||
pick c0ffeee The oneline of the next commit
|
||
|
||
edit deadbab The oneline of the commit after
|
||
|
||
exec cd subdir; make test...</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>当命令失败时（即以非0状态退出），交互式重新分配将停止，让您有机会解决问题。你可以继续<code>git rebase --continue</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>“exec” 命令会在 shell 中启动该命令（在中指定的命令<code>$SHELL</code>或默认 shell ，如果<code>$SHELL</code>未设置），因此您可以使用 shell 功能（如“cd”，“>”，“;”...）。该命令从工作树的根目录运行。</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">$ git rebase -i --exec "make test"</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这个命令让你检查中间提交是否可编译。待办事项列表如下所示：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">pick 5928aea one
|
||
|
||
exec make test
|
||
|
||
pick 04d0fda two
|
||
|
||
exec make test
|
||
|
||
pick ba46169 three
|
||
|
||
exec make test
|
||
|
||
pick f4593f9 four
|
||
|
||
exec make test</pre></div></div><div class="doc-postil"><div class="c-markdown"><h2>分割提交</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>在交互模式下，您可以使用“编辑”操作标记提交。但是，这并不一定意味着<code>git rebase</code>期望这个编辑的结果恰好是一个提交。事实上，您可以撤销提交，也可以添加其他提交。这可以用来将提交分成两部分：</p></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>开始一个交互式重新绑定<code>git rebase -i <commit>^</code>，其中 <commit> 是您要分割的提交。实际上，只要包含该提交，任何提交范围都会执行。</p></li><li><p>使用“编辑”操作标记要分割的提交。</p></li><li><p>当编辑提交时，执行<code>git reset HEAD^</code>。其效果是 HEAD 被倒回1，并且索引也随之而来。但是，工作树保持不变。</p></li><li><p>现在将更改添加到您想要在第一次提交中使用的索引中。您可以使用<code>git add</code>（可能交互式）或<code>git gui</code>（或两者）来做到这一点。</p></li><li><p>使用现在适合的提交消息提交当前的索引。</p></li><li><p>重复最后两个步骤，直到你的工作树干净。</p></li><li><p>继续与<code>git rebase --continue</code>的 rebase 。</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><p>如果您不确定中间修订是否一致（它们会进行编译，通过测试套件等），您应该使用<code>git stash</code>它在每次提交，测试和修改提交（如果需要修复）后保留尚未提交的更改。</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>从上游的 rebase 恢复</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>其他人基于工作的分支（或任何其他形式的重写）是一个坏主意：它下游的任何人都被迫手动修改其历史记录。本节介绍如何从下游角度进行修复。然而，真正的解决办法是避免重新摆放上游。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>为了说明，假设你处于某人开发<code>subsystem</code>分支的情况，并且你正在研究一个<code>topic</code>依赖于此的分支<code>subsystem</code>。你可能会得到如下的历史记录：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> o---o---o---o---o---o---o---o master
|
||
|
||
\
|
||
|
||
o---o---o---o---o subsystem
|
||
|
||
\ *---*---* topic</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>如果<code>subsystem</code>重新发放<code>master</code>，会发生以下情况：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> o---o---o---o---o---o---o---o master
|
||
|
||
\ \
|
||
|
||
o---o---o---o---o o'--o'--o'--o'--o' subsystem
|
||
|
||
\ *---*---* topic</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>如果你现在继续开发像往常一样，并最终合并<code>topic</code>到<code>subsystem</code>，从提交<code>subsystem</code>会永远保持复制：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> o---o---o---o---o---o---o---o master
|
||
|
||
\ \
|
||
|
||
o---o---o---o---o o'--o'--o'--o'--o'--M subsystem
|
||
|
||
\ / *---*---*-..........-*--* topic</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>这些重复的东西通常会被忽视，因为它们混淆了历史，使其难以遵循。为了清理，你需要将提交移植<code>topic</code>到新的<code>subsystem</code>提示中，即 rebase <code>topic</code>。这变成了一种连锁反应：下游的任何人<code>topic</code>都被迫变质，等等！</p></div></div><div class="doc-postil"><div class="c-markdown"><p>有两种修复方法，将在以下小节中讨论：</p></div></div><div class="doc-postil"><div class="c-markdown"><p>简单案例：这些变化字面上是相同的。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果这个<code>subsystem</code> rebase 是一个简单的 rebase 并且没有冲突，就会发生这种情况。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>困难的情况：变化是不一样的。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>如果<code>subsystem</code> rebase 有冲突或者用于<code>--interactive</code>忽略，编辑，挤压或修改提交，就会发生这种情况; 或者如果上游使用的一个<code>commit --amend</code>，<code>reset</code>或<code>filter-branch</code>。</p></div></div><div class="doc-postil"><div class="c-markdown"><h3>简单的情况</h3></div></div><div class="doc-postil"><div class="c-markdown"><p>只有<code>subsystem</code>在 rebase <code>subsystem</code>之前和之后的变化（基于 diff 内容的补丁ID）字面上相同时才有效。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>在这种情况下，修复很容易，因为<code>git rebase</code>知道跳过已经存在于新上游的变化。所以如果你说（假设你在<code>topic</code>）</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> $ git rebase subsystem</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>你会以固定的结果结束</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> o---o---o---o---o---o---o---o master
|
||
|
||
\
|
||
|
||
o'--o'--o'--o'--o' subsystem
|
||
|
||
\ *---*---* topic</pre></div></div><div class="doc-postil"><div class="c-markdown"><h3>困难的情况</h3></div></div><div class="doc-postil"><div class="c-markdown"><p>如果这些<code>subsystem</code>变化与 rebase 之前的变化不完全一致，事情会变得更加复杂。</p></div></div><div class="doc-postil"><div class="c-markdown"><div class="table-wrapper"><table><thead><tr class="firstRow"><th style="text-align: left;"><div class="table-header"><p>Note</p></div></th><th style="text-align: left;"><div class="table-header"><p>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 git rebase --interactive will be resurrected!</p></div></th></tr></thead><tbody></tbody></table></div></div></div><div class="doc-postil"><div class="c-markdown"><p>这个想法是手动告诉<code>git rebase</code>“旧的<code>subsystem</code>结局和你的<code>topic</code>开始”，也就是说，他们之间的旧合并基础是什么。您必须找到一种方法来命名旧的最后一次提交<code>subsystem</code>，例如：</p></div></div><div class="doc-postil"><div class="c-markdown"><ul class="ul-level-0 list-paddingleft-2" style="margin: 10px 0px 10px 20px;"><li><p>随着<code>subsystem</code> reflog：之后<code>git fetch</code>，旧的一角<code>subsystem</code>是在<code>subsystem@{1}</code>。后续提取将增加数量。（请参阅 git-reflog [1]。）</p></li><li><p>相对于提示<code>topic</code>：知道你<code>topic</code>有三次提交，旧的提示<code>subsystem</code>必须是<code>topic~3</code>。</p></li></ul></div></div><div class="doc-postil"><div class="c-markdown"><p>然后你可以<code>subsystem..topic</code>通过说（对于 reflog 的情况，并假设你已经<code>topic</code>），将旧的移植到新的提示中：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> $ git rebase --onto subsystem subsystem@{1}</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>“硬性案例”恢复的连锁反应特别糟糕：<code>everyone</code>下游<code>topic</code>将不得不进行“硬性案例”恢复！</p></div></div><div class="doc-postil"><div class="c-markdown"><h2>Bugs</h2></div></div><div class="doc-postil"><div class="c-markdown"><p>提供的待办事项列表<code>--preserve-merges --interactive</code>不代表修订图的拓扑结构。编辑提交和重新提交它们的提交消息应该可以正常工作，但尝试重新排序提交往往会产生违反直觉的结果。</p></div></div><div class="doc-postil"><div class="c-markdown"><p>例如，尝试重新排列</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">1 --- 2 --- 3 --- 4 --- 5</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>至</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript">1 --- 2 --- 4 --- 3 --- 5</pre></div></div><div class="doc-postil"><div class="c-markdown"><p>通过移动 “pick 4” 行，将导致以下历史记录：</p></div></div><div class="doc-postil"><div class="c-markdown"><pre class="prism-token token language-javascript"> 3 /1 --- 2 --- 4 --- 5</pre></div></div></div> |