问题标签 [git-rebase]

废话！大约一周前，我在尝试清理我的存储库时重新调整了一些提交，显然我并没有真正完成它。今天，一周后的几次提交，我去 rebase 重新排序了从今天开始的一些提交，它告诉我我已经在 rebase 中了。

这应该是一个提示复制我的回购以防万一。但我没有……相反，我跑了git rebase --abort，这在当时听起来是对的。嗯，那是不对的。它从一周前中止了 rebase 并将 master 的 HEAD 重置为旧的。假的！

我还有其他几个相当新的分支，并且我已经多次推送到远程，但最近的更改似乎永远消失了。我没有适当级别的 git-fu 知道是否有任何方法可以恢复我的更改。

我搞砸了吗？

编辑- 哇！多谢你们！git reflog太棒了！我完全康复了……吸取了教训。将 Tchalvak 的答案标记为第一个发布者已被接受。

我有一个 Git 存储库，其分支几乎不会更改（没有其他人为它做出贡献）。它基本上是去掉了一些代码和文件的主分支。有了这个分支，我可以很容易地打包我的项目的精简版本，而不必每次都手动剥离代码和文件。

我一直在使用git rebase使该分支与 master 保持最新，但是当我在变基后尝试推送分支时总是收到此警告：

然后我使用git push --force它并且它有效，但我觉得这可能是不好的做法。我想快速轻松地让这个分支与主分支保持“同步”。有没有更好的方法来处理这个任务？

更新

有关完整说明和解决方案，请参阅此主题：

git rebase 和 git push：非快进，为什么要使用？

作为集成测试，我想在将它们与我的主人合并之前加入几个分支。

他们都偏离了主人，走自己的路。这是正确合并没有直接关系的不同分支（例如父/子）？

重新加入分支机构有什么好的做法吗？

在此先感谢，劳尔。

我与一个使用 git 进行源代码管理的小团队合作。最近，我们一直在做主题分支来跟踪功能，然后在本地将它们合并到 master 中，然后将它们推送到远程服务器上的中央 git 存储库。这在 master 中没有进行任何更改时效果很好：我创建了我的主题分支，提交它，将它合并到 master，然后推送。万岁。

但是，如果有人在我之前推送到原点，我的提交不会快进。因此，随之而来的是合并提交。当主题分支需要在本地与 master 合并以确保我的更改与现在的代码一起工作时，也会发生这种情况。因此，我们最终得到了无处不在的合并提交和一个与友谊手镯相媲美的 git log。

因此，变基是显而易见的选择。我想要的是：

• 创建包含多个提交的主题分支
• 结帐大师和拉（快进，因为我还没有承诺掌握）
• 将主题分支重新定位到新的主人头上
• 针对 master 重新设置主题（因此主题从 master 头开始），将 master 带到我的主题头

我目前的做法如下：

有没有更快的方法来做到这一点？

git-rebase手册页提及-X<option>可以传递给git-merge. 何时/如何准确？

我想通过应用带有递归策略和他们的选项的补丁来重新定位（应用任何棒，而不是跳过整个冲突的提交）。我不想合并，我想让历史线性化。

我试过了：

和

但 git-X在这两种情况下都拒绝。

git rebase -Xtheirs在最近的版本中工作，除了树冲突需要手动解决。解决这些冲突后，您需要运行git rebase -Xtheirs --continue（重复）。-X

git rebase在保留提交时间戳的同时执行是否有意义？

我相信结果是新分支不一定按时间顺序有提交日期。这在理论上是可能的吗？（例如使用管道命令；这里只是好奇）

如果理论上可行，那么在实践中是否可以使用 rebase，而不是更改时间戳？

例如，假设我有以下树：

现在，如果我oldbranch基于master，提交日期从 1984 年 2 月更改为 2010 年 6 月。是否可以更改该行为以不更改提交时间戳？最后，我将因此获得：

这有意义吗？在 git 中甚至允许有一个历史，其中一个旧的提交有一个更新的提交作为父级？

以下是我经常遇到的一个场景：

master您在or上有一组提交design，我想将它们放在production分支之上。

我倾向于创建一个以基础为基础的新分支，在其production上挑选这些提交并将其合并到production

然后，当我合并master到生产时，我面临合并冲突，因为即使更改是相同的，但由于樱桃挑选而被注册为不同的提交。

我找到了一些解决方法来解决这个问题，所有这些都很费力，可以称为“黑客”。

尽管如此，我还没有做太多的变基，我相信这也会创建一个新的提交哈希。

我应该在我挑选的地方使用变基吗？与此相比，它还有什么其他优势。

我们有一个包含 400 多个提交的 Git 存储库，其中前几十个是大量的反复试验。我们希望通过将许多提交压缩成一个提交来清理这些提交。自然， git-rebase 似乎是要走的路。我的问题是它最终会出现合并冲突，而这些冲突并不容易解决。我不明白为什么会有任何冲突，因为我只是在压缩提交（而不是删除或重新排列）。很可能，这表明我并不完全理解 git-rebase 是如何进行压缩的。

