问题标签 [squash]

我在 GitHub 上创建了一个项目。在对我的分叉项目进行更改/提交之前，我需要压缩原始提交。但是，我想知道我是否能够创建一个拉取请求，以便将我的更改合并回原始项目。这可以做到吗？

我尝试在一个测试项目中执行此操作，但似乎我无法执行拉取请求，因为网络显示这两个项目不再连接。这是我所做的：

1. 创建了一个测试项目（“原始项目”）
2. 创建一个新文件，提交并推送
3. 创建另一个文件，提交并推送
4. 在另一个帐户中，我分叉了测试项目（“分叉项目”）
5. 在分叉的项目中，我压缩了具有 3 次提交的 git 日志（运行 'git rebase --root -i' 然后 'git push origin master --force'）
6. 在分叉的项目中，我修改了其中一个文件，提交并推送。这是对前叉的第一次更改。
7. 试图在 GitHub 上提出拉取请求，将 #6 的更改从分叉项目合并到原始项目，但说“没有什么可比较的。original:master 和 forked:master 是完全不同的提交历史。”

网络如下所示：

也许我做错了什么？还是我的设置不正确？或者根本做不到……

我的历史看起来像这样（按数字/字母排序）：

我想压缩提交 c2a 和 c2b，但我找不到一个独立于分支的方式来做到这一点，所以我不得不重新设置 4 次，而不是我期望的结果（星号代表由于重新设置的副本）：

代替

对历史的所有修改都是本地和远程的

我的问题是：

• 如何修复我的历史记录，以便将所有副本合并到一个提交中？
• 如何在不重现问题的情况下将 c1a 和 c1b 压缩到一个提交中？

我有一组要压缩的提交。我知道有一个，在运行时

根本没有出现，所以为了解决这个问题，我决定从尾部开始一个一个地挤压，这样当我遇到麻烦的提交时，我可以尝试会发生什么，这很好奇。当我的日志显示为

squashedCommitsHash 挤压提交麻烦的提交哈希麻烦的提交消息

我跑

然后我得到

什么？！我的麻烦提交在哪里？为什么不存在？为什么所有其他人都出现了，尽管指定我只想挤压 2？

我有一个存储库已经变得太大以至于无法使用。基本上我的存储库超过 2GB，克隆时间太长。我现在想缩小它，但仍然可以回到某些特定的旧版本......缩小将涉及重写历史，所以我很好。有克隆的人将不得不在新的 repo 克隆中的新分支之上 rebase/cherrypick/copyfiles。

• 我在这个存储库中有二进制文件，但我需要它们（将其视为软件运行的必需资源）。所以我不能真正使用 filter-branch 或BFG来删除一些大的二进制文件，因为在恢复到过去的提交时我可能需要它们。
• 我不关心以前的旧/已经合并的分支（例如：功能分支），但我关心一些特定的提交（例如过去发布分支的负责人）
• 由于我将修改（~many~）非常旧的提交，我现在不知道如何正确解决合并冲突（就像基本的 rebase/cherrypick 可能发生的那样）所以我正在寻找一个不会产生任何冲突的解决方案，或者只产生可以自动解决的冲突。
• 我想保留所有当前的分支，以便在克隆上进行工作的人可以对它们进行 rebase/copychanges。
• 我想在我的新提交之间拥有相关历史记录，以匹配旧回购的历史记录（就像提交被压扁一样）。当前分支的历史将从这些旧的压缩提交之一开始。

我认为它是不需要的旧存储库历史的壁球。到目前为止，我为我的案件提出的可能流程（我错过了一些步骤，但我仍然不确定这是否会达到我的想法）是：

• 克隆现有仓库的镜像。
• 从我想保留的旧提交创建孤立分支。这将创建包含所有需要的文件的无父压缩提交。
• 以某种方式将它们链接到重新创建旧的回购历史 => 如何？合并/变基/重置+提交孤儿？
• Cherrypick 每个当前分支的提交列表（使用间隔），并将它们应用于压缩其第一个分歧提交的父级的最新提交 => 如何自动找到将樱桃选择的提交间隔应用于哪个提交？这会在没有冲突的情况下工作吗？
• 将标签移动到新树。删除以前的树。git 垃圾收集。

这在没有任何冲突的情况下可行/可行吗？这在任何情况下都有效（git commit tree 可能非常复杂）？有什么更好的安全和自动压缩历史的解决方案吗？

在我看来，这种类型的维护任务对于一个长期运行的项目来说会发生，所以我假设其他大型项目已经使用了某种类型的解决方案。但是我想可能有一个我不知道的 git init （或其他命令）选项，可以从旧仓库为此用例创建一个新仓库？

更新：我在这里找到了解决方案的开始：https ://wincent.com/wiki/Editing,_amending,_or_squashing_the_root_commit_in_a_Git_repository 但我想在我的历史记录中以全自动方式（即没有冲突）多次执行此操作。 .

我有一个这样的分支：

我想重写它并使它像这样：

这意味着，压缩所有合并。

树枝很长。这怎么能自动完成？

编辑

这不是历史线性化。我想压缩所有的合并，比如 D 和 G。

我有一个历史混乱的项目，你越往前看就越混乱。我想要做的是将所有内容保留到特定提交，并从该提交开始压缩所有内容。所以在下面的方案中，我想保持 A 和 B 之间的所有内容，包括 A 和 B 之间的所有内容，并压缩 B 和 C 之间的所有内容：

A-...-B-...-C

不幸的是，在进行交互式 rebase 时，我似乎最终会沿途压平整个历史，这并不理想。我仍然希望看到 A 和 B 之间的分支和合并。有没有直接的方法可以做到这一点？我错过了一些非常简单的东西吗？

我想自动清理远程分支。我希望能够检查一个分支是否已经合并到 master 中。最初，我的计划是使用 git merge-base 来查看最后一次常见的提交。

然而，事实证明，当我们将所有分支合并到 master 中时，我们会压缩所有分支。由于这会创建一个新的提交哈希，我无法找到 master 和我的分支之间的共同提交。

如果我们在合并时将它们全部压扁，我该如何确定是否已合并分支？

提前致谢！

我的团队希望我进行壁球，但有时他们希望我再次拆分它（根据某些方面）。

在 squash ( git rebase -i) 之后，分支移动并且旧的提交被留在“真空”中。我想将分支留在旧的未压缩提交上，以便能够轻松返回。

是否有一种命令方式可以以某种方式离开旧分支位置，或者相反，为压扁的提交创建一个新分支？

在编写新代码时，我会进行许多小的提交来跟踪我的更改。但是，我的公司更喜欢将每个功能作为单个提交提交。所以解决方案是将我的整个（本地）分支压缩为一个提交。

如何在不使用git rebase --interactive然后更改pick为squash所有提交的情况下压缩整个分支？

我正在尝试正确地重新设置已经推送到远程的 git 历史记录。一切都按预期工作，除了在我编辑的提交中提到了一个神秘的“两个用户” squash。此提交的差异与 user 所做更改的差异相匹配tpgmartin，在此图像情况下。

这是我在 github 上看到的截图（我是用户ahoskins）：

为什么会发生这种行为？