orangejulius：
我为Github上托管的一个相当小的开源项目做出了贡献。为了让其他人可以利用我的工作，我在Github上创建了自己的fork。尽管Github选择了术语，但我不希望完全脱离主要项目。但是，我不希望也不希望我的所有工作都被接受到主存储库中。但是，其中一些已经合并到主存储库中了，我希望这种情况会继续下去。我遇到的问题是如何最好地将我们的两棵树保持在可以轻松共享代码的状态。
我已经或将要遇到的一些情况包括：
- 我提交后来被接受到主存储库中的代码。将来当我从该存储库中提取信息时，我的提交将在我的存储库中重复。
- 我提交了从未被接受到主存储库中的代码。将来当我从该存储库中提取信息时，两棵树已经分开，并且很难对其进行修复。
- 另一个人来了，并将他们的工作建立在我的存储库上。因此，我应该尽可能避免更改已推送的提交，例如通过使用git rebase。
- 我希望将代码提交到主存储库。理想情况下，我的更改应该可以轻松转换为补丁程序（最好使用git format-patch），这些补丁程序可以直接且干净地应用于主存储库。
据我所知，有两种或三种可能的方法来解决此问题，但没有一种方法特别有效：
- 经常运行git rebase，以使更改不受上游存储库的影响。这样，我可以消除重复的提交，但经常不得不重写历史记录，从而给想要从我的工作中获得成果的人们带来了麻烦。
- 经常将上游存储库更改合并到我的库中。在我这端可以正常工作，但似乎不容易将我的代码提交到上游存储库。
- 使用这些和可能的git cherry-pick的某种组合来使事情井然有序。
在这种情况下其他人做了什么？我知道我的情况类似于各种内核贡献者和Linus主存储库之间的关系，因此希望有好的方法可以解决这个问题。我对git还是相当陌生，所以还没有掌握所有的细微差别。最后，尤其是由于Github，我的术语可能并不完全一致或正确。随时纠正我。
sykora：
我从类似情况中学到的一些技巧：
- 为上游作者的工作提供一个远程跟踪分支。
- 经常将更改从该跟踪分支拖入您的主分支。
- 为您正在处理的每个主题创建一个新分支。这些分支通常应该仅是本地的。当您将更改从上游转换为master时，请重新建立主题分支以反映这些更改。
- 完成一些主题工作后，合并为master。这样，从您的工作派生出来的人就不会看到太多的重写历史记录，因为重新编制发生在您本地主题分支中。
- 提交更改：您的master分支基本上是一系列的提交，其中一些与上游相同，其余的都属于您。如果需要，后者可以作为补丁发送。
当然，您可以选择分支名称和远程名称。我不确定这些对方案是否穷尽，但它们涵盖了我的大部分障碍。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
编辑于
我来说两句