如何使用 git 维护生产源代码的略有不同的副本？
我有一个 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 自动执行复制过程？
I have a Ruby on Rails application, which sends out emails.
In production, I want to use some X SMTP server, but in development I want to use some other SMTP server (thus my configuration file for the SMTP settings is different in the development and production environments)
So I need to maintain 2 configuration files (one file each for the development/production environments' SMTP settings).
As of now, I keep settings for Y STMP in a file on my development machine. I clone the production code from the github repo, modify the working copy with settings for Y SMTP and proceed. Then when I have to push changes to github, I reverse the process. It works, but I'm thinking there should be a better way?
What is the "git way" to handle this sort of "small differences" between development and production code bases?
UPDATE
Per @Mike Axiak, is this the flow that you mean: (presume for simplicity that I'm not using ln, but using the copy method)
Set up source code so that there are 2 settings files on local machine:
- smtp.settings.prod
- smtp.settings.dev
Both are added to .gitignore
To work on local copy:
- Pull code from github
- Copy smtp.settings.dev to smtp.settings
- Use.
To push changes to server:
- Just before push, copy file smtp.settings.prod to smtp.settings
- Push
If this is what you meant, is there some way to automate the copying process via git?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Rails 已经使用配置/环境目录中的文件支持这种事情。只需将您的设置添加到适当的文件中即可。
Rails already support this kind of thing using the files the configuration/environments directory. Just add your settings in the appropriate file.
在大多数地方，我通过一个小的覆盖配置文件来处理这个问题，通常带有 .prod 或 .dev 后缀。然后在实际签出的环境中，使用 ln 将当前文件符号链接（或在 Windows 中复制）到实际设置文件名。然后告诉 git 忽略设置文件（使用 .gitignore）
In most places I've dealt with this by having a small override configuration file, usually with a .prod or .dev suffix. Then in the actual checked out environment you use ln to symlink (or in windows copy) the current file to the real settings file name. Then you tell git to ignore the settings file (using .gitignore)
如果配置文件不是一直在变化，我通常会在存储库中保留一个通用设置文件版本，例如
settings.conf.dist，然后添加settings.conf到我的.gitignore。现在，当我克隆一个新的存储库时，我只需cp settings.conf.dist settings.conf来制作应用程序设置的副本（被 git 忽略），然后根据需要进行修改。优点是你在提交/推/拉时永远不必担心它。缺点是当您进行更改（例如添加新设置）时，您需要记住将其放入其
.dist版本中，以及将其单独添加到每个本地settings.conf 中文件。就像我说的，当您不总是添加新设置时效果最好。编辑：我在这些本地设置文件中只有会跨计算机更改的设置。如果您有其他所有站点都相同的设置，我会为此准备另一个配置文件，其中将包含“本地”设置文件。
If the config files aren't changing all the time, I usually keep a generic settings file versioned in the repository, say
settings.conf.dist, and then addsettings.confto my.gitignore. Now when I clone a fresh repository, I would justcp settings.conf.dist settings.confto make a copy (ignored by git) of the app settings, and then modify as needed.The advantage is you never have to worry about it when committing/pushing/pulling. The disadvantage is when you make changes like adding a new setting, you want to remember to put it into the
.distversion of it, as well as add it separately to each localsettings.conffile. Like I said, works best when you're not adding new settings all the time.Edit: I only have settings that would change across machines in these local settings files. If you had other settings that would be the same for all sites, I'd have another config file for that, which would then include the "local" settings file.
执行 Gitorious 所做的操作，它使用
configuration/environments支持，并且您在运行脚本时向脚本提供RAILS_ENV环境变量，以便它知道要使用哪个配置。一个目录，多种配置。将版本升级到生产时删除未使用的配置。
我也做了类似的事情，但更自动化，通过根据部署的服务器的主机名进行配置。 dev.mycompany.com vs test.mycompany.com vs mycompany.com 有很多比处理多个文件更自动化的方法，这只是人为错误和痛苦的根源。
Do what Gitorious does, it uses the
configuration/environmentssupport and you provide anRAILS_ENVenvironment variable to the script when running it so it knows which configuration to use.One directory, multiple configurations. Delete the unused configs when promoting a release to production.
I have also done something similar but more automatic by basing configuration off the hostname of the server that it is deployed it. dev.mycompany.com vs test.mycompany.com vs mycompany.com there are lots of more automated ways of doing this than juggling multiple files, that is just a recipe for human error and suffering.
我是这样解决的。在 .bash_aliases 的帮助下。
根据需要修改 config.file。
用工作副本做一些事情。
I solved it like this. With a little help from .bash_aliases.
Modify config.file as needed.
Do something with working copy.