这是故事， 我有一个大型的软件源代码，即Web前端，实际上有数百个可以访问近一千个客户端，我的计划是每个客户端都可以直接链接到该git repo中的特定分支（用于源代码），没有客户会在我们的git repo中共享相同的分支名称。
现在，它在我在某些客户端甚至所有客户端上部署功能的方式上都面临挑战。
假设当前所有分支（所有客户端）都从相同的提交历史记录开始，即：
git log在分支：master，client1，...，client900：
然后，从分支master为feature_a创建了一个开发分支，然后为该功能开发了所有必需的代码，
我的计划是仅将feature_a部署到100个客户端，即将所有从feature_a到client1的提交合并到client100。
一切顺利。
然后，再次从分支master为feature_b创建了一个开发分支，然后为该功能开发了所有必要的代码，
现在，我的计划是将feature_b部署到所有客户端，即将所有从feature_b到client1的提交合并到client900。
目标是使client1至client100具有2个功能，而其余仅具有1个附加功能。
由于开发feature_a和feature_b要求我更改许多相同的文件，因此将导致分支client1到client100的合并冲突，
解决数百个（即使不是数千个）合并冲突不是我的选择，有没有更好的方法来解决此问题？还是有更好的git repo架构设计或方法，以便将功能部署到某些客户端，然后所有客户端都无缝的问题？
答案 0 :(得分：0)
我不同意这种结构化代码的方式，并且我同意注释者的意见，即您应该使用功能标记。如果您担心代码甚至无法到达客户端，则应将功能标记视为构建过程的一部分，以便给定的工件仅具有所需的功能。
话虽如此，对于数量很少的功能，您可以使用标签来改善情况。
不是每个客户端都有唯一的分支，而是给每个客户端一个唯一的标签。大多数git操作将执行相同的操作，但是更改它们指向的代码要容易得多。
然后，您的分支应该基于功能。因此，您将拥有feature_a，其中仅包含功能a的代码。然后，您有feature b的代码仅用于功能b。然后，您有feature_a_b包含功能a和b －并且只需要解决一个位置中的冲突。
对于部署，您只需将标签更改为指向您想要的分支-client1指向client100指向feature_a_b，client101指向client900到feature_b。
然后假设client562决定升级（或其他方式），现在他们需要功能a。超级简单-只需更改标签client562指向feature_a_b。无需合并！
但是，如果有客户特定的更改怎么办？
从功能分支中关闭一个客户端分支，然后在其中进行更改。
但是，如果有客户特定的更改并且它们更改了功能怎么办？
使用client分支，只需将特定于客户端的提交重新部署到适当的功能分支上即可。
随着引入更多功能，这变得更加复杂，特别是您将需要2^(n-1)个功能分支，其中n =功能数量。实际上，如果某些特征必须存在才能使其他特征起作用（例如，特征j仅在存在特征c时才有意义），这可能会更低。
但是，这是一种非常复杂的方法，我不希望在这种环境下实际工作。我仍然认为，与管理1,000个分支机构相比，这是一个进步，但我希望您会考虑采用其他方法来管理部署。