我正在为Github上托管的一个相当小的开源项目做贡献。为了让其他人可以利用我的工作，我在Github上创建了自己的fork。尽管Github选择了术语，但我不希望完全偏离主要项目。但是，我并不期望或希望我的所有工作都被主存储库接受。但是，其中一些已经合并到主存储库中，我希望这种情况会继续下去。我遇到的问题是如何最好地保持两棵树的状态，使它们之间的代码可以轻松共享
我已经或将遇到的一些情况包括：
- 我提交后来被接受的代码
进入主存储库。当我拉
将来从这个存储库中，
我的提交在我的
存储库 - 我将从不被接受的代码提交到主存储库中。当我将来从这个存储库中取出时，这两棵树已经分开，很难修复
- 另一个人出现并将他们的工作基于我的存储库。因此，如果可能的话，我应该避免更改我推送的提交，例如使用git rebase
- 我希望向主存储库提交代码。理想情况下，我的更改应该能够轻松地转换为补丁（理想情况下使用git格式的补丁），可以直接、干净地应用于主存储库
据我所知，有两种或三种方法可以解决这个问题，但没有一种特别有效：
- 经常运行git rebase，使我的更改不受上游存储库的影响。通过这种方式，我可以消除重复提交，但通常必须重写历史记录，这会给希望从我的工作中获得工作的人带来问题
- 经常将上游存储库更改合并到我的存储库中。这对我来说还行，但似乎不便于将代码提交到上游存储库
- 使用这些和git cherry pick的一些组合来保持秩序
其他人在这种情况下做了什么？我知道我的情况类似于各种内核贡献者和Linus的主存储库之间的关系，所以希望有好的方法来处理这个问题。不过我对git还比较陌生，所以还没有掌握它的所有细微差别。最后，特别是由于Github，我的术语可能不完全一致或正确。请随意纠正我
我从类似的情况中学到了一些技巧：
- 为上游作者的工作设置远程跟踪分支
- 经常将此跟踪分支的更改拉入主分支
- 为您正在处理的每个主题创建一个新分支。这些分支机构通常只能是本地分支机构。当您将上游更改为master时，请重新设置主题分支的基础，以反映这些更改
- 完成一些主题工作后，合并到master中。这样，从您的作品中派生出来的人就不会看到太多重写的历史，因为重定基址发生在您当地的主题分支中
- 提交更改：您的主分支基本上是一系列提交，其中一些与上游相同，其余的是您的。如果需要，可以将后者作为修补程序发送
当然，您可以自己选择分支名称和远程设备。我不确定这些都是详尽的场景，但它们涵盖了我的大部分障碍