[Django] migration 파일은 커밋 되어야 하는가?

마이그레이션 파일을 다루는 절대 원칙

1. 이미 커밋된 마이그레이션 파일은 지우면 안 됩니다.
2. 위와 같은 이유로 .gitignore에 포함시키지 않고 코드 저장소(Github)에 업로드하여 관리합니다.
3. 코드 저장소에 올리기 전에 혹은 프로덕션에 반영하기 전에 문제가 없는지 확인합니다.

 

왜 지우면 안 되나요?

디비를 모두 날렸어도 처음부터 끝까지 마이그레이션 파일을 실행했을때 날리기 전의 디비의 스키마를 그대로 복구할 수 있어야만 완전한 마이그레이션 파일입니다. 그런 상태일때만 여러분 각자의 로컬 디비가 서로 같은 상태를 유지하며 개발되고 있음을 보장할 수 있기 때문입니다.

1. 그래서 마이그레이션 파일은 디비에 변경점을 가하기 위한 도구라기보단 디비의 변경점을 기록해두는 커밋 로그처럼 다뤄야 합니다.
2. 가끔 심각하게 꼬인 마이그레이션의 경우 커밋을 롤백하면서 마이그레이션 파일을 지워야할 수도 있습니다. 하지만 프로덕션 db에 이미 반영된 마이그레이션 파일의 경우는 조심히 다뤄야합니다.
3. 프로덕션 db도 같이 롤백해주거나, 아니면 파일을 지우지 마세요. (자신 없으면 마이그레이션 건들지 마라.)

 

마이그레이션 파일을 커밋해야 하나요?

 

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.

https://docs.djangoproject.com/en/3.2/topics/migrations/

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.

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.

https://stackoverflow.com/a/28035246/11321149

 

---

Super Reference (겁나 참고)

 

https://velog.io/@hanqyu/django-migration-파일은-커밋되어야-할까

django migration 파일은 커밋되어야 할까