整理或放弃git历史以供发布？

Question

我打算公开发布一个项目，希望找到贡献者。我的项目是另一个活跃且资源充足的项目（Django项目模板）的本地克隆。我没有对代码做过任何深刻的更改，尽管它现在是一个不同的项目。

我目前的git历史是一团糟，并没有多大帮助。我会在公开发布之前以某种方式清理它，当然，要清楚原来的分叉项目是什么。由于我认为我对项目的修改（主要是自定义）没有任何特殊或神秘的东西，所以我很想按照这个Stack Overflow post来压缩所有提交。我想知道这是不是很糟糕的做法，因为如果我删除索引的搜索历史记录，它可能会更难以贡献。我打算通过好的评论，考虑自述文件等来减少这些问题。

我看到并希望避免的替代方案是艰苦的增量rebase squash任务。

Answer 1

我知道你有

1. 从GitHub上的项目分叉，
2. 克隆你的叉子，
3. 在当地的回购邮件中做了许多提交。

如果你已经推到了叉子

因为你的（不整洁的）历史现在是公开的，所以有些人可能已经分叉/克隆它以建立你的工作。通过改写你的历史，然后强行推进你的岔路口，你冒着惹恼那些人的风险......很大的时间！这是不良做法。

因此，在继续之前，您应该至少确保您的项目从未分叉或克隆过。幸运的是，GitHub会跟踪这些信息。在右侧导航栏中，单击图表。



网络标签会显示分叉项目的人数。



如果你是唯一一个在那里列出的人，那就好了。然后转到 Traffic 选项卡，查看项目的克隆次数。



如果您的项目从未被克隆过，那么仍有时间强制将您的整理历史推送到您的分支。

一个警告：当然，总有一种风险，就是在你强迫推动之前，有人会在一段时间内分叉/克隆旧的，不整洁的历史。保持谨慎。

如果您不尚未向叉子推送任何内容

在这种情况下，重写您的历史记录是完全安全的，并被视为良好做法。

您需要决定的是您希望在新的整洁历史中保留的关卡细节。 这完全取决于你，但是，当你重写历史时，试着让自己置身于浏览历史并试图理解你的改进/变化的人。

例如，如果您对原始项目所做的更改非常重要，那么将所有提交压缩到一个大型提交中可能不是最好的想法...通过将更改分散到多个提交中，使您的历史更加流行合乎逻辑的方式。

这是Pro Git书的relevant passage ：

  

[...]尝试使每个提交成为逻辑上独立的变更集。如果可以的话，尝试让你的变化易于理解 - 不要在五个不同的问题上编码整个周末，然后在星期一将它们全部提交为一个大规模的提交。即使您在周末没有提交，也请使用星期一的暂存区域将您的工作分成每个问题至少一次提交，每次提交都有一个有用的消息。如果某些更改修改了同一个文件，请尝试使用git add --patch来部分暂存文件（详见第6章）。无论您执行一次提交还是五次提交，分支顶端的项目快照都是相同的，只要在某个时刻添加了所有更改，因此在他们必须检查您的更改时，尽量让同事更轻松。如果您以后需要，此方法还可以更轻松地提取或还原其中一个更改集。