Question

在Git中，当我提交时，例如。 A - B - C我希望编辑B提交，我

使用git rebase -i <A-commit-hash>，
我在edit commit，

B

git rebase在B提交后立即停止，因此我可以使用git commit --amend修复我想要的任何内容，
然后我继续使用git rebase --continue。

据我所知，这是如何做到这一点的最佳做法。使用这种方法，我可以编辑过去的任何提交（只要它还没有被推送到远程分支），而且使用-p标志我甚至可以保留合并。这真是太棒了。

我目前的问题是：我在合并提交中的一行上犯了一个错误（拼写错误）（在合并两个分支时解决了冲突）。

我想解决它，但我不知道如何让git rebase停止合并提交。 git rebase -p -i <blah>列表忽略了合并提交，因此我无法在其前面编写edit命令，并让git rebase停在那里让我编辑它。

请帮忙吗？我只是想在合并提交中修复这一行，同时保留它之后的所有提交（和合并）。

感谢。

Answer 1

当涉及合并时，Git不容易进行交互式rebase。 -p选项在内部使用-i机制，因此将两者混合起来并不起作用。

然而，git rebase只是一种自动化的方式来做很多挑选。您可以通过手动挑选来复制其行为，以获得对该过程的更多控制。它不太方便，更容易出现人为错误，但可能。

这是我建议的方法：

使用git rebase在合并之后进入提交（合并的子代）

使用git reset --hard HEAD^手动进入合并

使用git commit --amend修复合并

使用git cherry-pick返回合并后的提交

使用git rebase --continue完成

以下是具体步骤：

请注意要修改的合并提交的SHA1 ID。有关讨论，请假设它是deadbeef。

在要修改的合并提交（合并提交的子项）之后，请注意提交的SHA1 ID。假设它是facef00d。

运行git rebase -i deadbeef。

选择facef00d进行修改。

当rebase返回编辑facef00d的提示时，请运行git reset --hard HEAD^。您现在应该在deadbeef（git rev-parse HEAD应该打印deadbeef）。

进行修改以修复错误的合并冲突，并使用git add进行投放。

运行git commit --amend以使用错误的合并提交融合分阶段修复。结果现在将具有不同的SHA1（不是deadbeef）。

运行git cherry-pick facef00d以将facef00d所做的更改应用于固定合并提交。

运行git rebase --continue完成。

Answer 2

现在，使用Git 2.22及更高版本中的--- title: "**my really really really really <br> really really long title**" author: "person" date: "4/24/2020" output: html_document: toc: true toc_float: collapsed: true smooth_scroll: false toc_depth: 4 theme: yeti highlight: tango code_folding: show ---选项可以轻松得多。此选项保留合并拓扑，并与交互式基础一起使用。

假设navigationItem.rightBarButtonItem?.isEnabled = true navigationItem.rightBarButtonItem = UIBarButtonItem(title: "CLOSE", style: .done, target: self, action: #selector(handleRightBarButton)) @objc handleRightBarButton() { //Hide function here? }是要修改的合并提交，它将看起来像这样：

--rebase-merges

您现在可以在B和label onto ... some branch definitions ... reset onto merge -C B branch-name # Merge branch 'B' into whatever pick C之间插入b（或break）：

merge

在pick中断时合并，然后继续进行变基。

这也适用于修正提交。例如，假设合并修复的提交为merge -C B branch-name # Merge branch 'xyz' into whatever break pick C。您可以将合并提交后的修订提交D移至以下位置：

commit --amend

请参见git-merge手册页的Rebasing Merges部分。

Answer 3

可能更容易创建修正提交＆＃39; D＆＃39;然后使用＆＃39; buildVersion＆＃39;重新排序＆＃39; D＆＃39;紧接着＆＃39; B＆＃39;并将其压入＆＃39; B＆＃39;。

function appendPosters() {
    $('li').each(function () {
        var $handler = $(this);
        var imdbId = $(this).parent().attr('href').substr(26, 9);
        getresponse($handler, $handler.parent().attr('href').substr(26, 9), function (data) {
        });
    });
}

function getresponse($handler, imdbId, callback) {
    $.getJSON('http://www.omdbapi.com/?i=' + imdbId).then(function (response) {
        var poster = response.Poster;
        console.log(poster);
        var img = $('<img>'); //Equivalent: $(document.createElement('img'))
        img.attr('src', poster);
        img.appendTo($handler);
        callback(true);
    });
}

Answer 4

tl;dr： 有时您根本不应该使用 git rebase 来编辑合并提交。另一种方法可能更有效。

我刚刚经历过一个这样的场景：我有一个合并提交，它正在一个非常旧的分支中合并，并且在合并提交中解决了许多冲突。合并后有一些额外的提交，然后发现在一个文件的冲突解决期间在大合并提交中犯了错误。我按照接受的答案中的描述设置了交互式 rebase，但是当我的机器在 2/59 锁定时，我意识到由于重新组织我的文件系统以匹配旧的文件系统，它正在写入很多文件分支。几分钟后我杀死了它，中止了 rebase，然后不得不删除 100K 文件才能回到我开始的地方。我没有变基，而是这样做了：

记下我在修复合并提交后要重播的提交 ID。
git reset --hard [merge-commit-id]
进行更改并简单地修改 HEAD 提交（即合并提交）。
在合并提交后按顺序挑选每个提交 ID，或者使用带有 3 个参数的 git rebase --onto 挑选整个范围（如果有多个）。

这快了。

使用git rebase编辑合并提交

4 个答案: