我正在编写一个简短的脚本,在页面顶部有一些简单的变量。我想和朋友一起工作,但我们不确定如何管理每次为我们中的一个人拉动后需要更改的变量,为git状态添加不必要的垃圾。我想过为我们每个人创建不同的命名分支,然后主人将只设置示例用户名,但是必须完成所有额外的工作合并似乎很愚蠢。我们可以将变量作为选项传递给脚本,但这不是所希望的,也不是将它分离到另一个单独的配置文件中。像.gitignore这样的东西会很棒,但只能忽略文件中的几行。
如何优雅地管理?这个问题通常如何管理?
答案 0 :(得分:60)
我不敢轻易忽略对文件特定行的更改,我担心,因此您可能会遇到单独的配置文件。下面我列举了两种处理这种情况的典型方法,以及一种更具异国情调的方法:
在这里,您可以在git中保留文件config.sample
作为示例,但应用程序实际上会使用config
中文件.gitignore
中的值。除非config
存在,否则应用程序将产生错误。将新配置变量添加到个人config
文件时,必须记住更改示例文件中的值。在这种情况下,让应用程序检查所有必需的配置变量是否实际设置也是一个好主意,以防有人在更改样本后忘记更新其config
文件。
您在git中保留文件config.defaults
,该文件尽可能具有合理的默认配置值。您的应用程序首先从config.defaults
然后从config
(位于.gitignore
)中获取配置,以覆盖任何默认值。使用此方法时,通常不会使config
不存在错误,因此应用程序可以为那些没有费心去创建config
的人开箱即用。
第三种可能性,在这种情况下,我个人不建议使用单个配置文件,该文件在git中提交,但要使用git update-index --assume-unchanged <FILE>
,告诉git忽略对它的更改。 (this useful blog post中对此进行了进一步描述。)这意味着您对配置文件的本地更改不会与git commit -a
一起提交或显示在git status
中。
答案 1 :(得分:5)
Python / Django特定的解决方案是将一个共享的settings.py
文件检入存储库,并在settings_local.py
末尾导入一个本地settings.py
,该文件覆盖了某些文件。具有机器特定值的设置。
答案 2 :(得分:4)
在我的情况下,我在一个单独的(小)文件中“配置”变量,团队中的所有其他开发人员也是如此。像我的数据库位置等东西保存在那里。我们将此文件的名称放在.gitignore
中,以便它不受版本控制,但签入“sample_config”文件,以便新手可以复制并将其用于自己的目的。
答案 3 :(得分:2)
其他选项(不优雅但可能有帮助):
git stash
和git stash pop
作为配置文件git checkout config <your config file>
如果您需要在repo(某处)保留本地配置更改,则第二个选项很好。
答案 4 :(得分:0)
我有几个像这样的短脚本,而不是创建一个单独的配置文件,我创建一个单独的setenv.sh(或setenv.bat)文件。我将一些简单的变量移动到这个新文件中,并在主脚本中调用setenv.sh文件。每个用户不会更改的变量仍保留在主脚本中。根据setenv.sh脚本的大小,我将编写有关如何创建此setenv.sh的文档,或者提交setenv.sh.sample作为模板。
对此的变体不是创建或调用setenv.sh,而是让用户设置主脚本中使用的环境变量。如果变量不存在,主脚本会抱怨。
一些简短的脚本会变成大脚本或成为完整的应用程序。当发生这种情况时,我会采用配置文件的方式。我们有一个管理名为Config的配置文件的应用程序,位于http://www.configapp.com。 Config具有环境和实例的概念。在您的示例中,您有1个本地环境和2个实例。常见变量进入本地环境,机器特定变量(您和您的朋友)进入实例。对于小脚本来说这有点太多了,但适用于应用程序。
答案 5 :(得分:0)
如今,我在python / django中使用ENV vars,例如,您也可以为其添加默认值。 在docker的上下文中,我可以将ENV变量保存在docker-compose.yml文件或版本控制中忽略的其他文件中。
# settings.py
import os
DEBUG = os.getenv('DJANGO_DEBUG') == 'True'
EMAIL_HOST = os.environ.get('DJANGO_EMAIL_HOST', 'localhost')