如果使用Git进行版本控制，需要一个Gitignore文件来忽略所有不重要的、不应该在Git存储库中的文件。想想你的虚拟环境和所有的.pyc文件。这些都是临时生成的，任何有权访问代码的人都可以生成。因此，没有必要将这些添加到存储库中。

有很多不同的文件类型和特定的文件夹是不需要的，甚至在Django项目之外。在VS Code、pycharm中的个人设置。

Django项目开发或改动完成后将本地代码提交到代码库(比如github)时，需要考虑哪些文件需要提交，哪些不需要提交。这是因为有些库文件(比如缓存文件)，本地日志文件还有一些编译文件是不必要提交的。这时可以使用.gitingnore文件忽略不需要提交的文件。

创建.gitignore文件

在Django项目的根目录下创建.gitignore文件，每行即为一项提交忽略文件/目录。

基本语法

1. # 用于注释一段内容
2. ！不忽略指定的文件或者文件夹，如：!readme.md，不忽视readme.md文件
3. * 匹配多个字符,如：*.log ,忽视所有后缀为.log的文件
4. ?  匹配除 / 外的任意一个字符
5. [] 方括号，匹配多个列表中的字符
6. /** 斜杠后紧跟两个连续的星号“**”，表示多级目录
7. /斜杠在前：匹配项目跟目录，如：/name，则表示指定路径下的名为name的文件或者文件夹
8. /斜杠在后：匹配项目跟目录，如：name/，则表示无指定路径下在名为name的文件夹

Django项目建议忽略的文件清单

一般缓存文件__pycache__、本地日志文件、.logdb.sqlite3、media文件夹不需要提交。PyCharm生成的文件、Env文件、第三方package、local_settings.py本地配置文件也不要提交。

参考资料：

https://djangowaves.com/tips-tricks/gitignore-for-a-django-project/

文件内容：

https://gitee.com/SteveRocket/python_framework/blob/master/django_framework/language_characteristic/.gitignore

涵盖了可以通过gitignore为您启动的每个Django项目忽略的所有内容。将这个列表放在Django项目的根目录中，并将其命名为.gitignore，文件清单内容如下：

*.pyc
*.swp
*.*.swp
bak/
bak_bak/
logs/
project/
settings_env.py
supervisord.conf
redis.conf
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[codi]
*$py.class# C extensions
*.so# Distribution / packaging
.Python
env/
./build/
develop-eggs/
dist/
downloads/
eggs/
.eggs/
lib/
lib64/
parts/
sdist/
var/
wheels/
*.egg-info/
.installed.cfg
*.egg
MANIFEST# PyInstaller
#  Usually these files are written by a python script from a template
#  before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec# Installer logs
pip-log.txt
pip-delete-this-directory.txt# Unit test / coverage reports
htmlcov/
.tox/
.coverage
.coverage.*
.cache
nosetests.xml
coverage.xml
*.cover
.hypothesis/
.pytest_cache/# Translations
# *.mo
*.pot# Django stuff:
local_settings.py
db.sqlite3# Flask stuff:
instance/
.webassets-cache# Scrapy stuff:
.scrapy# Sphinx documentation
docs/_build/# PyBuilder
target/# Jupyter Notebook
.ipynb_checkpoints# pyenv
.python-version# celery beat schedule file
celerybeat-schedule# SageMath parsed files
*.sage.py# Environments
.env# virtualenv
venv/
env.bak/
venv.bak/# Spyder project settings
.spyderproject
.spyproject# Rope project settings
.ropeproject# mkdocs documentation
/site# mypy
.mypy_cache/
.vscode/
.idea
.history# bkmonitor project settings
bkclouds/settings_env.py
tencent/settings_env.py
project
*~
.envrc# DS_Store
.DS_Store# Node# Logs
logs
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*# Runtime data
pids
*.pid
*.seed
*.pid.lock# Directory for instrumented libs generated by jscoverage/JSCover
lib-cov# Coverage directory used by tools like istanbul
coverage# nyc test coverage
.nyc_output# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
.grunt# Bower dependency directory (https://bower.io/)
bower_components# node-waf configuration
.lock-wscript# Compiled binary addons (http://nodejs.org/api/addons.html)
build/Release# Dependency directories
node_modules/
jspm_packages/# Optional npm cache directory
.npm# Optional eslint cache
.eslintcache# Optional REPL history
.node_repl_history# Output of 'npm pack'
*.tgz# Yarn Integrity file
.yarn-integrity# dist
webpack/monitor
webpack/mobile
webpack/weixinkernel_api/migrations/
.venv/# User upload files
USERRES/celerybeat-schedule.db# django-versionlog
version_logs_html/# tm config file
.tapd_manager.yaml# tm file
src/tapd-manager# preci
.codecc
build.yml# static files
static/fta/
static/monitor/
static/weixin/# develop config
conf/platform/ieod.py__pycache__media
# Backup files #*.bak
# If you are using PyCharm #.idea/**/workspace.xml.idea/**/tasks.xml.idea/dictionaries.idea/**/dataSources/.idea/**/dataSources.ids.idea/**/dataSources.xml.idea/**/dataSources.local.xml.idea/**/sqlDataSources.xml.idea/**/dynamic.xml.idea/**/uiDesigner.xml.idea/**/gradle.xml.idea/**/libraries*.iws /out/
# Python #*.py[cod]# Distribution / packaging.Python build/# celerycelerybeat-schedule.*
# SageMath parsed files# Environments
.venvENV/# mkdocs documentation# Sublime Text #*.tmlanguage.cache*.tmPreferences.cache*.stTheme.cache*.sublime-workspace*.sublime-project# sftp configuration filesftp-config.json# Package control specific files PackageControl.last-runControl.ca-listControl.ca-bundleControl.system-ca-bundleGitHub.sublime-settings

Django数据库迁移文件是否需要上传

数据库迁移文件位于每个app的migrations文件夹里，迁移文件记录了模型的创建与改动。每次当创建模型或对模型字段进行修改，然后运行python manage.py makemigrations命令时都会有新的迁移文件产生。

Django官方文档特别说明这些迁移文件属于Django项目代码中很重要的一部分，不应删除或忽略，所以建议上传。

然而实际项目开发中，不同人可能对同一个模型做出了不同或甚至相反的改动，如果都向同一代码库提交，容易造成迁移文件冲突。

开发环境

如果项目尚处于开发阶段，可以选择提交，也可以选择不提交。每次在创建模型或对模型进行改动后，可以直接使用python manage.py makemigrations根据models.py重新生成迁移文件，而不需要保留之前迁移文件版本。如果从github上clone的项目里没有迁移文件，可以使用同样命令生产迁移文件，然后使用python manage.py migrate对数据库中的表做出修改。

生产环境

如果项目已经处于生产环境，此时本地因对模型做出修改而产生的迁移文件也需要提交。在生产环境的机器上，不要使用python manage.py makemigrations再生成一遍迁移文件，而应直接使用python manage.py migrate根据已经提交的迁移文件对数据库中的表做出修改。

在大多数情况下，Django的迁移文件都需要提交，不建议忽略。即使发生冲突，也可以使用python manage.py makemigrations --merge合并冲突。