Python 我应该在 .gitignore 文件中添加 Django 迁移文件吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/28035119/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Should I be adding the Django migration files in the .gitignore file?
提问by Michael Smith
Should I be adding the Django migration files in the .gitignorefile?
我应该在文件中添加 Django 迁移.gitignore文件吗？
I've recently been getting a lot of git issues due to migration conflicts and was wondering if I should be marking migration files as ignore.
由于迁移冲突，我最近遇到了很多 git 问题，并且想知道是否应该将迁移文件标记为忽略。
If so, how would I go about adding all of the migrations that I have in my apps, and adding them to the .gitignorefile?
如果是这样，我将如何添加我的应用程序中的所有迁移，并将它们添加到.gitignore文件中？
采纳答案by Sven Marnach
Quoting from the Django migrations documentation:
引用Django 迁移文档：
The migration files for each app live in a “migrations” directory inside of that app, and are designed to be committed to, and distributed as part of, its codebase. You should be making them once on your development machine and then running the same migrations on your colleagues' machines, your staging machines, and eventually your production machines.
每个应用程序的迁移文件都位于该应用程序内的“迁移”目录中，旨在提交到其代码库并作为其代码库的一部分进行分发。您应该在开发机器上进行一次迁移，然后在同事的机器、临时机器上运行相同的迁移，最终在生产机器上运行。
If you follow this process, you shouldn't be getting any merge conflicts in the migration files.
如果您遵循此过程，您应该不会在迁移文件中遇到任何合并冲突。
When merging version control branches, you still may encounter a situation where you have multiple migrations based on the same parent migration, e.g. if to different developers introduced a migration concurrently. One way of resolving this situation is to introduce a _merge_migration_. Often this can be done automatically with the command
在合并版本控制分支时，您仍然可能会遇到基于同一个父迁移有多个迁移的情况，例如，如果对不同的开发人员同时引入了迁移。解决这种情况的一种方法是引入 _merge_migration_。通常这可以使用命令自动完成
./manage.py makemigrations --merge
which will introduce a new migration that depends on all current head migrations. Of course this only works when there is no conflict between the head migrations, in which case you will have to resolve the problem manually.
这将引入一个新的迁移，该迁移取决于所有当前的头部迁移。当然，这只适用于头部迁移之间没有冲突的情况，在这种情况下，您必须手动解决问题。
Given that some people here suggested that you shouldn'tcommit your migrations to version control, I'd like to expand on the reasons why you actually shoulddo so.
鉴于这里有些人建议您不要将迁移提交给版本控制，我想详细说明您实际上应该这样做的原因。
First, you need a record of the migrations applied to your production systems. If you deploy changes to production and want to migrate the database, you need a description of the current state. You can create a separate backup of the migrations applied to each production database, but this seems unnecessarily cumbersome.
首先，您需要记录应用于生产系统的迁移。如果将更改部署到生产并希望迁移数据库，则需要对当前状态的描述。您可以为应用于每个生产数据库的迁移创建单独的备份，但这似乎不必要地繁琐。
Second, migrations often contain custom, handwritten code. It's not always possible to automatically generate them with ./manage.py makemigrations.
其次，迁移通常包含自定义的手写代码。使用./manage.py makemigrations.
Third, migrations should be included in code review. They are significant changes to your production system, and there are lots of things that can go wrong with them.
第三，迁移应该包括在代码中。它们是对您的生产系统的重大更改，并且它们可能会出现很多问题。
So in short, if you care about your production data, please check your migrations into version control.
简而言之，如果您关心您的生产数据，请检查您的迁移到版本控制。
回答by Sdra
TL;DR: commit migrations, resolve migration conflicts, adjust your git workflow.
TL;DR：提交迁移，解决迁移冲突，调整您的 git 工作流程。
Feels like you'd need to adjust your gitworkflow, instead of ignoring conflicts.
感觉你需要调整你的git工作流程，而不是忽略冲突。
Ideally, every new feature is developed in a different branch, and merged back with a pull request.
理想情况下，每个新功能都在不同的分支中开发，并与拉取请求合并。
PRs cannot be merged if there's a conflict, therefore who needs to merge his feature needs to resolve the conflict, migrations included. This might need coordination between different teams.
如果存在冲突，则无法合并 PR，因此需要合并其功能的人需要解决冲突，包括迁移。这可能需要不同团队之间的协调。
It is important though to commit migration files! If a conflict arises, Django might even help you solve those conflicts;)
提交迁移文件很重要！如果出现冲突，Django 甚至可以帮助您解决这些冲突;)
回答by Anthony Briggs
I can't imagine whyyou would be getting conflicts, unless you're editing the migrations somehow? That usually ends badly - if someone misses some intermediate commits then they won't be upgrading from the correct version, and their copy of the database will be corrupted.
我无法想象为什么你会遇到冲突，除非你以某种方式编辑迁移？这通常会以糟糕的方式结束——如果有人错过了一些中间提交，那么他们将不会从正确的版本升级，并且他们的数据库副本将被破坏。
The process that I follow is pretty simple - whenever you change the models for an app, you also commit a migration, and then that migration doesn't change- if you need something different in the model, then you change the model and commit a new migration alongside your changes.
我遵循的过程非常简单 - 每当您更改应用程序的模型时，您也会提交一个迁移，然后该迁移不会更改- 如果您需要模型中的某些内容，那么您更改模型并提交一个新迁移与您的更改。
In greenfield projects, you can often delete the migrations and start over from scratch with a 0001_ migration when you release, but if you have production code, then you can't (though you can squash migrations down into one).
在新建项目中，您通常可以在发布时删除迁移并从头开始使用 0001_ 迁移，但如果您有生产代码，则不能（尽管您可以将迁移压缩为一个）。
回答by SuperNova
You can follow the below process.
您可以按照以下流程进行操作。
You can run makemigrationslocally and this creates the migration file. Commit this new migration file to repo.
您可以在makemigrations本地运行，这将创建迁移文件。将此新迁移文件提交到 repo。
In my opinion you should not run makemigrationsin production at all. You can run migratein production and you will see the migrations are applied from the migration file that you committed from local. This way you can avoid all conflicts.
在我看来，您根本不应该makemigrations在生产中运行。您可以migrate在生产中运行，您将看到从您从本地提交的迁移文件中应用了迁移。这样您就可以避免所有冲突。
IN LOCAL ENV, to create the migration files,
在 LOCAL ENV 中，创建迁移文件，
python manage.py makemigrations
python manage.py migrate
Now commit these newly created files, something like below.
现在提交这些新创建的文件，如下所示。
git add app/migrations/...
git commit -m 'add migration files' app/migrations/...
IN PRODUCTION ENV, run only the below command.
在 PRODUCTION ENV 中，仅运行以下命令。
python manage.py migrate
回答by WhyNotHugo
The solution usually used, is that, before anything is merged into master, the developer must pull any remote changes. If there's a conflict in migration versions, he should rename his localmigration (the remote one has been run by other devs, and, potentially, in production), to N+1.
通常使用的解决方案是，在将任何内容合并到 master 之前，开发人员必须拉取任何远程更改。如果迁移版本存在冲突，他应该将他的本地迁移（远程迁移已由其他开发人员运行，并且可能在生产中）重命名为 N+1。
During development it might be okay to just not-commit migrations (don't add an ignore though, just don't addthem). But once you've gone into production, you'll need them in order to keep the schema in sync with model changes.
在开发过程中，不提交迁移可能没问题（尽管不要添加忽略，只是不要添加add）。但是一旦投入生产，您将需要它们以保持模式与模型更改同步。
You then need to edit the file, and change the dependenciesto the latest remote version.
然后您需要编辑该文件，并将其更改dependencies为最新的远程版本。
This works for Django migrations, as well as other similar apps (sqlalchemy+alembic, RoR, etc).
这适用于 Django 迁移以及其他类似的应用程序（sqlalchemy+alembic、RoR 等）。
回答by Diansheng
Short answerI propose excluding migrations in the repo. After code merge, just run ./manage.py makemigrationsand you are all set.
简短的回答我建议在 repo 中排除迁移。代码合并后，只需运行即可./manage.py makemigrations。
Long answerI don't think you should put migrations files into repo. It will spoil the migration states in other person's dev environment and other prod and stage environment. (refer to Sugar Tang's comment for examples).
长答案我认为您不应该将迁移文件放入 repo 中。它会破坏其他人的开发环境和其他产品和阶段环境中的迁移状态。（请参阅糖唐的评论以获取示例）。
In my point of view, the purpose of Django migrations is to find gaps between previous model states and new model states, and then serialise the gap. If your model changes after code merge, you can simple do makemigrationsto find out the gap. Why do you want to manually and carefully merge other migrations when you can achieve the same automatically and bug free? Django documentationsays,
在我看来，Django 迁移的目的是找到以前模型状态和新模型状态之间的差距，然后将差距序列化。如果您的模型在代码合并后发生变化，您可以简单makemigrations地找出差距。当您可以自动实现相同且无错误时，为什么要手动并小心地合并其他迁移？Django 文档说，
They*(migrations)*'re designed to be mostly automatic
他们*（迁移）*'被设计成大部分是自动的
; please keep it that way. To merge migrations manually, you have to fully understand what others have changed and any dependence of the changes. That's a lot of overhead and error prone. So tracking models file is sufficient.
; 请保持这种方式。要手动合并迁移，您必须完全了解其他人已更改的内容以及更改的任何依赖性。这是很多开销并且容易出错。所以跟踪模型文件就足够了。
It is a good topic on the workflow. I am open to other options.
这是一个关于工作流程的好话题。我对其他选择持开放态度。
回答by techkuz
Quote from the 2018 docs, Django 2.0. (two separate commands = makemigrationsand migrate)
引自 2018 年文档，Django 2.0。（两个单独的命令 =makemigrations和migrate）
The reason that there are separate commands to make and apply migrations is because you'll commit migrations to your version control system and ship them with your app; they not only make your development easier, they're also useable by other developers and in production.
有单独的命令来进行和应用迁移的原因是因为您将迁移提交到您的版本控制系统并将它们与您的应用程序一起发布；它们不仅使您的开发更容易，而且其他开发人员和生产环境也可以使用它们。
回答by Gizachew Soboksa
Having a bunch of migration files in git is messy. There is only one file in migration folder that you should not ignore. That file is init.py file, If you ignore it, python will no longer look for submodules inside the directory, so any attempts to import the modules will fail. So the question should be how to ignore all migration files but init.py? The solution is: Add '0*.py' to .gitignore files and it does the job perfectly.
在 git 中有一堆迁移文件很麻烦。迁移文件夹中只有一个您不应忽略的文件。该文件是init.py 文件，如果忽略它，python 将不再在目录中查找子模块，因此任何导入模块的尝试都将失败。所以问题应该是如何忽略所有迁移文件但init.py？解决方案是：将 '0*.py' 添加到 .gitignore 文件，它完美地完成了这项工作。
Hope this helps someone.
希望这可以帮助某人。
回答by Yevhen Dyachenko
Gitignore the migrations, if You have separate DBs for Development, Staging and Production environment. For dev. purposes You can use local sqlite DB and play with migrations locally. I would recommend You to create four additional branches:
如果您有单独的用于开发、暂存和生产环境的数据库，请忽略迁移。对于开发。目的您可以使用本地 sqlite 数据库并在本地进行迁移。我建议您创建四个额外的分支：
Master - Clean fresh code without migrations. Nobody is connected to this branch. Used for code reviews only
Development - daily development. Push/pull accepted. Each developer is working on sqlite DB
Cloud_DEV_env - remote cloud/server DEV environment. Pull only. Keep migrations locally on machine, which is used for the code deployment and remote migrations of Dev database
Cloud_STAG_env - remote cloud/server STAG environment. Pull only. Keep migrations locally on machine, which is used for the code deployment and remote migrations of Stag database
Cloud_PROD_env - remote cloud/server DEV environment. Pull only. Keep migrations locally on machine, which is used for the code deployment and remote migrations of Prod database
Master - 无需迁移即可清理新代码。没有人连接到这个分支。仅用于代码
发展 - 日常发展。接受推/拉。每个开发人员都在研究 sqlite DB
Cloud_DEV_env - 远程云/服务器 DEV 环境。只拉。保持机器本地迁移，用于Dev数据库的代码部署和远程迁移
Cloud_STAG_env - 远程云/服务器 STAG 环境。只拉。保持机器本地迁移，用于Stag数据库的代码部署和远程迁移
Cloud_PROD_env - 远程云/服务器 DEV 环境。只拉。保持机器本地迁移，用于Prod数据库的代码部署和远程迁移
Notes: 2, 3, 4 - migrations can be kept in repos but there should be strict rules of pull requests merging, so we decided to find a person, responsible for deployments, so the only guy who has all the migration files - our deploy-er. He keeps the remote DB migrations each time we have any changes in Models.
注意： 2, 3, 4 - 迁移可以保存在 repos 中，但应该有严格的合并拉取请求的规则，所以我们决定找一个人来负责部署，所以唯一拥有所有迁移文件的人 - 我们的部署-呃。每次我们对模型进行任何更改时，他都会保留远程数据库迁移。
