我有一个主要网站，我已分成两个新网站。这些网站的80％相同，但存在一些差异。因此，在主站点上进行更改时，某些提交需要发送到分支，而其他提交则不需要。
现在我正在通过使用cherry-pick更新上游更改我的forks来处理这个问题。因此，当我在需要传播的主站点上进行更改时，我必须登录两个分叉并使用cherry-pick单独更新它们。这有点乏味，但是因为每次推送更改时我都需要立即登录到我的两个分支并进行更新，所以我不会忘记哪些提交需要被提取而哪些提交没有。
我的问题是：有没有办法标记我需要在主仓库上传播的提交，以便在我的forks中我只能说“只在标记的提交中合并”而不是挑选每个提交一个接一个？
感谢您提供有关如何管理这些网站的任何提示。
更新--- 我太新了，不能回答我自己的问题，这个回复对于评论来说太长了 - 所以，我在这里折腾：
啊......好吧，我想我明白了。这是我第一次涉足分叉，所以我认为我可以在这些条款中迷失一点。看起来分支和分叉有时可以互换。让我看看我是否正确理解了这个概念。
我有一个原始的回购邮件是原始网站。当网站分歧时，我应该采用原始仓库并分叉成“叉A”。这让我留下原始的回购，我现在称之为“上游”。所以，我把主人“上游”分成了叉子A.
所以，我继续在fork A工作，我有提交，我想回到“上游”。为了解决这些问题，我将通过“git checkout upstream / master”检查上游。然后，我可以将共享提交挑选到该分支中并推送它们。
现在，在分叉A分离之后的某个晚些时候，我也将叉B从“上游”分离出来。要更新Fork B，我现在只需要做一个“git pull upstream / master”，对吗？
感谢您的帮助理解。我喜欢git是多么强大，但是你的大脑包裹起来肯定很多。 ：）
答案 0 :(得分：0)
是的，它被称为分支。在这种情况下，您需要第三个分支。
如果你让master只包含属于公共树的东西，并且每个分支都有自己的特殊部分，那么你只需要将主变化合并到每个分叉的部分中。根据您的描述，听起来当前的主人确实不“应得”这种状态，并且应该像其他人一样，在完全共享的核心代码之外的分支。
要做到这一点，我建议找到你分叉其他两个分支的位置，并从那里创建另一个分支。接下来，将您关注的更改从旧的master分支拉入其中，然后将其声明为新的master并将新的更改合并到其中，或者您可以重新绑定现有的分支以删除cherry-picks，以便简单合并工作得很好。
PS：如果您选择“干净”的rebase路线，请先制作备用分支。