답변:
Django 마이그레이션 문서 에서 인용 :
각 앱의 마이그레이션 파일은 해당 앱 내부의 "migrations"디렉토리에 있으며 해당 코드베이스에 커밋되고 일부로 배포되도록 설계되었습니다. 개발 컴퓨터에서 한 번 만든 다음 동료의 컴퓨터, 스테이징 컴퓨터 및 결국 프로덕션 컴퓨터에서 동일한 마이그레이션을 실행해야합니다.
이 프로세스를 따르면 마이그레이션 파일에서 병합 충돌이 발생하지 않아야합니다.
버전 제어 분기를 병합 할 때 동일한 상위 마이그레이션을 기반으로 여러 마이그레이션이있는 상황이 발생할 수 있습니다 (예 : 다른 개발자에게 동시에 마이그레이션을 도입 한 경우). 이 상황을 해결하는 한 가지 방법은 _merge_migration_을 도입하는 것입니다. 종종 이것은 다음 명령을 사용하여 자동으로 수행 될 수 있습니다.
./manage.py makemigrations --merge현재의 모든 헤드 마이그레이션에 의존하는 새로운 마이그레이션을 소개합니다. 물론 이것은 헤드 마이그레이션간에 충돌이없는 경우에만 작동하며이 경우 수동으로 문제를 해결해야합니다.
여기에있는 일부 사람들이 마이그레이션을 버전 제어로 커밋 하지 말아야한다고 제안 했기 때문에 실제로 그렇게 해야하는 이유를 확장하고 싶습니다 .
먼저, 프로덕션 시스템에 적용된 마이그레이션 기록이 필요합니다. 프로덕션에 변경 사항을 배포하고 데이터베이스를 마이그레이션하려는 경우 현재 상태에 대한 설명이 필요합니다. 각 프로덕션 데이터베이스에 적용된 마이그레이션의 별도 백업을 만들 수 있지만 이는 불필요하게 번거로운 것 같습니다.
둘째, 마이그레이션에는 종종 사용자 지정 손으로 작성한 코드가 포함됩니다. .NET을 사용하여 자동으로 생성하는 것이 항상 가능한 것은 아닙니다 ./manage.py makemigrations.
셋째, 마이그레이션은 코드 검토에 포함되어야합니다. 이는 프로덕션 시스템에 중요한 변경 사항이며 문제가 될 수있는 많은 것들이 있습니다.
즉, 프로덕션 데이터에 관심이 있다면 버전 관리로의 마이그레이션을 확인하십시오.
아래 절차를 따를 수 있습니다.
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 migratemigrate하고 절대로 수행하지 않는 것이 좋습니다 makemigrations. 그건 생각도 못 했어.
2018 년 문서, Django 2.0에서 인용. (두 개의 개별 명령 = makemigrations및 migrate)
마이그레이션을 수행하고 적용하는 별도의 명령이있는 이유는 마이그레이션을 버전 제어 시스템에 커밋하고 앱과 함께 제공하기 때문입니다. 개발을 더 쉽게 할뿐만 아니라 다른 개발자와 프로덕션에서도 사용할 수 있습니다.
요약 : 마이그레이션 커밋, 마이그레이션 충돌 해결, git 워크 플로 조정.
충돌을 무시하는 대신 git 워크 플로 를 조정해야 할 것 같습니다 .
이상적으로는 모든 새로운 기능이 다른 브랜치에서 개발되고 풀 리퀘스트로 다시 병합됩니다 .
충돌이 있으면 PR을 병합 할 수 없으므로 기능을 병합해야하는 사람은 충돌을 해결해야하며 마이그레이션도 포함됩니다. 다른 팀 간의 조정이 필요할 수 있습니다.
마이그레이션 파일을 커밋하는 것이 중요합니다! 충돌이 발생하면 Django는 이러한 충돌을 해결하는 데 도움을 줄 수도 있습니다 .)
어떻게 든 마이그레이션을 편집하지 않는 한 충돌이 발생하는 이유 를 상상할 수 없습니까? 그것은 일반적으로 나쁘게 끝납니다. 누군가 중간 커밋을 놓치면 올바른 버전에서 업그레이드하지 않고 데이터베이스 복사본이 손상됩니다.
제가 따르는 프로세스는 매우 간단합니다. 앱의 모델을 변경할 때마다 마이그레이션도 커밋하면 마이그레이션이 변경되지 않습니다 . 모델에서 다른 것이 필요하면 모델을 변경하고 커밋합니다. 변경 사항과 함께 새로운 마이그레이션.
그린 필드 프로젝트에서는 종종 마이그레이션을 삭제하고 릴리스 할 때 0001_ 마이그레이션으로 처음부터 다시 시작할 수 있지만 프로덕션 코드가 있으면 불가능합니다 (마이그레이션을 하나로 스쿼시 할 수 있음).
일반적으로 사용되는 솔루션은 어떤 것이 마스터로 병합되기 전에 개발자가 원격 변경 사항을 가져와야한다는 것입니다. 마이그레이션 버전에 충돌이있는 경우 로컬 마이그레이션의 이름을 변경해야 합니다 (원격 마이그레이션은 다른 개발자에 의해 실행되었으며 잠재적으로 프로덕션 단계에 있음).
개발 중에는 마이그레이션을 커밋하지 않는 것이 좋습니다 (무시를 추가하지 말고 그냥 추가하지 마십시오 add). 그러나 일단 프로덕션에 들어간 후에는 스키마를 모델 변경과 동기화하기 위해 필요합니다.
그런 다음 파일을 편집 dependencies하고을 최신 원격 버전으로 변경해야 합니다.
이는 Django 마이그레이션 및 기타 유사한 앱 (sqlalchemy + alembic, RoR 등)에서 작동합니다.
개발, 스테이징 및 프로덕션 환경을위한 별도의 DB가있는 경우 마이그레이션을 무시하십시오. dev. 목적 로컬 sqlite DB를 사용하고 로컬에서 마이그레이션을 수행 할 수 있습니다. 4 개의 추가 분기를 생성하는 것이 좋습니다.
마스터-마이그레이션없이 새 코드를 정리합니다. 아무도이 지점에 연결되어 있지 않습니다. 코드 검토에만 사용
개발-매일 개발. 밀기 / 끌기 허용. 각 개발자는 sqlite DB에서 작업하고 있습니다.
Cloud_DEV_env-원격 클라우드 / 서버 DEV 환경. 당기기 만하십시오. 코드 배포 및 Dev 데이터베이스의 원격 마이그레이션에 사용되는 머신에서 로컬로 마이그레이션을 유지합니다.
Cloud_STAG_env-원격 클라우드 / 서버 STAG 환경. 당기기 만하십시오. Stag 데이터베이스의 코드 배포 및 원격 마이그레이션에 사용되는 머신에서 로컬로 마이그레이션을 유지합니다.
Cloud_PROD_env-원격 클라우드 / 서버 DEV 환경. 당기기 만하십시오. Prod 데이터베이스의 코드 배포 및 원격 마이그레이션에 사용되는 컴퓨터에서 로컬로 마이그레이션을 유지합니다.
참고 : 2, 3, 4-마이그레이션은 리포지토리에 보관할 수 있지만 풀 리퀘스트 병합에 대한 엄격한 규칙이 있어야하므로 배포를 담당하는 사람을 찾기로 결정했습니다. 따라서 모든 마이그레이션 파일을 보유한 유일한 사람인 배포 -어. 그는 모델이 변경 될 때마다 원격 DB 마이그레이션을 유지합니다.
짧은 대답
은 리포지토리에서 마이그레이션을 제외 할 것을 제안합니다. 코드 병합 후 실행./manage.py makemigrations 모든 설정이 완료됩니다.
긴 대답 은 마이그레이션 파일을 repo에 넣어야한다고 생각하지 않습니다. 다른 사람의 개발 환경과 다른 제품 및 무대 환경에서 마이그레이션 상태를 망칠 것입니다. (예는 Sugar Tang의 의견을 참조하십시오).
내 관점에서 Django 마이그레이션의 목적은 이전 모델 상태와 새 모델 상태 사이의 차이를 찾은 다음 그 차이를 직렬화하는 것입니다. 코드 병합 후 모델이 변경되면 간단하게 makemigrations차이를 찾을 수 있습니다 . 자동으로 버그없이 동일한 작업을 수행 할 수 있는데 다른 마이그레이션을 수동으로 신중하게 병합하려는 이유는 무엇입니까? Django 문서에 따르면
그들은 * (마이그레이션) *이 대부분 자동으로 설계되었습니다.
; 그렇게 유지하십시오. 마이그레이션을 수동으로 병합하려면 다른 사용자가 변경 한 사항과 변경 사항에 대한 종속성을 완전히 이해해야합니다. 이는 많은 오버 헤드와 오류가 발생하기 쉽습니다. 따라서 추적 모델 파일이면 충분합니다.
워크 플로우에 대한 좋은 주제입니다. 나는 다른 옵션에 열려 있습니다.
manage.py makemigrations --merge. 완전히 자동으로 작동합니다.
makemigrations some_app하면 해당 멤버가 제어하는 모델뿐만 아니라 다른 관련 모델도 영향을받습니다. 즉, 다른 앱의 마이그레이션 파일 (00 * _ *)이 변경됩니다. 그리고 이로 인해 GitHub로 푸시하거나 가져 오는 동안 많은 충돌 문제가 발생합니다. 현재 시스템이 생산 준비가되지 않았으므로.gitignore마이그레이션 파일 만 있습니다. 우리는 여전히 시스템이 생산 될 때 그것을 해결하는 방법을 모릅니다. 아무도 해결책이 있습니까?