标签: git-interactive-rebase

我试图将我的主仓库中的所有提交压缩到我的分支内的一个提交.我这样做是因为主分支是从我们无法控制的远程仓库中提取的,而有问题的分支被拉/推到我们自己的远程git仓库(Atlassian Stash).我这样做是因为我真的不想要或不关心主分支的所有提交历史.

我开始使用整个过程git rebase --root -i,在交互式部分中我选择重新编写第一个提交并修复其余部分(大约有16000个提交)

现在在进程的中间,rebase经常遇到冲突,如果甚至一半的提交导致冲突,手动选择接受他们的冲突将花费很长时间.

因此,当由于冲突而停止rebase过程时,是否可以将合并策略更改为始终接受它们？

我最近安装了Vim.现在,当我以交互模式重新分支我的分支时,Git会自动打开Vim.

但是,我不想以交互模式打开Vim; 相反,我想打开默认的Git交互模式编辑器.如何设置Git使用的默认交互式编辑器？

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

例如，在此图中：

5bab4818e (HEAD -> cell-toggle-comp) Added cell-toggle component
d55cab881 (toggle-comp) Toggle: Added honey traceability comment
4240f0ac3 Made Toggle a named export and replaced references to obsolete <ui> alias
90a0b2452 Refactored Switch instances to toggle
e15c758a0 Updated Switch component to latest specs (and renamed things to match design lingo)
d53090e93 (fix-switch-reference) Fixed Switch reference that was being imported from React Native instead of src/components
4a214cb72 (cell-text-selection-comp) Added CellTextSelection ui component
cef3b5716 (origin/master, origin/HEAD, master) …

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

更长的版本：

背景

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

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

从选项列表中：

#  e, edit = use commit, but stop for amending

问题

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

动机/用例

例如，如果我想压缩一系列提交，然后停止进行一些手动操作，我必须将编辑 + 压缩放在同一个提交 ID 前面 - 这是不允许的。

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

pick COMMIT_0 Change some colors
pick COMMIT_1 Make it faster
squash COMMIT_2 Fix a typo in previous commit
squash COMMIT_3 Fix another typo in previous commit
edit
pick COMMIT_4 Refactor some things
pick …

为什么 git rebase -i 最近会导致头部分离？它曾经用交互式变基的结果来更新我当前的分支。如何获得交互式变基以停止进入分离的 HEAD？

在从远程存储库拉取之前，我总是使用 git rebase -i 来压缩我的提交，以简化处理 git pull 中的任何合并冲突。我不必解决可能多个提交的冲突，而只需解决一个提交。

我使用的示例命令

# git rebase -i <tip of public branch> <my latest commit>
git rebase -i 380647533da 82f5ee67bed

在 vim 中编辑 rebase 交互后：

pick 3ec7c211c49 version1
s 82f5ee67bed some significant refactoring

编辑并保存提交后的输出：

[detached HEAD ea50304796c] version1
 Date: Thu Jun 6 17:04:36 2019 -0400
 14 files changed, 213 insertions(+), 52 deletions(-)
 create mode 100644     some file
 create mode 100644     some file
 create mode 100644     some file
Successfully rebased …

我正在进行交互式变基，并且已经修改了几个提交

我有几个剩余的提交已标记为编辑，但我决定不再编辑它们

我怎样才能结束变基（如果愿意的话，尽早结束）但保留迄今为止所做的更改？

git rebase --abort将结束变基并删除我所做的所有更改，并且git rebase --continue对于我必须编辑的每个剩余提交进行键入太乏味

在Git中，我可以使用交互式的基础来重写历史记录，这很棒，因为在我的功能分支中，我探索了不同的重构和完成方式时，使用部分有效的代码进行了大量提交。

在将分支重新合并或合并到master之前，我想将很多提交压缩在一起。

一些按从上到下的顺序排列提交

1. Initial commit on feature branch "Automatic coffee maker UI"
2. Add hot chocolate as product
3. Add tea as product. Products are now generic
4. Create in memory data store for adapter tests
5. Cry because I can't get entity framework to create a composite key. Integration tests broken.
6. Implemented composite key!!
7. All tests green and feature done!

假设我要保留提交3、4和7。

使用变基我想“压扁”提交

• 1和2进入3。
• 4宿
• 5和6进入7

理想情况下，我会在交互式基础中执行

1. squash
2. squash
3. pick (contains the work …

我已经执行了以下合并：

A---B---C---E (HEAD, merge of C and D)
           /
      D---|

但我注意到E中的一些问题，并在F中修复了它们：

A---B---C---E---F (HEAD)
           /
      D---|

我想修改提交，E以便它包含F.

当我尝试时git rebase -p -i HEAD~2，它会尝试创建常规（非合并）提交，甚至尝试让我重新解决在执行合并时已经解决的冲突E。

如何修复提交E，使其包含中所做的更改F？

我正在尝试交互式变基。假设我有一个有 6 次提交的线性主分支，并且 HEAD 位于第 6 次提交，并且我运行 git rebase -i HEAD~4 那么它允许我选择/编辑/拆分/压缩 HEAD 和最后 3 次提交。

一旦我执行任何操作并完成变基操作，它就会重播 HEAD~4 之上的提交。现在，它们有了新的提交 ID，并且头指向最近（选择的）提交。

我想知道原始提交到底发生了什么？是否被删除，是否可以恢复？

所以我遇到了这种奇怪的情况。

我正在对 4 次提交进行交互式变基。我尝试挤压，但我做错了，出现以下错误：

error: cannot 'squash' without a previous commit You can fix this with
'git rebase --edit-todo' and then run 'git rebase --continue'. Or you
can abort the rebase with 'git rebase --abort'.

我决定运行git rebase --edit-todo，当我这样做时，只出现了最后一次提交。我将其从 更改为squash，pick然后运行git rebase --continue，但现在看来我试图压缩的其他 3 个提交已经不存在了。
所以我早上的工作似乎失败了。
一定有办法恢复这些，对吗？
我该怎么做？

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

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

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

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

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

如果不共享完整的存储库，这个问题有点难以描述，但我会尝试。

我意识到我在最后一次提交中犯了一个错误。我决定使用交互式变基来修复它。

git rebase -i @~~

现在我进入 Vim，在其中更改第一行中的命令：

pick 80c90b55788 First commit message  <-- change 'pick' to 'edit'
pick 712be094f96 Second commit message

Git 响应如下：

Stopped at 80c90b55788...  First commit message
You can amend the commit now, with
    git commit --amend 
Once you are satisfied with your changes, run
    git rebase --continue

我修改了需要修复的发现（我删除了有问题的行）。然后我继续：

git add <file>
git commit --amend
git rebase --continue

现在 git 检测到我编辑的文件中存在冲突。（连续的两行被删除 - 一行最初是在第二次提交中，另一行是我在上一步中删除的。）对我来说，这一步看起来是多余的，因为 Git 基本上做了正确的事情 - 它已经正确合并了更改。但它正在等待我上演改变。

在不对文件进行任何修改的情况下，我再次执行以下操作：

git add <file>
git commit --amend
git rebase …