git 协作时如何管理配置文件？

How to manage configuration files when collaborating?

提问by Gitter

I'm writing a short script with a few simple variables at the top of the page. I want to work on them with a friend, but we aren't sure how to manage the variables needing to be changed after pulling each time for one of us, adding unnecessary junk to git status. I thought about just creating different named branches for each of us, and then the master will just have example usernames set, but it seems silly to have to do all that extra work merging. We could have the variables passed to the script as options, but that isn't desired, nor is separating it out to another separate configuration file. It would be great to have something like a .gitignore but for only ignore a few lines in a file.

我正在编写一个简短的脚本，在页面顶部包含一些简单的变量。我想和一个朋友一起研究它们，但我们不确定如何管理每次为我们中的一个拉取后需要更改的变量，将不必要的垃圾添加到 git status。我想过为我们每个人创建不同的命名分支，然后 master 将只设置示例用户名，但是必须合并所有额外的工作似乎很愚蠢。我们可以将变量作为选项传递给脚本，但这不是我们想要的，也不是将其分离到另一个单独的配置文件中。拥有像 .gitignore 这样的东西会很棒，但只忽略文件中的几行。

How can this be elegantly managed? How is this problem usually managed?

这如何优雅地管理？这个问题通常是如何处理的？

回答by Mark Longair

You can't easily just ignore changes to particular lines of a file, I'm afraid, so you're probably stuck with having a separate configuration file. Below I've listed two typical ways of dealing with this, and one slightly more exotic one:

恐怕您不能轻易忽略对文件特定行的更改，因此您可能会坚持使用单独的配置文件。下面我列出了两种典型的处理方法，一种稍微有点奇特的方法：

Have a sample configuration file in git

在 git 中有一个示例配置文件

Here, you would keep a file config.samplein git as an example, but the application would actually use the values in a file configwhich is in .gitignore. The application would then produce an error unless configis present. You have to remember to change values in the sample file when you add new configuration variables to your personal configfile. In this case it's also a good idea to have your application check that all the required configuration variables are actually set, in case someone has forgotten to update their configfile after changes to the sample.

在这里，你还保留了一份文件，config.sample在Git中作为一个例子，但应用程序实际上在文件中使用的值config是在.gitignore。除非config存在，否则应用程序将产生错误。当您将新的配置变量添加到您的个人config文件时，您必须记住更改示例文件中的值。在这种情况下，让您的应用程序检查所有必需的配置变量是否实际设置也是一个好主意，以防有人config在更改示例后忘记更新他们的文件。

Have a file of default values in git

在 git 中有一个默认值文件

You keep a file config.defaultsin git, which has sensible default configuration values as far as possible. Your application first sources configuration from config.defaultsand then from config(which is in .gitignore) to possibly override any of the default values. With this method, typically you wouldn't make it an error for confignot to exist, so the application can work out of the box for people who haven't bothered to create config.

您config.defaults在 git 中保留一个文件，该文件尽可能具有合理的默认配置值。您的应用程序首先从config.defaults，然后从config（在 中.gitignore）获取配置以可能覆盖任何默认值。使用这种方法，通常不会因为config不存在而导致错误，因此该应用程序可以为那些不想创建config.

Using a single configuration file with --assume-unchanged

使用带有 --assume-unchanged 的​​单个配置文件

A third possibility, which I wouldn't recommend in this case, personally, would be to have a single configuration file which is committed in git, but to use git update-index --assume-unchanged <FILE>, to tell git to ignore changes to it. (This is described further in this useful blog post.) That means that your local changes to the configuration file won't be committed with git commit -aor show up in git status.

第三种可能性，我个人在这种情况下不推荐的，是在 git 中提交一个配置文件，但使用git update-index --assume-unchanged <FILE>, 告诉 git 忽略对它的更改。（这是在进一步说明这个有用的博客文章。）这意味着你的本地修改配置文件不会被提交git commit -a或显示git status。

回答by Tomasz Zieliński

