python - django 프로젝트의 마이그레이션 디렉토리를 git에 커밋해야 할까요?

Question

제목에서 알 수 있듯이 로컬 개발 환경에서 모델을 수정하면 여러 번 변경되는 경우도 있고, 그러면 많은 마이그레이션 파일이 생성됩니다.

그러나 서버에 배포할 때 서버는 어떻게 변경을 수행해야 합니까?

1. 마이그레이션 파일을 업로드하지 말고 직접 실행하세요 makemigrations 重新生成 migrations，再运行 migrate

2. 개발 중에 마이그레이션 파일을 업로드한 후 직접 실행하세요 migrate

위 두 가지 방법 중 어떤 것을 선택해야 하나요? 왜?

Answer 1

공식 성명에 따르면, 다시 생성할 필요 없이 migrate서버 측에서 직접 제출하고 실행해야 합니다.

마이그레이션을 데이터베이스 스키마의 버전 제어 시스템으로 생각해야 합니다. makemigrations는 모델 변경 사항을 커밋과 유사하게 개별 마이그레이션 파일로 패키징하는 역할을 담당하고 마이그레이션은 이를 데이터베이스에 적용하는 역할을 합니다.

각 앱의 마이그레이션 파일은 해당 앱 내부의 "migrations" 디렉터리에 있으며 해당 코드베이스에 커밋되고 배포되도록 설계되었습니다. 개발 컴퓨터에서 해당 파일을 한 번 만든 다음 실행해야 합니다. 동료의 컴퓨터, 스테이징 컴퓨터, 최종적으로는 생산 컴퓨터에서도 동일한 마이그레이션이 가능합니다.

중국어 번역:

마이그레이션을 데이터베이스의 버전 제어 시스템으로 생각할 수 있습니다. makemigrations 명령은 커밋과 마찬가지로 모델 변경 사항을 마이그레이션 파일에 저장하는 역할을 담당하는 반면, 마이그레이션은 데이터베이스에 대한 변경 사항을 커밋하는 역할을 합니다.

각 앱의 마이그레이션 파일은 해당 앱의 "migrations" 폴더에 저장되며, 실행 방법은 분산 코드 베이스로 준비되어 있습니다. 개발 시스템이나 동료의 시스템, 그리고 최종적으로는 프로덕션 시스템에서 동일한 마이그레이션을 실행할 때마다 이러한 파일을 다시 생성해야 합니다.

Answer 2

저장소에 제출하는 것을 권장합니다.

Answer 3

현재 원격 라이브러리와 동기화가 되지 않고 있습니다.
개발 과정에서 모델을 자주 수정해야 하기 때문에 마이그레이션 파일이 많이 생성되고 오류 없이 마이그레이션을 제어하기 어렵습니다.
프로그램을 게시하기 전에 모델이 업데이트되었는지 먼저 확인하세요. makemigration을 수행한 다음 로컬로 인해 테스트되었으므로 이상한 동기화 문제가 발생하지 않습니다.

Answer 4

마이그레이션을 제출하기 전에 새로 생성된 마이그레이션 변경 사항을 삭제하고 다시 마이그레이션한 다음 저장소를 제출하는 것이 어떻습니까

Answer 5

하지만 로컬에서 필드를 추가한 다음 삭제하는 등의 작업은 결국 데이터베이스에 변경 사항이 없을 수 있습니다. 따라서 이러한 마이그레이션도 서버에 제출하고 다시 실행해야 합니까?