每次在生产服务器上更新 Mercurial 分支时是否都必须合并并提交？

Question

我在最近的一个项目中使用了 Mercurial。在我部署项目的网络服务器上，我的配置文件与生产设置略有不同。问题是当我拉动和更新时，我经常还必须合并和提交。

这是正确的工作流程吗？似乎很奇怪，为了能够继续更新，我必须提交变更集，我认为合并会将它们集成到我的生产分支中，并在每次更新时继续这样做。这是我还不习惯的分布式版本控制范例吗？

Answer 1

一种选择是将特定于服务器的部署设置完全保留在版本控制存储库之外。

这意味着在服务器上手动上传并更改它们，但无需不断合并。它还使数据库密码等内容不受版本控制，这可能是一件好事。

例如，当我使用 Django 应用程序时，我会签入一个 settings.py 文件，其中包含：

• 所有在服务器之间不会发生变化的设置（站点名称、安装的 Django 应用程序等）。
• 用于本地开发的“服务器特定”设置（数据库位置等）。
• 最后的 from deploy import * 行。

from deploy import * 行会提取 deploy.py 文件中的所有项目（如果存在）。在测试/登台/生产服务器上，我将创建此文件并将特定于服务器的设置放入其中。因为导入发生在 settings.py 的末尾，所以这些将覆盖主设置文件中任何本地开发特定的设置。

这样做意味着本地运行和开发所需的所有内容都会签入版本控制，但不会签入特定于服务器和/或敏感信息（例如密码）（因此永远不需要合并）。它需要一些额外的工作来设置（添加导入行并最初在服务器上创建 deploy.py 文件）。

这个特定的方案适用于 Django 项目，但也许类似的想法也适合您。

Answer 2

这是在这个问题中处理的 ，但我认为你的问题更好，因为它寻求更清晰一点。

简而言之：是的，这很正常。这里有一些扩展：

您从主存储库中的这个开始（其中的框是变更集）：

main: --[E]--[F]--[G]

然后克隆到生产服务器并添加一个变更集 H，它执行部署自定义。因此，部署存储库看起来像这样：

production: --[E]--[F]--[G]--[H]

然后在主存储库上发生更多工作，添加变更集 I 和 J，使主存储库看起来像：

main: --[E]--[F]--[G]--[I]--[J]

当拉到生产时看起来像：

production:  --[E]--[F]--[G]--[I]--[J]
                            \         
                             \-[H]

有两个头，您可以合并以获得：

production:  --[E]--[F]--[G]--[I]--[J]
                            \         \
                             \-[H]-----[K]

其中 K 只是 J 加上您最初在 H 中所做的更改。

现在 main 中发生了更多工作，给出：

main: --[E]--[F]--[G]--[I]--[J]--[L]--[M]

您将其拉入生产给出：

production:  --[E]--[F]--[G]--[I]--[J]--[L]--[M]
                            \         \
                             \-[H]-----[K]

然后合并并得到：

production:  --[E]--[F]--[G]--[I]--[J]--[L]--[M]
                            \         \         \
                             \-[H]-----[K]-------[N]

所以每次您从 main 中引入更改时，您都会进行一次合并，并创建一个新的变更集（这次是 N）。

我认为这没什么问题，而且很“正常”。

但是，您可以通过使用我上面链接的问题中的一些答案来避免这种情况并且有一个新技巧可以用来保持修改原始 H 的父母（和内容），以便它始终移动到新提示的末尾。

诀窍是 Rebase 扩展，它会产生生产的线性历史记录（尽管你仍然会本质上是通过合并来获得它）。我不喜欢它，因为我不喜欢在提交后更改变更集，但由于 H 永远不会离开生产框，所以没关系。

其他答案是 mercurial 队列 和 生产更改存在于开发存储库中，并由生产环境中的不同内容触发（例如 Host: 标头）。