在这种情况下使用git rebase。可能会发生一些代码冲突，但这些冲突可以手动解决，前提是冲突文件是文本文件-代码文件，json文件等。
使用它很多次，如果使用正确，没有问题发生，子分支可以很容易地合并到主分支。
作为我的经验法则，我使用git rebase -i HEAD~<no.of.commits.to.be.squashed>将子分支上的提交压缩为一次提交，这样如果发生任何变基冲突，我可以只在一次提交中解决它们。

您的方法是为您可能拥有的每个可能的值组合创建一个分支。这意味着无论何时添加新属性，您都需要拥有与分支数量一样多的提交。此外，当您更改值时，您还需要将其应用于尽可能多的副本。最后，您可能有一些不应该进行版本控制的秘密值，例如密码，API秘密等。
与您选择的不安全和多余的方法不同，解决您的问题的替代方法可以说是更好的方法：

1.创建一个env文件，在其中设置本地所有设置的值

创建. env.php并将所有值设置为本地值

2.将. env.php添加到.gitignore

我们不想对. env.php进行版本控制，因为它是不稳定的，并且它可能包含不应该进行版本控制的秘密

3.更改所有对这些设置的引用

通过你的代码，并取代所有的硬编码的网址和诸如此类的这些设置。

4.将env.php复制到仓库的所有副本中

将此文件复制到存储库的所有副本后，更改应在其中使用的实际值

5.同步

拉取所有分支上的更改或将它们合并到这些分支中，因此设置将基于. env.php动态推断

6.您可能希望有多个非版本化配置

结论

不要把所有的分支复制到尽可能多的分支上，而是确保你动态地推断它们，并且你有一个包含这些值的. env. php的非版本化副本。在第一个示例中，你可以在.env.php中实现这个函数：

function env() {
    return [
        "key1" => "value1",
        "key2" => "value2",
        //...
    ];
}

字符串
并包含或需要此文件，因此，您可以执行类似env()["URL1"]的操作，而不是URL1