在settings.py:

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

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

我在manage.py中区分它，并创建了两个单独的设置文件:local_settings.py和prod_settings.py。

在manage.py中检查服务器是本地服务器还是生产服务器。如果它是本地服务器，它将加载local_settings.py，如果它是生产服务器，它将加载prod_settings.py。基本上是这样的:

#!/usr/bin/env python
import sys
import socket
from django.core.management import execute_manager 

ipaddress = socket.gethostbyname( socket.gethostname() )
if ipaddress == '127.0.0.1':
    try:
        import local_settings # Assumed to be in the same directory.
        settings = local_settings
    except ImportError:
        import sys
        sys.stderr.write("Error: Can't find the file 'local_settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file local_settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
        sys.exit(1)
else:
    try:
        import prod_settings # Assumed to be in the same directory.
        settings = prod_settings    
    except ImportError:
        import sys
        sys.stderr.write("Error: Can't find the file 'prod_settings.py' in the directory containing %r. It appears you've customized things.\nYou'll have to run django-admin.py, passing it your settings module.\n(If the file prod_settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__)
        sys.exit(1)

if __name__ == "__main__":
    execute_manager(settings)

我发现将设置文件分开到两个单独的文件中更容易，而不是在设置文件中做大量的if。

1 -在你的应用程序中创建一个新文件夹，并设置它的名称。

2 -现在在其中创建一个新的__init__.py文件，并在其中写入

from .base import *

try:
    from .local import *
except:
    pass

try:
    from .production import *
except:
    pass

3 -在设置文件夹local.py和production.py和base.py中创建三个新文件。

4 -在base.py中，复制之前settings.py文件夹中的所有内容，并将其重命名为old_settings.py。

5 -在base.py中更改BASE_DIR路径以指向新的设置路径

旧的路径- > BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

新建路径-> BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

通过这种方式，项目总监可以结构化，并且可以在生产和本地开发之间进行管理。

我使用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设置文件方法)。

为了在不同的环境中使用不同的设置配置，创建不同的设置文件。在部署脚本中，使用——settings=<my-settings.py>参数启动服务器，通过该参数可以在不同的环境中使用不同的设置。

使用这种方法的好处:

Your settings will be modular based on each environment You may import the master_settings.py containing the base configuration in the environmnet_configuration.py and override the values that you want to change in that environment. If you have huge team, each developer may have their own local_settings.py which they can add to the code repository without any risk of modifying the server configuration. You can add these local settings to .gitnore if you use git or .hginore if you Mercurial for Version Control (or any other). That way local settings won't even be the part of actual code base keeping it clean.

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

我的标准是:

所有东西都应该在源代码控制中。我不喜欢精细的东西到处乱放。 理想情况下，将设置保存在一个文件中。如果我不看东西，我就会忘记它们:) 无需部署手动编辑。应该能够用一个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总是让它变得如此模糊，以至于你可以设置环境变量。)

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