你遇到的这个问题非常典型——开发时的环境配置和生产环境冲突，提交时容易忘改导致线上问题。下面是几个业界常用的解决方案，从最优雅到临时应急的都有：

1. 优先采用「配置文件拆分 + 环境变量」方案（Django官方推荐） #

这是最根本的解决方法，彻底避免把环境敏感配置硬编码进版本控制：

步骤： #

• 把settings.py拆分为基础配置和环境专属配置：
  • 保留settings.py作为通用基础配置（比如安装的APP、中间件、静态文件路径等）
  • 创建local_settings.py（本地开发用，配置DEBUG=True、stagingDB凭据）
  • 创建production_settings.py（生产用，配置DEBUG=False、productiveDB凭据）
• 在settings.py末尾添加：

  try:
      from .local_settings import *
  except ImportError:
      try:
          from .production_settings import *
      except ImportError:
          pass
  

• 将local_settings.py加入.gitignore，这样永远不会被提交到Git仓库
• 生产环境部署时，只需要把production_settings.py放到服务器上（或者用环境变量覆盖）

进阶：用环境变量读取敏感信息 #

如果不想维护多个配置文件，也可以直接在settings.py中从环境变量读取配置：

import os
from dotenv import load_dotenv  # 需要安装python-dotenv包

# 本地开发时加载.env文件
load_dotenv()

DEBUG = os.environ.get("DJANGO_DEBUG", "False") == "True"
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.mysql",
        "NAME": os.environ.get("DJANGO_DB_NAME"),
        "USER": os.environ.get("DJANGO_DB_USER"),
        "PASSWORD": os.environ.get("DJANGO_DB_PASSWORD"),
        "HOST": os.environ.get("DJANGO_DB_HOST", "localhost"),
    }
}

• 本地创建.env文件存储环境变量（加入.gitignore）：

  DJANGO_DEBUG=True
  DJANGO_DB_NAME=stagingDB
  DJANGO_DB_USER=dev_user
  DJANGO_DB_PASSWORD=dev_pass
  

• 生产环境在IIS中配置环境变量，或者用服务器的环境变量管理工具设置，完全不用修改代码。

2. 用GitLab CI/CD自动修改配置（适合必须提交settings.py的场景） #

如果因为某些原因必须把settings.py提交到仓库，GitLab CI/CD可以在流水线运行时根据分支自动修改配置：

在.gitlab-ci.yml中添加部署阶段的脚本：

deploy_production:
  stage: deploy
  only:
    - master  # 只在master分支运行
  script:
    # 替换DEBUG模式为False
    - sed -i 's/DEBUG = True/DEBUG = False/' your_project/settings.py
    # 替换数据库名称为productiveDB
    - sed -i 's/NAME = "stagingDB"/NAME = "productiveDB"/' your_project/settings.py
    # 替换数据库凭据（如果需要）
    - sed -i 's/USER = "dev_user"/USER = "prod_user"/' your_project/settings.py
    # 执行部署命令（比如IIS部署脚本）
    - your_deploy_script.sh

这种方式的缺点是如果settings.py的代码格式变化，sed命令可能失效，但作为临时方案可以解决问题。

3. 用Git钩子在本地提交前自动修正 #

如果想在本地提交时就避免错误，可以用Git的pre-commit钩子，在提交前检查当前分支，自动调整配置：

1. 在项目的.git/hooks目录下创建pre-commit文件（去掉.sample后缀）
2. 写入以下脚本（Windows用户可以改用PowerShell脚本）：

#!/bin/bash
current_branch=$(git rev-parse --abbrev-ref HEAD)

# 如果当前是master分支，自动修正配置
if [ "$current_branch" = "master" ]; then
    echo "Detected master branch, updating production settings..."
    # 修改DEBUG为False
    sed -i '' 's/DEBUG = True/DEBUG = False/' your_project/settings.py
    # 修改数据库为productiveDB
    sed -i '' 's/NAME = "stagingDB"/NAME = "productiveDB"/' your_project/settings.py
    # 将修改后的文件加入暂存区
    git add your_project/settings.py
fi

exit 0

3. 给脚本添加执行权限：chmod +x .git/hooks/pre-commit

注意：钩子是本地的，每个开发者都需要配置，不如CI/CD方案统一可靠。

总结 #

最推荐的是配置文件拆分+环境变量的方案，这不仅解决了分支切换的问题，还符合安全最佳实践（避免把数据库凭据等敏感信息提交到代码仓库）。Git和GitLab本身没有内置的"根据分支修改变量"的功能，但可以通过CI/CD流水线或Git钩子实现自动化修正，不过这些都是辅助手段，核心还是不要把环境敏感配置硬编码进版本控制。

内容的提问来源于stack exchange，提问作者Dnz