问题标签 [git-rebase]

有人知道如何轻松撤消 git rebase 吗？

想到的唯一方法是手动进行：

• git checkout 两个分支的提交父级
• 然后从那里创建一个临时分支
• 手工挑选所有提交
• 用手动创建的分支替换我重新设置的分支

在我目前的情况下，这将起作用，因为我可以轻松地发现来自两个分支的提交（一个是我的东西，另一个是我同事的东西）。

然而，我的方法给我的印象是次优且容易出错（假设我刚刚用我自己的 2 个分支重新设置了基础）。

有任何想法吗？

澄清：我说的是重放一堆提交的rebase。不止一个。

假设您有一个包含三个提交A、B和C的历史记录：

我想将两个提交A和B合并为一个提交AB：

我试过

这将打开我的编辑器，其中包含以下内容：

我把它改成

然后 Git 1.6.0.4 说：

有没有办法或者这是不可能的？

几个月来，我和其他开发人员一起在一个项目中使用了 Git。我有几年的SVN经验，所以我想我给这段关系带来了很多包袱。

我听说 Git 非常适合分支和合并，但到目前为止，我还没有看到它。当然，分支非常简单，但是当我尝试合并时，一切都变得糟糕透顶。现在，我已经习惯了 SVN，但在我看来，我只是将一个低于标准的版本控制系统换成了另一个。

我的搭档告诉我，我的问题源于我想随意合并的愿望，并且在许多情况下我应该使用 rebase 而不是合并。例如，这是他制定的工作流程：

本质上，创建一个特性分支，总是从主分支变基到分支，然后从分支合并回主分支。需要注意的重要一点是，分支始终保持在本地。

这是我开始的工作流程

有两个本质区别（我认为）：我总是使用合并而不是变基，并且我将我的功能分支（和我的功能分支提交）推送到远程存储库。

我对远程分支的推理是我希望在工作时备份我的工作。我们的存储库会自动备份，如果出现问题可以恢复。我的笔记本电脑没有，或者没有那么彻底。因此，我讨厌在我的笔记本电脑上有没有在其他地方镜像的代码。

我对合并而不是 rebase 的理由是，merge 似乎是标准的，而 rebase 似乎是一个高级功能。我的直觉是我想做的不是高级设置，所以 rebase 应该是不必要的。我什至仔细阅读了关于 Git 的新实用程序设计书，它们广泛地涵盖了合并，几乎没有提到变基。

无论如何，我在最近的一个分支上遵循我的工作流程，当我试图将它合并回 master 时，一切都变得糟糕透顶。与本应无关紧要的事情发生了很多冲突。这些冲突对我来说毫无意义。我花了一天的时间整理一切，最终以强制推送到远程 master 达到高潮，因为我的本地 master 已经解决了所有冲突，但远程 master 仍然不高兴。

像这样的“正确”工作流程是什么？Git 应该让分支和合并变得超级容易，而我只是没有看到它。

2011-04-15 更新

这似乎是一个非常受欢迎的问题，所以我想我会用我第一次问起的两年经验来更新。

事实证明，最初的工作流程是正确的，至少在我们的例子中是这样。换句话说，这就是我们所做的并且它有效：

事实上，我们的工作流程有点不同，因为我们倾向于进行squash 合并而不是原始合并。（注意：这是有争议的，见下文。）这允许我们将整个功能分支变成 master 上的单个提交。然后我们删除我们的功能分支。这允许我们在 master 上逻辑地构建我们的提交，即使它们在我们的分支上有点混乱。所以，这就是我们要做的：

Squash Merge Controversy - 正如一些评论者所指出的，squash 合并将丢弃您功能分支上的所有历史记录。顾名思义，它将所有提交压缩为一个。对于小功能，这是有道理的，因为它将它压缩成一个包。对于更大的功能，这可能不是一个好主意，特别是如果您的个人提交已经是原子的。这真的取决于个人喜好。

Github 和 Bitbucket（其他？）Pull Requests - 如果您想知道合并/rebase 与 Pull Requests 的关系，我建议您按照上述所有步骤操作，直到您准备好合并回 master。无需手动与 git 合并，您只需接受 PR。请注意，这不会进行 squash 合并（至少默认情况下不会），但非 squash、非快进是 Pull Request 社区中公认的合并约定（据我所知）。具体来说，它是这样工作的：

我开始爱上 Git，再也不想回到 SVN。如果你在挣扎，那就坚持下去，最终你会看到隧道尽头的曙光。

你可以将git rebase --interactive <commit>任意数量的提交压缩成一个。

除非您想将提交压缩到初始提交中，否则这一切都很好。这似乎是不可能的。

有什么方法可以实现吗？

中度相关：

在一个相关的问题中，我设法提出了一种不同的方法来解决第一次提交的压缩需求，也就是说，使它成为第二次提交。

如果您有兴趣：git：如何将提交作为第一个插入，然后转移所有其他提交？

我之前问过如何压缩 git 存储库中的前两个提交。

虽然这些解决方案相当有趣，并且不像 git 中的其他一些东西那样令人费解，但如果您需要在项目开发过程中多次重复该过程，它们仍然有点伤脑筋。

所以，我宁愿只经历一次痛苦，然后就可以永远使用标准的交互式变基。

那么，我想要做的是有一个空的初始提交，该提交只是为了成为第一个而存在。没有代码，什么都没有。只是占用空间，因此它可以成为 rebase 的基础。

那么我的问题是，拥有一个现有的存储库，我该如何在第一个提交之前插入一个新的空提交，并将其他所有人向前推进？

什么时候推荐使用 Git rebase vs. Git merge？

成功变基后我还需要合并吗？

我开始从NASM源文件重写一些 Perl 程序。我已经对我自己的工作副本做了一些提交，我想知道我是否应该做而不是做git pull，如果我应该做git rebase。

我几乎已经决定我应该做一个git rebase，但我不知道如何重新设计我的存储库以达到这种效果，或者即使它是可能的。

我的项目中有一个 master 分支，用于从其他人那里获取更改。从那以后，我通常有几个我目前正在研究的主题分支。

我的问题是：有没有办法让我将新的更改拉入我的主人，然后一次将我所有的主题分支重新定位到那个？

这是这种情况：

我想用一个命令来完成这个（H来自上游）：

现在，我知道我可以通过将 topic1 和 topic2 重新定位到 master 来实现这一点，我什至可以编写一个脚本来自动执行此操作。但是如果我有几个其他分支，经常创建新分支并删除其他分支，并且我一直收到上游更改怎么办？

这个操作（几个变基），当手工完成时，既累人又容易出错。

有没有更简单的方法？

我正在使用这么多 git-svn 存储库（同时），以至于更新它们变得很麻烦。我想编写一个自动化的脚本，这样我就可以每天早上在我拿咖啡的时候运行它。

基本上我的工作流程是这样的

我已经将该git svn fetch部分自动化，可以随时安全地完成。但是自动执行 git svn rebase 并不安全，因为可能存在冲突。

脚本如何确定变基后是否存在冲突？然后我可以运行 git rebase --abort，并在日志文件中写入一行，这样当我喝咖啡回来时，我可以查看失败：)

我想知道如何删除提交。

，delete我的意思是好像我没有提交，当我将来推送时，我的更改不会推送到远程分支。

我阅读了 git help，我认为我应该使用的命令是git reset --hard HEAD. 这个对吗？