我将公开发布一个项目，希望能找到贡献者。我的项目是另一个活跃且资源丰富的项目（Django 项目模板）的本地克隆。我没有对代码进行任何深入的更改，尽管它现在是一个不同的项目。
我当前的 git 历史记录一团糟，而且没有多大帮助。我会在公开发布之前以某种方式清理它，当然，也会明确最初的分叉项目是什么。由于我认为我对项目所做的修改（主要是自定义）没有什么特别或神秘之处，因此我热衷于按照此压缩所有提交堆栈溢出帖子。我想知道这是否是一种不好的做法，因为如果我删除索引搜索历史记录，可能会变得更难做出贡献。我打算通过良好的评论、经过深思熟虑的自述文件等来减少此类问题。
我看到并希望避免的替代方案是艰苦的增量rebase squash使命。
我明白你有
由于您的（不整洁的）历史记录现已公开，因此有些人可能已经分叉/克隆了它以在您的工作基础上进行构建。通过重写你的历史，然后强行推到你的分叉上，你冒着惹怒那些人的风险......大事！那是不好的做法.
因此，在继续之前，您至少应该确保您的项目从未被分叉或克隆。幸运的是，GitHub 会跟踪这些信息。在右侧导航栏中，点击Graphs.
The Network选项卡将显示有多少人分叉了您的项目。
如果您是其中唯一列出的人，那很好。然后前往Traffic选项卡，查看您的项目被克隆了多少次。
如果您的项目从未被克隆，那么仍然有时间强制将您整理的历史记录推送到您的分叉上。
一个警告：当然，总是存在有人在你强制推送之前的关键时刻分叉/克隆你旧的、不整洁的历史记录的风险。小心行事。
在这种情况下，重写你的历史是完全安全的，并且被认为是好的做法.
您需要决定的只是您希望在新的、整洁的历史中保留的关卡细节。 这实际上取决于您，但是，当您重写历史时，请尝试将自己置于浏览该历史的人的位置，并尝试理解您的改进/更改。
例如，如果您对原始项目所做的更改很大，那么将所有提交压缩为一个大型提交可能不是最好的主意...通过以合乎逻辑的方式将更改分散到多个提交中，使您的历史记录更加平淡。
这里有一个相关段落Pro Git 书的内容：
[...]尝试使每个提交成为逻辑上独立的变更集。如果可以的话，尽量让你的更改易于理解——不要用整个周末的时间来编写五个不同的问题，然后在周一将它们全部作为一个大规模提交提交。即使您不在周末提交，也可以在周一使用临时区域将您的工作分成每个问题至少一个提交，并且每个提交都有一条有用的消息。如果某些更改修改了同一个文件，请尝试使用 git add
--patch部分暂存文件（第 6 章详细介绍）。无论您进行一次提交还是五次提交，只要在某个时刻添加所有更改，分支顶端的项目快照都是相同的，因此当其他开发人员必须审查您的更改时，请尽量让他们更轻松。如果稍后需要，此方法还可以更轻松地提取或恢复其中一个变更集。
