.gitignore 파일에 Django 마이그레이션 파일을 추가해야합니까?

.gitignore 파일에 Django 마이그레이션 파일을 추가해야합니까?

---

Django 마이그레이션 파일을 파일에 추가해야합니까 .gitignore?

최근 마이그레이션 충돌로 인해 많은 자식 문제가 발생했으며 마이그레이션 파일을 무시로 표시해야하는지 궁금합니다.

그렇다면 내 앱에있는 모든 마이그레이션을 추가하고 .gitignore파일에 추가하려면 어떻게해야합니까?

---

Django 마이그레이션 문서 에서 인용 :

각 앱의 마이그레이션 파일은 해당 앱 내부의 "migrations"디렉토리에 있으며 해당 코드베이스에 커밋되고 일부로 배포되도록 설계되었습니다. 개발 머신에서 한 번 만든 다음 동료의 머신, 스테이징 머신, 그리고 결국 프로덕션 머신에서 동일한 마이그레이션을 실행해야합니다.

이 프로세스를 따르면 마이그레이션 파일에서 병합 충돌이 발생하지 않아야합니다.

현재 가지고있는 문제를 완화하려면 마이그레이션 파일의 신뢰할 수있는 버전이있는 저장소 또는 분기 를 지정한 다음 git의 속성 메커니즘 을 사용하여 이러한 파일에 대한 병합 전략을 "우리"로 지정해야합니다. 이것은 git에게 이러한 파일의 외부 변경 사항을 항상 무시하고 로컬 버전을 선호하도록 지시합니다.

---

아니.

나는 이것을 여러 번 겪었고 내 인생 동안 저장소에서 마이그레이션이 필요한 경우를 찾을 수 없습니다.

내가보기에 스키마의 최종 기록은 models.py. 내가 변경 사항을 병합하고 다른 사람이 가져 오면 실행시 모든 것이 정확 makemigrations해 migrate집니다. 마이그레이션을위한 "우리"의 전략이 무엇인지 정의 할 필요가 없습니다.

롤백해야하는 경우 되돌리고 models마이그레이션합니다. 모든 것이 좋고 문제가 없습니다.

필드가 이미 존재한다고 불평하지 않습니다.

내가 일하기 전에 다른 개발자의 마이그레이션 파일을 병합해야하는 이점이있는 특정 사례를 누가 줄 수 있는지 궁금합니다. 나는 문서가 내가해야한다고 말하는 것을 알고있다. 그래서 나는 그렇게 생각한다. 하지만 한 번도 만나 본 적이 없습니다.

누군가?

---

아래 절차를 따를 수 있습니다.

makemigrations로컬에서 실행할 수 있으며 마이그레이션 파일이 생성됩니다. 이 새 마이그레이션 파일을 repo에 커밋합니다.

제 생각 makemigrations에는 프로덕션에서 전혀 실행해서는 안됩니다 . migrate프로덕션에서 실행할 수 있으며 로컬에서 커밋 한 마이그레이션 파일에서 마이그레이션이 적용되는 것을 볼 수 있습니다. 이렇게하면 모든 충돌을 피할 수 있습니다.

LOCAL ENV 에서 마이그레이션 파일을 만들려면

python manage.py makemigrations 
python manage.py migrate

이제 다음과 같이 새로 생성 된 파일을 커밋합니다.

git add app/migrations/...
git commit -m 'add migration files' app/migrations/...

---

PRODUCTION ENV 에서 아래 명령 만 실행하십시오.

python manage.py migrate

---

2018 년 문서, Django 2.0에서 인용. (두 개의 개별 명령 = makemigrations및 migrate)

마이그레이션을 수행하고 적용하는 별도의 명령이있는 이유는 버전 제어 시스템에 마이그레이션을 커밋하고 앱과 함께 제공하기 때문입니다. 개발을 더 쉽게 할뿐만 아니라 다른 개발자와 프로덕션에서도 사용할 수 있습니다.

https://docs.djangoproject.com/en/2.0/intro/tutorial02/

---

어떻게 든 마이그레이션을 편집하지 않는 한 충돌이 발생하는 이유 를 상상할 수 없습니까? 그것은 일반적으로 나쁘게 끝납니다. 누군가 중간 커밋을 놓치면 올바른 버전에서 업그레이드하지 않고 데이터베이스 복사본이 손상됩니다.

제가 따르는 프로세스는 매우 간단합니다. 앱의 모델을 변경할 때마다 마이그레이션도 커밋하면 마이그레이션이 변경되지 않습니다 . 모델에서 다른 것이 필요하면 모델을 변경하고 커밋합니다. 변경 사항과 함께 새로운 마이그레이션.

그린 필드 프로젝트에서는 종종 마이그레이션을 삭제하고 릴리스 할 때 0001_ 마이그레이션으로 처음부터 다시 시작할 수 있지만 프로덕션 코드가 있으면 불가능합니다 (마이그레이션을 하나로 스쿼시 할 수 있음).

---

일반적으로 사용되는 솔루션은 어떤 것이 마스터로 병합되기 전에 개발자가 원격 변경 사항을 가져와야한다는 것입니다. 마이그레이션 버전에 충돌이있는 경우 로컬 마이그레이션의 이름을 변경해야 합니다 (원격 마이그레이션은 다른 개발자에 의해 실행되었으며 잠재적으로 프로덕션 단계에 있음).

개발 중에는 마이그레이션을 커밋하지 않는 것이 좋습니다 (무시를 추가하지 말고 그냥하지 마십시오 add). 그러나 프로덕션 단계에 들어간 후에는 스키마를 모델 변경 사항과 동기화하기 위해 필요합니다.

그런 다음 파일을 편집 dependencies하고을 최신 원격 버전으로 변경해야 합니다.

이는 Django 마이그레이션 및 기타 유사한 앱 (sqlalchemy + alembic, RoR 등)에서 작동합니다.

---

Feels like you'd need to adjust your git workflow, instead of ignoring conflicts.

Ideally, every new feature is developed in a different branch, and merged back with a pull request.

PR cannot be merged if there's a conflict, therefore who needs to merge his feature needs to resolve the conflict, migrations included.

---

Short answer I propose excluding migrations in the repo. After code merge, just run ./manage.py makemigrations and you are all set.

Long answer I 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).

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 makemigrations to 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 documentation says,

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.

---

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.

Hope this helps someone.

---

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:

1. Master - Clean fresh code without migrations. Nobody is connected to this branch. Used for code reviews only

2. Development - daily development. Push/pull accepted. Each developer is working on sqlite DB

3. 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

4. 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

5. 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

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.

참고URL : https://stackoverflow.com/questions/28035119/should-i-be-adding-the-django-migration-files-in-the-gitignore-file