我不是英语母语用户。请原谅我的语法错误。
前言：
我们的项目松散地遵循git-flow结构。最近，我必须创建多个演示版本，每个演示版本包含一个或多个演示功能。主要生产版本不必使用这些功能。
主要是因为我们的销售人员可以使用那些具有更多精美功能的演示版本来探索潜在客户。
问题：
问题是如何管理这些演示版本并尝试适应当前使用的git-flow结构，并且可以执行以下操作：
Tempoary Solutions： 目前，我们使用多个分支，每个分支代表一个演示版本，以维护版本。然而，反复合并和开发分支使得现在几乎变得混乱。
我试图将repo作为演示版本。但是由于几乎90％的代码是相同的，我的同事不接受这个解决方案，并且它也没有能力与主要仓库合并。 （也许多个遥控器可以解决这个问题？）
那么，有什么好的解决方案适用于这种情况吗？
答案 0 :(得分：0)
由于这些演示版本主要是为了吸引潜在客户，因此它远离您的生产版本（它们是松散连接的）。我建议您将这些演示版本管理到不同的git存储库。使用不同的git存储库，您可以：
1.并行更新演示版本。
2.将演示版应用于开发分支：
# in local repo contains develop branch
git remote add demo1 <URL for a demo> -f
#use gitk --all to find a commit which you want to apply on develop branch
git checkout develop
git cherry-pick <the commit you found>
3.从开发分支更新演示版：
# In a demo repo
git remote add dev <URL for develop repo> -f
# find the commit id you want to update to demo repo by gitk --all
git cherry-pick <the commit you found>
答案 1 :(得分：0)
分行与回购
我认为你不能比使用分支机构进行演示版本更好。听起来，当前的困难是主线开发和演示版本之间的交互。如果你必须让这些交互发生，那么必须跨越回购边界进行交互不会让事情变得更容易。 （当然，如果你不需要这样做......你就不会这样做，开始就没有问题。）
问题不在于是否可以开发出可以根据需要在回购之间迁移变更的模式;问题是，相对于使用分支，您将获得的努力是什么。换句话说，考虑到git在回购中给你多大的灵活性，你期望通过使用多个回购获得什么？
除了复杂性之外，使用多个repos的输掉是一个单一，全面的项目历史记录，可以轻松回答诸如“当Yoyodyne帐户对Feature X给出正面反馈，主要功能是什么等问题他们正在反对吗？因为我们看到了这个奇怪的错误......“
那怎么可能更好？
听起来演示分支的分支/合并模式可能是真正的问题。对此有明确的（可能是最小的）标准可能会有很长的路要走。究竟应该是一个团队特定的决定，但有些想法：
您可能希望避免从演示分支合并。如果基于演示接受了一组功能，那么可能是时候回到功能分支并通过开发通过通常的集成和测试程序运行它们。这使您可以独立于特定演示的演变来推广功能。它还允许演示开发人员确定他们是否对特定功能进行了更改（在这种情况下，更新功能分支并重新合并到演示中），或者只是执行特定于演示的工作，这些工作永远不属于任何特定功能。功能（不用担心它可能最终意外地合并到主线开发）。
如果您需要了解演示中的哪些功能，git branch --list具有--merged选项
git branch --list --merged demoXYZ
如果你没有删除分支，因为它们已合并到develop，那么排除它们比我想要的要复杂一些;我通常只是在开发
git branch --list --no-merged develop
并使用comm之类的内容来查找哪些内容位于演示文稿的分支列表中。
留下将合并到演示分支。为了最大限度地减少混乱，您可以将其限制为“仅来自develop”，并且只在真正需要时才执行此操作。 （让演示分支落后于开发并不理想，但是如果你遵循我的上述建议，那么所涉及的功能还没有通过主线集成和测试，所以它可能不像看起来那么重要。）
如果一个相当小的团队在给定的演示上工作，你可以重新定义演示以跟上develop而不是合并（尽管如果很多开发人员同时使用该演示，这可能不是最好的选择因为开发人员必须在每次之后从上游rebase中恢复。）