我在最近的一个项目中使用 Mercurial。在我部署项目的 Web 服务器上，我的配置文件与生产设置略有不同。问题是当我pull 和update 时，我经常还要merge 和commit。
这是正确的工作流程吗？奇怪的是，为了能够继续更新，我必须提交变更集，我认为合并会将它们集成到我的生产分支中，并在每次更新时继续这样做。这是我还不习惯的分布式版本控制范例吗？
【问题讨论】：
标签： mercurial merge dvcs commit
这是in this question 处理的，但我认为你的问题更好，因为它寻求更清晰一些。
简而言之：是的，这很正常。这里有一点扩展：
您从主存储库中开始（其中的框是变更集）：
main: --[E]--[F]--[G]
然后您克隆到生产服务器并添加一个变更集 H，它执行部署自定义。所以部署 repo 看起来像这样：
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 Extension，它会在生产中产生线性历史记录（尽管您仍然会做本质上是合并的事情）。我不喜欢它，因为我不喜欢在它们提交后更改变更集，但由于 H 永远不会离开生产框，所以没关系。
其他答案是 mercurial queues 和 making the production changes live in the dev repo and get triggered by something that's different in the production environment（如 Host: 标头）。
【讨论】：
一种选择是将特定于服务器的部署设置完全排除在版本控制存储库之外。
这意味着上传它们并在服务器上手动更改它们，但无需不断合并。它还使数据库密码等内容不受版本控制，这可能是件好事。
例如，当我处理 Django 应用程序时，我签入了一个 settings.py 文件，其中包含：
from deploy import *。from deploy import * 行会拉入 deploy.py 文件中的所有项目（如果存在）。在测试/登台/生产服务器上，我将创建此文件并将特定于服务器的设置放入其中。因为导入发生在settings.py 的末尾，这些将覆盖主设置文件中的任何本地开发特定设置。
这样做意味着需要在本地运行和开发的所有内容都被签入版本控制，但不会签入特定于服务器的信息和/或敏感信息（如密码）（因此永远不需要合并）。它需要一些额外的工作来设置（添加导入行并最初在服务器上创建deploy.py 文件）。
此特定方案适用于 Django 项目，但类似的想法可能对您有用。
【讨论】：