我开始认真地认为我需要分叉一个开源项目，以满足我自己的需求。我已经向原作者发送了补丁，但回复非常简洁，而且，嗯，不受欢迎。
无论如何。我已经阅读了Forking an open source project nicely的问题，但这并不能回答我更具体的问题：
我应该如何处理这些文件？
首先，我应该继续使用原始 Git 存储库，还是干脆扔掉所有历史，重新开始（“ rm -rf .git && git init”）？其次，对旧自述文件、以前的版本信息和版本控制有什么意见吗？
自然，许可和归属将根据许可的要求进行处理。
历史是源代码控制中最有价值的部分。我会说保留历史并标记您自己的发展开始的点。
我保留历史的原因：
git bisect- 您可能会发现您认为无害的更改实际上是至关重要的。这种东西很容易找到，bisect没有它就很难找到。如果没有历史，你就无法做到这一点。如果这些都不适用，您可能想重新开始。但即使你这样做了，也要将历史记录保存在私人副本中。如果您需要它，您可以从新存储库中移植您的更改并执行上述所有操作。
应该很轻松，除非您从头开始重写所有内容，否则这是正确的方法。
即使您从未打算将补丁发送回原作者，git也可以制作出色的本地版本控制工具。
关于 github 的另一件很酷的事情，作为之前发布的其他一些工作流程的附录：
git clone本地找到您的新仓库如果你从项目作者那里得到蹩脚的回应，那么他们并不完全值得你的帮助，我想你不应该太担心回馈。但是，仍然按照关于您的 Fork 队列的步骤 #4 - 您可以与 github 上与您一起对项目进行更改的其他所有人保持最新状态。
一个快速补充：如果你想让你的工作与原作者分开一点，很容易： * 创建一个新分支 ( git checkout -b my_branch_name) 并在那里工作。
* 一旦你的分支处于你想要的状态，你可以切换回原来的分支 ( git checkout master) 并将你的更改合并回 ( git merge my_branch_name)。
* 然后你可以将它推回 github ( git push origin master)，或者 * 为原作者制作一个补丁（带有一些版本git format-patch）。
正如其他人指出的那样：您应该真正保留历史。关于 README 和版本控制：您应该重命名项目以避免与原始项目混淆。您可以使用暗示原始项目的名称（但要注意潜在的商标问题），但尽量不要无礼。例如，如果原始项目名为“foo”，则将您的项目命名为“foo-ng”（下一代）会以某种方式表明您的项目比另一个项目“更好”。即使你觉得是这种情况，也不要那样做。
自述文件应根据您的需要进行更新。即它应该记录新的项目名称，它是项目“foo”的一个分支，并且可能是它的分支点。就我个人而言，我也会保留 ChangeLogs 和类似的、更面向技术的文档，并在必要时附加到它们，但重新开始任何“NEWS”风格的文档，即针对最终用户的文档。
如果您实际上是在分叉（从原始项目停止的地方开始），请务必克隆原始存储库并继续提交。这不仅允许您合并来自原始存储库的更改，还允许原始项目的开发人员从您的 fork 合并更改。如果两个项目都在Github上，这种协作会更容易（拉取请求）。
这实际上应该很自然，因为您应该在存储库中进行更改并发送补丁或拉取请求。分叉是相同的，只是它被标记为一个单独的项目。
如果您打算进行完全重写，请使用新初始化的 git。除此之外，只需克隆。