如何在针对不同环境的相似版本之间移动代码？
How to move code between similar versions targeting different environments?
我正在开发一个执行特定核心任务的脚本，并在两个不同的环境中使用该脚本的版本，其中一些设置和步骤需要不同。我正在寻找的是是否存在一种优雅的方式来处理两个版本脚本之间的细微差别。我敢肯定开发人员在开发要部署在多个平台上的软件时会遇到类似的问题，但我没有具体的名称可以固定。
我现在要做的是打开第二个脚本并手动替换需要不同的行。这既麻烦又费时，每当我不可避免地忘记注释掉一行或更改一个字符串时，都会让人头疼。
示例
[...]
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?
针对该问题提供的解决方案：
去掉所有的差异，就没有问题可以解决了。这在我的具体情况下可能可行，也可能不可行，而且将来肯定不会对每个人都适用。所以也许有一个更通用的解决方案。
维护代码的两个不同分支，即使它们几乎相同。这与我现在所做的类似，但我最终不得不在分支之间来回复制和粘贴大量内容。这只是软件开发所固有的吗？
执行平台检测并将差异包装在条件中。这在代码中添加了很多丑陋的东西，但如果我能够成功检测环境并有条件地实现所有必要的差异，我就不必在将代码发送到不同环境之前对代码进行任何更改。
开发人员如何在项目的相似但不同的并行分支之间来回移动代码？
与语言和 SCM 无关
- 使用一（二、三）通用class（es），但不同的接口（每个环境的接口）
- 将所有 env-specific 从硬编码移动到外部配置，单独存储
与 SCM 无关
单独的任务，即：
- 获取干净的公共核心
- 获取每个环境的顶级核心更改
- 将其移至任何 SCM 中的
$ENVS+1 个分支 (Core+...+EnvN)
工作流程更改为
- 提交对核心的常见更改
- 将核心合并到每个环境分支
- 测试 env 分支，如果需要修复特定于 env 的更改
私人和个人，适合我和我的习惯
分支树解的变体
纯 Mercurial 方式，因为我懒得维护特定于 Env 的分支
Mercurial，一个分支 + MQ 队列和一组补丁（每个 Env 一个 mq 补丁，可能是 "set of queues /queue per Env/, one patch per queue"）
公共代码存储在不可变的变更集中，任何变更，将普通核心转换为特定于环境的产品，存储在补丁中并按需应用（并在需要时编辑）。
- 相对于分支方式的小优势 - 单分支，无合并，更多
清除历史记录
- 缺点 - 纯粹的 Mercurial，现在流行 Git（git-男孩
哭了）
我正在开发一个执行特定核心任务的脚本，并在两个不同的环境中使用该脚本的版本，其中一些设置和步骤需要不同。我正在寻找的是是否存在一种优雅的方式来处理两个版本脚本之间的细微差别。我敢肯定开发人员在开发要部署在多个平台上的软件时会遇到类似的问题，但我没有具体的名称可以固定。
我现在要做的是打开第二个脚本并手动替换需要不同的行。这既麻烦又费时，每当我不可避免地忘记注释掉一行或更改一个字符串时，都会让人头疼。
示例
[...]
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?
针对该问题提供的解决方案：
去掉所有的差异，就没有问题可以解决了。这在我的具体情况下可能可行，也可能不可行，而且将来肯定不会对每个人都适用。所以也许有一个更通用的解决方案。
维护代码的两个不同分支，即使它们几乎相同。这与我现在所做的类似，但我最终不得不在分支之间来回复制和粘贴大量内容。这只是软件开发所固有的吗？
执行平台检测并将差异包装在条件中。这在代码中添加了很多丑陋的东西，但如果我能够成功检测环境并有条件地实现所有必要的差异，我就不必在将代码发送到不同环境之前对代码进行任何更改。
开发人员如何在项目的相似但不同的并行分支之间来回移动代码？
与语言和 SCM 无关
- 使用一（二、三）通用class（es），但不同的接口（每个环境的接口）
- 将所有 env-specific 从硬编码移动到外部配置，单独存储
与 SCM 无关
单独的任务，即：
- 获取干净的公共核心
- 获取每个环境的顶级核心更改
- 将其移至任何 SCM 中的
$ENVS+1个分支 (Core+...+EnvN)
工作流程更改为
- 提交对核心的常见更改
- 将核心合并到每个环境分支
- 测试 env 分支，如果需要修复特定于 env 的更改
私人和个人，适合我和我的习惯
分支树解的变体
纯 Mercurial 方式，因为我懒得维护特定于 Env 的分支
Mercurial，一个分支 + MQ 队列和一组补丁（每个 Env 一个 mq 补丁，可能是 "set of queues /queue per Env/, one patch per queue"）
公共代码存储在不可变的变更集中，任何变更，将普通核心转换为特定于环境的产品，存储在补丁中并按需应用（并在需要时编辑）。
- 相对于分支方式的小优势 - 单分支，无合并，更多 清除历史记录
- 缺点 - 纯粹的 Mercurial，现在流行 Git（git-男孩 哭了）