如何使用 git 来维护一个稍微不同的生产源代码副本？

Posted 2023-02-26

【中文标题】如何使用 git 来维护一个稍微不同的生产源代码副本？

【英文标题】：How to use git to maintain a slightly different copy of production source code?

【发布时间】：2011-08-17 23:30:27

【问题描述】：

我有一个 Ruby on Rails 应用程序，它可以发送电子邮件。

在生产中，我想使用一些 X SMTP 服务器，但在开发中我想使用其他一些 SMTP 服务器（因此我的 SMTP 设置的配置文件在开发和生产环境中是不同的）

所以我需要维护 2 个配置文件（开发/生产环境的 SMTP 设置各一个文件）。

到目前为止，我将 Y STMP 的设置保存在我的开发机器上的一个文件中。我从 github 存储库克隆了生产代码，使用 Y SMTP 的设置修改工作副本并继续。然后，当我必须将更改推送到 github 时，我会反转该过程。它有效，但我认为应该有更好的方法？

什么是“git方式”来处理开发和生产代码库之间的这种“小差异”？

---

更新

根据@Mike Axiak，这就是您的意思吗：（为简单起见，假设我没有使用ln，而是使用copy 方法）

设置源代码，使本地机器上有2个设置文件：

smtp.settings.prod smtp.settings.dev

两者都添加到.gitignore

要处理本地副本：

从 github 拉取代码 将 smtp.settings.dev 复制到 smtp.settings 使用。

将更改推送到服务器：

就在推送之前，将文件 smtp.settings.prod 复制到 smtp.settings 推送

如果这就是你的意思，有没有办法通过 git 自动化复制过程？

【参考方案1】：

Rails 已经使用配置/环境目录中的文件支持这种事情。只需将您的设置添加到相应的文件中即可。

【参考方案2】：

在大多数地方，我通过一个小的覆盖配置文件来处理这个问题，通常带有 .prod 或 .dev 后缀。然后在实际签出的环境中，您使用 ln 将当前文件符号链接（或在 Windows 中复制）到实际设置文件名。然后你告诉 git 忽略设置文件（使用 .gitignore）

【讨论】：

或者你有一个版本控制的脚本来做。

这是一个人工必须重复的过程；因此容易出错，需要为团队中的每个开发人员完成，从而增加出错的机会并颠覆 Rails 中用于处理此用例的configuration/environments 功能，因此它是非标准 另一个不这样做的原因

【参考方案3】：

如果配置文件不是一直在变化，我通常会在存储库中保留一个通用设置文件版本，比如settings.conf.dist，然后将settings.conf 添加到我的.gitignore。现在，当我克隆一个新的存储库时，我只需 cp settings.conf.dist settings.conf 制作应用设置的副本（被 git 忽略），然后根据需要进行修改。

优点是你在提交/推送/拉取时永远不必担心它。缺点是当您进行更改（例如添加新设置）时，您要记住将其放入 .dist 版本中，并将其单独添加到每个本地 settings.conf 文件中。就像我说的，当您不一直添加新设置时效果最好。

编辑：我只有在这些本地设置文件中会在机器之间更改的设置。如果您有对所有站点都相同的其他设置，我会为此设置另一个配置文件，然后包含“本地”设置文件。

【参考方案4】：

做 Gitorious 做的事，它使用 configuration/environments 支持，并且您在运行脚本时向脚本提供 RAILS_ENV 环境变量，以便它知道要使用哪个配置。

一个目录，多种配置。将发布升级到生产时删除未使用的配置。

我也做了一些类似但更自动化的事情，方法是根据部署它的服务器的主机名进行配置。 dev.mycompany.com vs test.mycompany.com vs mycompany.com 有很多比处理多个文件更自动化的方法，这只是人为错误和痛苦的秘诀。

【参考方案5】：

我是这样解决的。在 .bash_aliases 的帮助下。

git clone
git checkout -b production.conf

根据需要修改 config.file。

git commit -a
git checkout master

用工作副本做点什么。

git checkout production.conf -- config.file
git commit -a
git push