分叉FOSS项目的Git存储库

Question

我认真地开始认为我需要分叉一个开源项目，以满足我自己的需求。我已经向原作者发送了补丁，但回复非常简洁，而且不受欢迎。

总之。我已经阅读了问题Forking an open source project nicely，但这并没有回答我更具体的问题：

我该怎么处理这些文件？

首先，我应该继续使用origninal Git存储库，还是只丢弃所有历史记录，然后重新开始（“rm -rf .git && git init”）？其次，有没有关于旧自述文件的意见：s，以前的版本信息和版本控制？

当然，许可和归属将根据许可证的要求进行处理。

Answer 1

历史是源代码控制中最有价值的部分。我会说保留历史，只标出你自己的发展开始的地方。

Answer 2

我保留历史的原因：

1. 最重要的原因：这允许您在原始代码进入时导入有用的更改。除非您预测您的项目将如此彻底地与原始代码分开，否则您将永远不会想要他们所做的任何事情你的，它可以更容易地追踪这些有用的变化并导入它们。
2. 如果您愿意，可以更容易回馈（比如原始项目的所有者更愿意与您合作）。
3. 如果你回头看它，就会更容易追踪到特定变化的起源，不知道这意味着什么。在git的情况下，它可以帮助你捕获因git bisect而导致的错误 - 你可能会发现你认为无害的变化实际上是至关重要的。这是bisect很容易找到的东西，没有它就很难找到。没有历史，你不能这样做。

如果这些都不适用，您可能想重新开始。但即使你这样做，也要将历史保存在私人副本中。如果您需要它，您可以从新的存储库中移植您的更改并执行上述所有操作。

Answer 3

1. 从Github分享它
2. 将其克隆到您的本地计算机
3. 应用您原始作者发送的未被接受的补丁
4. 推

应该是非常轻松的，除非你从头开始重写所有内容，否则这是正确的方法。

Answer 4

即使您从未计划将补丁发送回原作者，git也会制作精彩的本地版本控制工具。

关于github的另一个很酷的事情，作为之前发布的其他一些工作流程的附录：

1. 创建一个github帐户。
2. 分叉您想要的存储库（通过转到github上的页面并单击fork按钮）
3. 按照说明git clone您的新回购邮箱
4. 根据需要在当地开展工作;另外，请务必从github上的原始源中提取更新（您可以在Github上的项目的版本中执行此操作，在Fork Queue中）
5. （而不是向原作者发送补丁）请求作者通过转到原始项目的Fork Queue页面来获取补丁 - 这使原始作者无需抓取您的更改。

如果你得到项目作者的蹩脚回应，那么他们并不完全值得你的帮助，我想你不应该过分担心回馈。但是，仍然按照关于您的Fork Queue的步骤＃4 - 您可以与github上的所有其他人保持同步，并与您一起对项目进行更改。

快速补充：如果你想让你的作品与原作者分开，那么很容易：  *创建一个新分支（git checkout -b my_branch_name）并在那里工作  *在您想要的状态下拥有该分支后，您可以切换回原始分支（git checkout master）并将更改合并回（git merge my_branch_name）。
 *然后你可以把它推回到github（git push origin master），或者  *为原作者制作补丁（使用某些版本的git format-patch）。

Answer 5

正如其他人所指出的那样：你应该保留历史。关于README和版本控制：您应该重命名项目以避免与原始项目混淆。您可以使用暗示原始项目的名称（但要注意潜在的商标问题），但尽量不要无礼。例如，如果原始项目名为“foo”，则命名为项目“foo-ng”（下一代）将以某种方式表明您的项目比另一个项目“更好”。即使你觉得情况确实如此，也不要这样做。

应根据您的需求更新README。即它应该记录新项目名称，事实上它是项目“foo”的分支，可能是它分叉的点。就个人而言，我还会保留ChangeLogs和类似的，技术更为面向的文档，并在必要时附加到它们，但是开始新的任何“新闻”式文档，即针对最终用户的文档。

Answer 6

如果您打算进行完全重写，请使用刚刚初始化的git。除此之外，只需做一个克隆。

Answer 7

如果您实际上正在分叉（从原始项目停止的地方开始），请务必克隆原始存储库并继续提交。这不仅允许您合并原始存储库中的更改，还允许原始项目的开发人员从您的fork合并更改。如果两个项目都在Github上，那么这种协作将更加容易（拉取请求）。

这应该是非常自然的，因为您应该在存储库中进行更改并发送补丁或拉取请求。分叉是相同的，除了它被标记为一个单独的项目。