这是我正在使用的脚本的修改版本：

repo_squash.sh（这是实际运行的脚本）：

repo_squash_helper.sh（此脚本仅供 repo_squash.sh 使用）：

repo_squash_list.txt：（此文件仅供 repo_squash_helper.sh 使用）

我将把“新消息”的内容留给你想象。最初，我在没有“--strategy theirs”选项的情况下执行此操作（即，使用默认策略，如果我正确理解文档是递归的，但我不确定使用哪种递归策略），它也没有不工作。另外，我应该指出，使用 repo_squash_helper.sh 中注释掉的代码，我保存了 sed 脚本工作的原始文件并针对它运行 sed 脚本以确保它正在做我想要它做的事情（它是）。同样，我什至不知道为什么会发生冲突，所以使用哪种策略似乎并不重要。任何建议或见解都会有所帮助，但大多数情况下我只是想让这个挤压工作。

更新了与​​ Jefromi 讨论的额外信息：

在处理我们庞大的“真实”存储库之前，我在测试存储库上使用了类似的脚本。这是一个非常简单的存储库，并且测试运行良好。

失败时我收到的消息是：

这是第一次壁球提交后的第一个选择。运行会git status产生一个干净的工作目录。如果我然后执行 a git rebase --continue，我会在多次提交后收到非常相似的消息。如果我再做一次，我会在几十次提交后得到另一个非常相似的消息。如果我再做一次，这次它会经历大约一百次提交，并产生以下消息：

如果我然后运行git status，我得到：

“两个修改”位对我来说听起来很奇怪，因为这只是一个选择的结果。还值得注意的是，如果我查看“冲突”，它可以归结为一行，其中一个版本以 [tab] 字符开头，另一个版本以四个空格开头。这听起来可能是我如何设置配置文件的问题，但其中没有任何问题。（我确实注意到 core.ignorecase 设置为 true，但显然 git-clone 是自动完成的。考虑到原始源位于 Windows 机器上，我对此并不完全感到惊讶。）

如果我手动修复file_X.cpp，它会在不久之后因另一个冲突而失败，这次是在一个版本认为应该存在的文件（CMakeLists.txt）和一个版本认为不应该存在的文件（CMakeLists.txt）之间。如果我通过说我确实想要这个文件（我确实想要）来解决这个冲突，那么稍后我会遇到另一个冲突（在同一个文件中），现在有一些相当重要的更改。它仍然只完成了大约 25% 的冲突。

我还应该指出，因为这可能非常重要，所以这个项目是从一个 svn 存储库开始的。最初的历史很可能是从那个 svn 存储库中导入的。

更新#2：

在百灵鸟（受 Jefromi 评论的影响）上，我决定将我的 repo_squash.sh 更改为：

然后，我按原样接受了原始条目。即，“变基”不应该改变任何事情。它最终得到了与前面描述的相同的结果。

更新#3：

或者，如果我省略该策略并将最后一个命令替换为：

我不再遇到“无事可做”的变基问题，但我仍然面临其他冲突。

使用重新创建问题的玩具存储库进行更新：

test_squash.sh（这是您实际运行的文件）：

test_squash_helper.sh（由 test_sqash.sh 使用）：

PS：是的，当你看到我使用 emacs 作为后备编辑器时，我知道你们中的一些人会畏缩。

PPS：我们确实知道在 rebase 之后我们将不得不删除现有存储库的所有克隆。（按照“发布后您不应重新设置存储库”的思路。）

PPPS：谁能告诉我如何为此添加赏金？无论我处于编辑模式还是查看模式，我都没有在此屏幕上的任何地方看到该选项。

编辑问题归结为“也可以git rebase指示重新设置标签吗？” 但是对原始问题的回答也会有所帮助。

询问如何将过去添加到 git 存储库？我按照这些说明进行操作。<编辑>然后我重新定位以包含仅在快照中的文件，请参见此处。< /编辑> 由于历史被重写（由git filter-branch或git rebase两者？）所有标签仍然在原始时间线上*，我会以某种方式喜欢把他们搬到新的。我想我使所有带有标签的提交消息都是唯一的，所以我可以尝试编写一个使用它们的脚本，但更通用的git move-tags <from> <to>会更好。

那么，有没有办法解决“在新时间线上的 N 次提交之后的提交，以便标记旧时间线上的第 N 次提交”？除了明显的手动重新标记之外的任何其他解决方案也很棒。

（请随时将那个可怕的长句子改成简单的英语......）

*)嘿，git 解决了祖父悖论！

我现在有一个庞大的、臃肿的 Git 存储库，占用了 GitHub 上的大量磁盘空间，我想节食。我需要丢弃在项目历史早期做出的与项目当前方向基本无关的古老提交。

我是 - 并且将永远是 - 这个私人回购的唯一用户。

理想情况下，我可以做类似的事情：

git rebase from-birth-of-repo-直到一个月前

谢谢，
道格