维护 2 个代码相似但不完全相同的分支
Maintain 2 branches with similar code, but not identical
我有 2 个环境和 2 个分支，测试和生产。测试分支 (Angular) 上的代码与生产分支的代码有 99% 相同，但是我需要维护生产分支上的一些差异，例如删除 "sign up" 和 "create new" 按钮，而现场网站仍处于测试阶段。但是我在版本控制中 100% 需要这些视图，在测试分支/环境中我需要它们。
有没有办法在不使用 .gitignore 的情况下保持 2 个稍微不同的文件，即使在我合并时？就像我只需要 .gitignore 几行代码一样！
我现在的方法是简单的记住改动，每次合并到生产分支的时候重新做，切换回测试分支的时候撤销改动。虽然它变得有点烦人！
我当然可以设置一个环境变量来切换代码行，但是对于任何人来说，在（客户端）代码中看到它并使用我隐藏的链接和按钮都是微不足道的。
我的部署过程如下：
- 提交对 Atlassian (Bitbucket) SourceTree 软件中任一分支的更改。
- 推送更改
- 推送是为
通过 Codeship.com
自动部署
- Codeship 部署通过
Elastic Beanstalk 或直接到 S3
因此环境变量和构建脚本可以 运行 在 codeship 或 EBS 阶段。
任何建议表示赞赏。
Is there a way to maintain 2 slightly different files even when I merge, without using .gitignore? Its like I need to .gitignore just a few lines of code!
你有一个隐含的前提，即 .gitignore 会在这里帮助你。它不会。 only .gitignore 所做的是保持未跟踪文件未跟踪（默认情况下）。它不影响合并。
所以让我们删除它并解决正确的问题：
Is there a way to maintain 2 slightly different files even when I merge
出于所有意图和目的，不。您可以尝试，但对于潜在问题有更好的解决方案。
你需要做的是，为合并定义一个方向，然后在合并的 "target" 一侧引入差异。但是 (1) 每次合并受影响的文件时，您都会面临不必要的合并冲突的可能性，并且 (2) 您正在用非常严格的合并规则束缚自己的手。
（最后一点：假设你决定 "always merge toward production"。这听起来 太 与 "merge toward master" 的 gitflow 规则不同......但是修补程序呢？即使是从生产到测试的间接合并也会破坏这种方法，因此创建修补程序的过程会变得更加复杂。）
更好的解决方案是使用单一代码库，但使用特定于环境的配置来决定表达哪种行为。配置可以由您的构建过程管理，或者在运行时直接从环境中获取。
我的建议是将特定于分支的代码隔离在一小组文件中，然后使用配置文件中的设置（而不是环境变量）在生产和开发分支之间切换。
我有 2 个环境和 2 个分支，测试和生产。测试分支 (Angular) 上的代码与生产分支的代码有 99% 相同，但是我需要维护生产分支上的一些差异，例如删除 "sign up" 和 "create new" 按钮，而现场网站仍处于测试阶段。但是我在版本控制中 100% 需要这些视图，在测试分支/环境中我需要它们。
有没有办法在不使用 .gitignore 的情况下保持 2 个稍微不同的文件，即使在我合并时？就像我只需要 .gitignore 几行代码一样！
我现在的方法是简单的记住改动，每次合并到生产分支的时候重新做，切换回测试分支的时候撤销改动。虽然它变得有点烦人！
我当然可以设置一个环境变量来切换代码行，但是对于任何人来说，在（客户端）代码中看到它并使用我隐藏的链接和按钮都是微不足道的。
我的部署过程如下：
- 提交对 Atlassian (Bitbucket) SourceTree 软件中任一分支的更改。
- 推送更改
- 推送是为 通过 Codeship.com 自动部署
- Codeship 部署通过 Elastic Beanstalk 或直接到 S3
因此环境变量和构建脚本可以 运行 在 codeship 或 EBS 阶段。
任何建议表示赞赏。
Is there a way to maintain 2 slightly different files even when I merge, without using .gitignore? Its like I need to .gitignore just a few lines of code!
你有一个隐含的前提，即 .gitignore 会在这里帮助你。它不会。 only .gitignore 所做的是保持未跟踪文件未跟踪（默认情况下）。它不影响合并。
所以让我们删除它并解决正确的问题：
Is there a way to maintain 2 slightly different files even when I merge
出于所有意图和目的，不。您可以尝试，但对于潜在问题有更好的解决方案。
你需要做的是，为合并定义一个方向，然后在合并的 "target" 一侧引入差异。但是 (1) 每次合并受影响的文件时，您都会面临不必要的合并冲突的可能性，并且 (2) 您正在用非常严格的合并规则束缚自己的手。
（最后一点：假设你决定 "always merge toward production"。这听起来 太 与 "merge toward master" 的 gitflow 规则不同......但是修补程序呢？即使是从生产到测试的间接合并也会破坏这种方法，因此创建修补程序的过程会变得更加复杂。）
更好的解决方案是使用单一代码库，但使用特定于环境的配置来决定表达哪种行为。配置可以由您的构建过程管理，或者在运行时直接从环境中获取。
我的建议是将特定于分支的代码隔离在一小组文件中，然后使用配置文件中的设置（而不是环境变量）在生产和开发分支之间切换。