问题标签 [git-interactive-rebase]

我已将 VSCode 设置为我的 git 编辑器，详见此处。

当我尝试这样做时：git rebase HEAD~3 -i它会打开一个新的代码窗口，并且一旦交互式变基 VSCode 窗口关闭包含触发命令的终端的窗口，就会开始进行变基。

据我所知，编辑器需要触发错误代码以中止变基。

我不确定在 VSCode 中是否有办法做到这一点，或者我是否需要在他们的 git 存储库上打开问题/增强功能？或者您是否应该清除所有行然后关闭它应该是相同的？这会中止吗？

我正在帮助将一个长期运行的项目集成回主线。想要回归的功能分支之一本身就是许多其他“迷你功能”分支的章鱼合并（不是单个章鱼合并，而是随着时间的推移进行的多次合并）。

这些迷你功能分支中的每一个都散布在其独特的内容中，一组共同的提交被精心挑选到每个相应的迷你功能分支中。我想在合并回主线之前清理所有这些常见的提交。

可能相关的是功能分支的当前状态是“正确的”，即代码的外观是它应该看起来的样子。

我尝试过的选项：

1. 直截了当rebase -i：导致了很多冲突，可能是因为樱桃挑选已应用于多个迷你功能分支并已解决
2. rebase -i -p：这导致完全相同的分支结构与重复的常见提交

在正常情况下，我会简单地挥动投降的白旗并进行壁球合并。但是，我需要做的是用一组新的和改进的常见提交替换这些常见提交——这表明 rebase 是最合适的继续方式。

理想的做法是使用rebase -i冲突解决策略，尝试通过选择使结果看起来最像最终目标（当前章鱼特征分支）的冲突选项来解决冲突。但我不知道如何告诉 git 这样做。

我的问题：

1. 有什么方法可以告诉 git 以上述方式解决冲突吗？
2. 有没有更好、更清洁的方法来实现我的目标？
3. 我是否愿意使用 rebase 手动重建这些迷你功能分支？

我有以下屏幕，需要必要的命令来合并 2 个提交。

在 rebase 期间，我将本地功能分支同步到上游分支以完成拉取请求，我尝试使用所有三种方法（git rebase、git rebase -i 和 git merge），它们中的每一个都提供了完全不同的体验，当到了解决冲突的问题。

Git 合并一次向我展示了我所有的冲突。我解决了它们，并在解决所有问题后添加了更改。正如预期的那样，合并搞砸了我的历史，我不得不再次恢复。

Git Rebase 分两步引导我解决冲突。在每一个中，我都添加了我的更改，然后继续进行变基。在这期间，我丢失了一个补丁，不得不重新开始。

交互式变基就像一个魅力。它引导我通过提交提交的冲突，并且在每次解决之后，它再次开始从功能分支的基础快速转发到下一个冲突。我可以确保正确地包含提交的共同作者，最后甚至不需要添加“合并”或“变基”提交，完成后坐在分支的头部。

我对何时使用它们中的每一个都有一个概念性的理解，但为什么即使没有交互式编辑修订，rebase 和交互式 rebase 的行为也会如此不同？为什么 git merge 和 git rebase 甚至被使用，当它们似乎做得很糟糕并且更容易在历史上搞砸一些事情时？

我想在提交消息的中间插入换行符，同时在交互式 rebase 中重新编写它们。我怎样才能做到这一点？

我使用 Notepad++ 作为交互式 rebase 的外部编辑器。

在处理我的功能分支时，我不断地对它们进行重新排序和压缩，git rebase -i以保持我的历史版本更清晰。有时我会处理多个相互依赖的特性（我团队的规则是让 PR 尽可能小，因此较大特性的一个原子块通常会成为它自己的特性分支）。由于这个工作流程，我通常最终在重新定位分支后手动重新指向分支。有没有办法自动将这些指针移动到它们应该降落的位置？

因此，例如，在此图中：

假设我想交换提交e15c758a0和d53090e93，但我希望fix-switch-reference分支与它的提交一起移动。有没有办法自动做到这一点？还是我必须移动提交，然后手动将分支指向新的哈希？

