Linux 开源项目git存储库的最佳实践

我正在为Github上托管的一个相当小的开源项目做贡献。为了让其他人可以利用我的工作，我在Github上创建了自己的fork。尽管Github选择了术语，但我不希望完全偏离主要项目。但是，我并不期望或希望我的所有工作都被主存储库接受。但是，其中一些已经合并到主存储库中，我希望这种情况会继续下去。我遇到的问题是如何最好地保持两棵树的状态，使它们之间的代码可以轻松共享

我已经或将遇到的一些情况包括：

• 我提交后来被接受的代码 进入主存储库。当我拉 将来从这个存储库中， 我的提交在我的 存储库
• 我将从不被接受的代码提交到主存储库中。当我将来从这个存储库中取出时，这两棵树已经分开，很难修复
• 另一个人出现并将他们的工作基于我的存储库。因此，如果可能的话，我应该避免更改我推送的提交，例如使用git rebase
• 我希望向主存储库提交代码。理想情况下，我的更改应该能够轻松地转换为补丁（理想情况下使用git格式的补丁），可以直接、干净地应用于主存储库

据我所知，有两种或三种方法可以解决这个问题，但没有一种特别有效：

• 经常运行git rebase，使我的更改不受上游存储库的影响。通过这种方式，我可以消除重复提交，但通常必须重写历史记录，这会给希望从我的工作中获得工作的人带来问题
• 经常将上游存储库更改合并到我的存储库中。这对我来说还行，但似乎不便于将代码提交到上游存储库
• 使用这些和git cherry pick的一些组合来保持秩序

---

其他人在这种情况下做了什么？我知道我的情况类似于各种内核贡献者和Linus的主存储库之间的关系，所以希望有好的方法来处理这个问题。不过我对git还比较陌生，所以还没有掌握它的所有细微差别。最后，特别是由于Github，我的术语可能不完全一致或正确。请随时纠正我。

我从类似情况中学到的一些技巧：

• 为上游作者的工作设置远程跟踪分支
• 经常将此跟踪分支的更改拉入主分支
• 为您正在处理的每个主题创建一个新分支。这些分支机构通常只能是本地分支机构。当您将上游更改为master时，请重新设置主题分支的基础，以反映这些更改
• 完成一些主题工作后，合并到master中。这样，从您的作品中派生出来的人就不会看到太多重写的历史，因为重定基址发生在您当地的主题分支中
• 提交更改：您的主分支基本上是一系列提交，其中一些与上游相同，其余的是您的。如果需要，可以将后者作为修补程序发送

---

当然，您可以自己选择分支名称和远程设备。我不确定这些内容是否详尽，但它们涵盖了我的大部分障碍。

自从我提出这个问题以来，我在Git方面获得了更多的经验，并大致确定这是最佳答案。仅在本地提交的情况下保持更改处于开发状态是关键。绝对是一个很好的提示。谢谢。你曾经在一台以上的计算机上处理过主题分支吗？如果是的话，你做了什么？不，我没有研究过跨计算机的主题分支，但“跨计算机”部分并不难。这是一种“跨越人群”的方式。您可以同样轻松地将主题分支推送到服务器，以便使用它。如果您有一个程序员团队在同一个外部维护的开源项目上处理不同的主题分支，该怎么办？然后，您将拥有一个公司git服务器，所有程序员都可以在其中推送。您将拥有主分支，其中包含许多来自主题分支的合并提交。然后，当您向上游发送补丁时，很可能会将这些合并提交压缩为单个提交。然后，如果它们被接受，您将从上游再次获得它们。它们不会与git服务器上已有的提交冲突吗？进行这种开发最干净的方法是什么？请注意，即使您（强制）推动您的重基更改，其他人也可以轻松地使用重基进行更新。这只是另一个历史不断被改写的研讨会。最重要的是，你需要更加小心一点，因为力推能够消灭一切：）