我正在开发一个执行某个核心任务的脚本，并在两个不同的环境中使用该脚本的版本，其中一些设置和步骤需要不同。我正在寻找的是，是否存在一种优雅的方式来处理脚本的两个版本之间的微小差异。我确信开发人员在开发要在多个平台上部署的软件时会面临类似的问题，但我没有特定的名称来固定它。
我现在要做的是打开第二个脚本并手动替换需要不同的行。当我不可避免地忘记注释掉一行或更改一个字符串时，这很麻烦，很费时并且有点头疼。
实施例
[...]
path_to_something = "this/is/different"
use_something(path_to_something)
[...]
do_thing_A() # Only in environment A.
[...]
do_thing_B() # Only in environment B.
[...]
两个版本中省略的[...]部分相同，当我对它们进行更改时，我必须复制并粘贴每个更改的行，或者如果更改很重要，则复制整个内容，并且手动更改A和B部件。
我想出的可能解决方案的一些想法：
编写一个脚本，自动执行我来回移动代码时手动执行的步骤。这完全复制了必要的步骤，并且可以根据需要快速轻松地添加或删除步骤。
这是gitattributes的用例吗？
将版本之间相同的所有代码分解为单独的文件，以便包含异构代码的文件根本不需要更改，因此本身不需要进行版本控制
我不了解处理此类工作流程的其他一些工具或最佳做法。
环顾四周，我发现了一个类似前提的问题，即维护不同版本的代码可以做同样的事情：
Proper way to maintain a project that meets two versions of a platform?
提出这个问题的解决方案：
摆脱所有差异，然后没有问题需要解决。在我的具体情况下，这可能是也可能是不可能的，并且在将来每个人的情况下都不可能实现。所以也许有一个更通用的解决方案。
维护代码的两个不同分支，即使它们几乎完全相同。这与我现在的做法类似，但我最终不得不在分支之间进行大量的复制和粘贴。这只是软件开发所固有的吗？
执行平台检测并包含条件差异。这在代码中添加了许多丑陋的东西，但如果我能成功地检测环境并有条件地实现所有必要的差异，我就不必在将代码发送到不同的环境之前对代码进行任何更改。
开发人员如何在项目的相似但不同的并行分支之间来回移动代码？
答案 0 :(得分：0)
分开任务，即：
$ENVS+1个分支（Core + ... + EnvN）更改的工作流程变为
分支树解决方案的变化
Pure Mercurial-way，因为我懒得维护特定于Env的分支
Mercurial，一个分支+带有一组补丁的MQ队列（每个Env一个mq补丁，可能是＆＃34;每个Env /一个队列/队列，每个队列一个补丁＆＃34;）
存储在不可变更改集中的公共代码，任何更改，将普通核心转换为特定于环境的产品，存储在补丁中并按需应用（如果需要，则进行编辑）。