每次我认为我是一个 Git 向导时，都会发生一些全新而奇怪的事情让我回到原来的位置......

我正在一个交互式 rebase 中压缩两个提交，突然间，来自 Git 的输出开始像覆盖自己一样，并且多个 Git Bash 提示出现在混乱中，好像命令认为它们在实际完成之前就已经完成（可惜忘记截图了）。我的回购现在似乎已经损坏，因为我陷入了REBASE-i模式并且无法中止。下面是一些屏幕截图，希望能帮助解决更多的 Git-wizardry-than-I 问题（git s是 的别名git status）。我以前从未见过该Cannot store消息，而且我不明白它是如何由rebase. 我总是可以删除回购并制作一个新的克隆，但我想我会在放弃之前向 SO 提出上诉......

编辑：
这是我导致此问题的步骤：

1. git commit --squash head这样我就可以用之前的提交来压缩我的最新更改。
2. git rebase -i --autosquash head^^squash使用已设置的命令启动交互式变基。
3. 变基正常进行，但随后开始显示上述奇怪的输出。它开始抱怨无法取消链接.pack文件，如果我想再试一次。我以前看过那条消息；通常它只是一直要求永远重试，所以我退出了Ctrl+C.
4. 那时，我无法git rebase --abort使用下面显示的错误消息。
5. 我尝试git rebase --edit-todo并删除了 todo 文件的所有行，但 rebase 继续失败。
6. 最后我跑了git rebase --continue，它让我脱离了REBASE-i模式，让我在非常慌乱的状态下继续我的生活......

版本信息：
- 适用于 Windows 的 Git：2.18.0
-Windows：Windows 10 Pro 1803

我编写了一个脚本来自动git rebase --interactive编辑指定的提交，使用GIT_SEQUENCE_EDITOR=sed ...s/pick/edit/...

如何防止git rebase --interactive打印出“有用的”消息：

这条消息被打印到 STDERR，我仍然想查看rebase命令本身和/或任何{pre,post}-rebase钩子的任何错误，所以 2>/dev/null不是一个选项。

从git config 文档中，我尝试过：

git -c advice.statusHints=false rebase --quiet --interactive --autostash --autosquash "$commit"~

我也试过禁用advice.resolveConflictand advise.detachedHead。

下似乎没有任何有用的选项 rebase.*。

当我这样做时git rebase <base-commit>，我看到.git/rebase-apply创建的目录包含文件onto、、orig-head和original-commit、引用<base-commit>、head和分别应用的当前提交。

当我这样做时git rebase -i <base-commit>，我会看到.git/rebase-merge包含文件onto、、orig-head和的目录stopped-sha，其中stopped-sha似乎等同于original-commit.

我的问题是为什么交互式和非交互式 rebase 之间的文件和目录命名存在差异？我对文件的理解是否正确？

(TLDR) 有没有办法在git rebase -i没有提交 ID 的情况下停止编辑？(/TLDR)

更长的版本：

背景

使用git rebase -i，我得到一个文本编辑器，我可以在其中定义一个命令列表，从pick COMMIT_ID每一行开始。

其中一个选项是将“pick COMMIT_ID”替换为“edit COMMIT_ID”，这意味着它将在提交后停止，以便我修改提交或进行一些手动操作。然后我可以继续git rebase --continue。

从选项列表中：

问题

我想知道是否可以选择停止编辑，而不选择任何提交。

动机/用例

例如，如果我想压缩一系列提交，然后停止一些手动操作，我将不得不将 edit + squash 放在同一个提交 id 的前面——这是不允许的。

相反，我会做这样的事情：

这样的选项还允许在序列中的第一次提交之前停止。

（我要说它允许在整个历史的初始提交之前进行编辑，但这不是真的 - 初始提交永远不是变基序列的一部分）

如果我这样做，git 会这样说：

警告：SHA-1 丢失或不是以下行中的提交：

有趣的是，效果或多或少是我想要的，它停下来，我可以做事。但我确信这不是预期的方式。