与白标项目一起使用的 Git 策略答案

【问题标题】：Git strategy to use with white label project与白标项目一起使用的 Git 策略
【发布时间】：2018-01-24 01:58:07
【问题描述】：

我有一个项目托管在 git 环境中，我必须基于它生成一个白标项目。我对 Microsoft 的 TFVC（团队基金会版本控制）的经验要丰富得多，我很容易知道如何使用它，但我不确定我应该如何继续使用 git。

在 TFVC 中，我会从主项目创建一个分支“A”，删除任何客户特定的内容，然后就完成了，我有一个通用版本。之后我将删除父级，从'A'创建一个新分支'B'，然后从主项目执行baseles合并到'B'所以现在我有了我需要的层次结构，新创建的分支包含所有客户具体变化。当新客户到来时，我从通用的“A”创建一个分支“C”并应用所需的任何新更改。

如果一个新特性是通用的并且对所有客户端都足够有用，它将在“A”中开发，然后将合并到“B”、“C”等。这是最好的方案，因为所有客户端在我看来，将允许请求不同的功能并使用单个存储库打开和关闭它们，这比维护源自一个公共代码的不同示例代码要糟糕得多。相同的功能在不同的客户端也可能表现不同，我不希望应用程序必须在运行时检查它。

解释了场景后，我如何使用 Git 来做到这一点？另外，是否可以使用forks而不是使用git的分支来完成？

【问题讨论】：

标签： git gitlab git-branch

【解决方案1】：

据我了解，您通常应该做同样的事情，可能会有细微的变化。

从主项目创建一个分支“A”，删除任何客户特定的内容，就完成了，我有一个通用版本。

你在 git 中做同样的事情

之后我将删除父级，从“A”创建一个新分支“B”，然后执行从主项目到“B”的baseles合并，所以现在我有了我需要的层次结构，新创建的分支包含所有客户特定的更改

相反，您可以启动分支B 并恢复（作为git revert）您对分支A 所做的所有更改以删除特定于客户的信息，从而返回到与最初相同的项目，但没有任何手动解决冲突。这是预期的结果吗？

当新客户到来时，我从通用分支“A”创建一个分支“C”并应用所需的任何新更改

在 git 中相同

如果一个新功能对所有客户来说都是通用且足够有用的，它将在“A”中开发，然后将合并到“B”、“C”等

在 git 中相同

【讨论】：

我认为，从我读到的所有内容，git 中的分支的生命周期非常短，不应该在生产环境中使用，在多个客户的情况下使用 TFVC 时，情况并非如此。无限期地使用分支是否被认为是一种不好的做法？
这完全取决于您的决定。您可以创建和删除临时分支，但也可以让它们永远存在；您还可以决定是仅将它们更新为快进还是允许强制更新。在前一种情况下，你必须对你在那里推动的东西制定一些纪律，因为它是不可逆转的。例如，您错误地将特定于客户的内容推送到您的A，您将不得不将其还原，或者在合并到客户的分支之前重置到之前的点。
请注意，这些分支应该是指主服务器上的分支，如 here 所述。您不直接在该服务器上操作，而是使用本地跟踪分支进行开发和合并，它们可能具有相同的名称，但了解区别很重要。
我重新阅读了您的答案，出于某种原因，我之前没有对此发表评论，但在这种情况下，“git revert”命令不起作用，因为在开发过程中我没有离开客户特定的内容到最后。它是同时开发的，主要是因为它从来没有打算用作白标产品。