Python/Django-specific solution is to have a shared settings.pyfiles that is checked into the repository, and a local settings_local.pyimported at the end of settings.py, that overrides some of the settings with machine-specific values.

Python/Django 特定的解决方案是将共享settings.py文件签入存储库，并settings_local.py在settings.py.

回答by Noufal Ibrahim

In my case, I have "config" variables in a separate (small) file as do all the other developers on the team. Things like my database location etc. are kept there. We put the name of this file in our .gitignoreso that it's not version controlled but checkin a "sample_config" file so that newcomers can make a copy and use it for their own purposes.

就我而言，我在一个单独的（小）文件中拥有“配置”变量，团队中的所有其他开发人员也是如此。诸如我的数据库位置等之类的东西都保存在那里。我们将此文件的名称放在我们的文件中，.gitignore以便它不受版本控制，而是签入“sample_config”文件，以便新人可以制作副本并将其用于自己的目的。

回答by Mick Kelly

Other options (not elegant but may be helpful):

其他选项（不优雅但可能有帮助）：

• Use git stashand git stash popfor your config file
• Have a branch named, say, configwhich has your local config file changes and then use git checkout config <your config file>

• 使用git stash和git stash pop用于您的配置文件
• 有一个名为config的分支，它更改了您的本地配置文件，然后使用git checkout config <your config file>

Second option is good if you need to keep the local config changes in the repo (somewhere).

如果您需要在存储库（某处）中保留本地配置更改，则第二个选项很好。

回答by Bienvenido David

I have a couple of short scripts like this and instead of creating a separate configuration file, I create a separate setenv.sh (or setenv.bat) file. I move the few, simple variables to this new file, and call the setenv.sh file in the main script. Variables that will not change per user remains in the main script. Depending on how small this setenv.sh script is, I will either write documentation on how to create this setenv.sh, or will commit a setenv.sh.sample to be used as a template.

我有几个这样的简短脚本，我没有创建单独的配置文件，而是创建了一个单独的 setenv.sh（或 setenv.bat）文件。我将几个简单的变量移动到这个新文件中，并在主脚本中调用 setenv.sh 文件。不会更改每个用户的变量保留在主脚本中。根据此 setenv.sh 脚本的大小，我将编写有关如何创建此 setenv.sh 的文档，或者将提交一个 setenv.sh.sample 用作模板。

A variation to this is not to create or call a setenv.sh, and let the user set environment variables used in the main script. The main script will complain if the variables don't exist.

对此的一个变体不是创建或调用 setenv.sh，而是让用户设置主脚本中使用的环境变量。如果变量不存在，主脚本会报错。

Some short scripts grow into big scripts or become full-fledged applications. When this happens, I go the way of configuration files. We have an application that manages configuration files called Config, at http://www.configapp.com. Config has the concept of environments and instances. In your example, you have 1 Local environment and 2 instances. Common variables go into Local environment and machine specific variables (you and your friend) go into the instances. This is a little too much for small scripts but works well for applications.

一些短脚本成长为大脚本或成为成熟的应用程序。发生这种情况时，我会采用配置文件的方式。我们有一个管理配置文件的应用程序，名为 Config，位于http://www.configapp.com。Config 有环境和实例的概念。在您的示例中，您有 1 个本地环境和 2 个实例。公共变量进入本地环境，机器特定变量（你和你的朋友）进入实例。这对于小脚本来说有点太多了，但对于应用程序来说效果很好。

回答by yvess

Nowadays I use ENV vars for example in python/django, you can also add defaults to them. In the context of docker I can save the ENV vars in a docker-compose.yml file or an extra file which is ignored in version control.

现在我在 python/django 中使用 ENV 变量，你也可以为它们添加默认值。在 docker 的上下文中，我可以将 ENV 变量保存在 docker-compose.yml 文件或在版本控制中被忽略的额外文件中。

# settings.py
import os
DEBUG = os.getenv('DJANGO_DEBUG') == 'True'
EMAIL_HOST = os.environ.get('DJANGO_EMAIL_HOST', 'localhost')