在公共存储库中重新绑定和cherrypick后删除重复提交

我有一个开源项目的github存储库 - Cubes。出于各种原因，以非常谨慎的方式对存储库进行了rebase和cherry-picking。由于承诺信息不是公开的，因此历史也进行了编辑。跨越多个提交的一些操作似乎独立应用于两个克隆，之后这两个克隆合并为一个，导致更多重复。在公共存储库中重新绑定和cherrypick后删除重复提交

简而言之：有一个很大的缺乏适当的git卫生，历史现在非常混乱和多余。看下面的图片。

我想从存储库中删除整个重复分支。

问题：

有什么解决的清理庞大的重复量的这个问题的提交（实际上，复制分支机构）的最好方法？
有什么替代interactive rebasegit rebase -i？
如果交互式底牌是要走的路，那么将它做到面向公众的仓库会有多大的损害？我知道有没有这样做的建议。

的情况有些可视化：

来源

2017-04-04 Stiivi

刚刚重新开始。无论如何，我在提交消息中看不到任何有用的值。除了可能发布的版本 –

首先，我并不是对任何东西都使用rebase，除了发布里程碑（并且可能在发布过程的复杂性上预发布）之外，我并不喜欢使用rebase。我不认为通过增量提交进行排序的额外时间与尝试追踪某些内容或清理某些内容一样是个大问题。有很多你没有提及的考虑因素，包括你的发布过程。为什么“重复分支”是一个问题，根据过程而不总是一件坏事。为什么“面向公众的”知识库解决任何问题？为什么要删除一个分支是你的问题？ –

你可能会在旧的提交之上做另一个rebase。我甚至不想尝试解释如何成功完成这一点。你基本上会改变互动，并删除你不想要的模糊。这可能会变得非常糟糕，但我不建议它 –

一种方式让历史上看，不重写它与 “git replace” 代替提交更好。所以，你运行：

git replace --edit {commit}

的承诺，你“复制”分支合并，并在编辑器窗口中删除除了第一个所有“父”线。然后你不会在git客户端看到这个分支，尽管它仍然存在。您可以使用命令推送替换替换命令，使整个团队可以看到它们：

git push origin 'refs/replace/*:refs/replace/*' 
git fetch origin 'refs/replace/*:refs/replace/*'

来源

2017-04-05 08:48:16 max630

在公共存储库中重新绑定和cherrypick后删除重复提交

回答

相关问题