标题可能有点误导，因为我不知道该取什么名字。
我们创建了一个基于网络的系统，我们将其出售给我们的客户。我们做所有的托管，什么不做。如果我们有一个新客户购买了该系统，我们会从其他客户那里复制一个并更改徽标等。
现在，如果我们进行了更改，假设我们发现了一个错误并修复它，我们必须遍历所有系统并更改有错误的文件。这是我正在考虑改变的事情。
基本上我正在寻找的是一种简单的方法来保持这种组织和易于推动生产。但也希望灵活，如果客户需要特定功能，我们能够轻松更改它，而不是使用此功能更新每个系统。
因此，每当我们对系统核心进行更改时，我想以某种方式将固定文件推送到所有其他系统，而不是手动进行，这是一种麻烦且愚蠢的做法。
现在我认为这对于 git 是可能的，通过某种可以合并到主分支中的分支结构，但我对此不太确定，也找不到任何关于它的信息。
有谁知道这叫什么或者有没有办法做到这一点？
任何版本控制系统都应该可以做到这一点，而不仅仅是 Git。
假设您的核心系统位于 master 分支中。为每个客户创建一个新分支。
如果发现核心系统的bug，在master中修复，并将master合并到所有客户分支中。
同时，您可以在客户分支机构中进行独特的更改。但是，例如，如果您index.php在客户分支中进行了更改，然后您在 master 中修复了该文件中的错误，那么当您将 master 合并到客户分支时，您可能会遇到冲突，您必须手动解决。
而且，由于每个客户分支都是特定于您的客户的，具有独特的自定义更改，因此您不需要从客户分支合并到主分支。您将始终从 master 分支到 customer 分支，而不是相反。
如果您在核心系统中只进行了微小的更改和错误修复，那么这个设置应该可以正常工作，偶尔会有轻微的冲突。但是，如果您对核心系统进行大量更改，您可能会遇到很多冲突，从而使设置变得难以维护。这一切都取决于客户分支和主分支中独特变化的重叠。如果重叠很少或没有重叠，那么即使是大范围的更改也很容易合并。