如果你愿意，可以选择维护不同的文件: 如果您正在使用git或任何其他VCS将代码从本地推送到服务器，您可以将设置文件添加到.gitignore。

这将允许您在两个地方有不同的内容而没有任何问题。所以在服务器上，你可以配置一个独立版本的settings.py，任何在本地所做的更改都不会反映在服务器上，反之亦然。

此外，它将删除settings.py文件从github也，大错误，这我已经看到许多新手做。

我对这个问题的解决方案在某种程度上也是这里已经提到的一些解决方案的混合:

我保留了一个名为local_settings.py的文件，其内容为USING_LOCAL = True在dev中，USING_LOCAL = False在prod中 在settings.py中，我对该文件进行导入以获得USING_LOCAL设置

然后我将所有与环境相关的设置都基于此:

DEBUG = USING_LOCAL
if USING_LOCAL:
    # dev database settings
else:
    # prod database settings

我更喜欢这样，而不是有两个单独的settings.py文件，我需要维护，因为我可以将我的设置结构化地保存在一个文件中，而不是将它们分布在几个文件中。就像这样，当我更新一个设置时，我不会忘记在两个环境中都这样做。

当然每种方法都有它的缺点，这种方法也不例外。这里的问题是，无论何时将更改推到生产环境中，我都不能覆盖local_settings.py文件，这意味着我不能盲目地复制所有文件，但这是我可以接受的。

在settings.py:

try:
    from local_settings import *
except ImportError as e:
    pass

你可以覆盖local_settings.py;它应该不在你的版本控制范围之内。但既然你提到了复制，我猜你没有使用;)

创建多个版本的settings.py是12因素应用程序方法论的反模式。 请使用python- decoupling或django-environ。

我发现这里的回答很有帮助。(这个问题是否得到了更明确的解决?上一次回复是在一年前。)在考虑了列出的所有方法之后，我提出了一个在这里没有列出的解决方案。

我的标准是:

所有东西都应该在源代码控制中。我不喜欢精细的东西到处乱放。 理想情况下，将设置保存在一个文件中。如果我不看东西，我就会忘记它们:) 无需部署手动编辑。应该能够用一个fabric命令测试/推送/部署。 避免将开发设置泄漏到生产环境中。 让Django布局尽可能接近“标准”(*咳嗽*)。

我认为打开主机是有意义的，但后来发现真正的问题是针对不同环境的不同设置，并有了一个顿悟时刻。我把这段代码放在settings.py文件的末尾:

try:
    os.environ['DJANGO_DEVELOPMENT_SERVER'] # throws error if unset
    DEBUG = True
    TEMPLATE_DEBUG = True
    # This is naive but possible. Could also redeclare full app set to control ordering. 
    # Note that it requires a list rather than the generated tuple.
    INSTALLED_APPS.extend([
        'debug_toolbar',
        'django_nose',
    ])
    # Production database settings, alternate static/media paths, etc...
except KeyError: 
    print 'DJANGO_DEVELOPMENT_SERVER environment var not set; using production settings'

这样，应用程序默认为产品设置，这意味着你明确地将你的开发环境“白名单”。忘记在本地设置环境变量要比反过来忘记在生产环境中设置一些内容而使用一些开发设置安全得多。

在本地开发时，无论是在shell中，还是在.bash_profile中，或者其他任何地方:

$ export DJANGO_DEVELOPMENT_SERVER=yep

(或者如果你在Windows上开发，可以通过控制面板或者其他什么工具来设置…Windows总是让它变得如此模糊，以至于你可以设置环境变量。)

使用这种方法，开发设置都在一个(标准)位置，只需在需要的地方覆盖生产设置。任何与开发设置有关的事情都应该完全安全地提交到源代码控制中，而不会对生产产生影响。

我使用Harper Shelby发布的“if DEBUG”风格设置的稍微修改版本。显然，根据环境(win/linux/等等)，代码可能需要稍作调整。

我在过去使用“if DEBUG”，但我发现偶尔我需要用DEUBG设置为False进行测试。我真正想要区分的是环境是生产环境还是开发环境，这给了我选择DEBUG级别的自由。

PRODUCTION_SERVERS = ['WEBSERVER1','WEBSERVER2',]
if os.environ['COMPUTERNAME'] in PRODUCTION_SERVERS:
    PRODUCTION = True
else:
    PRODUCTION = False

DEBUG = not PRODUCTION
TEMPLATE_DEBUG = DEBUG

# ...

if PRODUCTION:
    DATABASE_HOST = '192.168.1.1'
else:
    DATABASE_HOST = 'localhost'

我仍然认为这种设置方式是一种正在进行中的工作。我还没有看到任何一种方法来处理Django设置，它涵盖了所有的基础，同时设置起来也不是很麻烦(我不喜欢5x设置文件方法)。