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

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

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

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

만약 그렇다면, 앱에 있는 모든 마이그레이션을 추가하고, 이 마이그레이션을 추가하는 방법은 무엇입니까?.gitignore 파일?

Django 마이그레이션 설명서에서 인용한 내용:

각 앱의 마이그레이션 파일은 해당 앱 내부의 "마이그레이션" 디렉터리에 상주하며, 코드베이스의 일부로 커밋되고 배포되도록 설계되었습니다.개발 시스템에서 이러한 마이그레이션을 한 번 만든 다음 동료의 시스템, 스테이징 시스템 및 최종적으로 프로덕션 시스템에서 동일한 마이그레이션을 실행해야 합니다.

이 프로세스를 수행하면 마이그레이션 파일에서 병합 충돌이 발생하지 않습니다.

버전 제어 분기를 병합할 때 동일한 상위 마이그레이션을 기반으로 여러 마이그레이션을 수행하는 상황이 발생할 수 있습니다(예: 다른 개발자가 동시에 마이그레이션을 도입한 경우).이 문제를 해결하는 한 가지 방법은 merge_migration을 도입하는 것입니다.종종 이 작업은 명령을 사용하여 자동으로 수행할 수 있습니다.

./manage.py makemigrations --merge

현재의 모든 헤드 마이그레이션에 의존하는 새로운 마이그레이션이 도입될 것입니다.물론 헤드 마이그레이션 간에 충돌이 없는 경우에만 작동하며, 이 경우 문제를 수동으로 해결해야 합니다.

---

여기에 있는 일부 사람들이 버전 관리로 마이그레이션을 수행하면 안 된다고 제안했기 때문에 실제로 마이그레이션을 수행해야 하는 이유에 대해 자세히 설명하고자 합니다.

먼저 운영 시스템에 적용된 마이그레이션 기록이 필요합니다.프로덕션에 변경 사항을 배포하고 데이터베이스를 마이그레이션하려면 현재 상태에 대한 설명이 필요합니다.각 프로덕션 데이터베이스에 적용되는 마이그레이션에 대한 별도의 백업을 생성할 수 있지만, 이 작업은 불필요하게 번거로운 작업으로 보입니다.

둘째, 마이그레이션에는 종종 사용자 지정, 손으로 쓴 코드가 포함됩니다.항상 자동으로 생성할 수 있는 것은 아닙니다../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/...

---

운영 환경에서는 다음 명령만 실행합니다.

python manage.py migrate

4 (두 개의 명령 = 2022년 명령 4.0.) (두의개별명령도 =)makemigrations그리고.migrate)

마이그레이션을 만들고 적용하는 별도의 명령이 있는 이유는 버전 제어 시스템으로 마이그레이션을 커밋하고 앱과 함께 제공하기 때문입니다. 이러한 명령을 사용하면 개발이 더 쉬워질 뿐만 아니라 다른 개발자와 실운영 환경에서도 사용할 수 있습니다.

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

TL;DR: 마이그레이션 커밋, 마이그레이션 충돌 해결, Git 워크플로우 조정

충돌을 무시하는 대신 Git 워크플로우를 조정해야 할 것 같습니다.

모든 새 기능은 다른 분기에서 개발되고 꺼내기 요청과 병합되는 것이 이상적입니다.

충돌이 있는 경우 PR을 병합할 수 없으므로 마이그레이션을 포함하여 충돌을 해결하기 위해 기능을 병합해야 하는 사용자가 필요합니다.이것은 서로 다른 팀 간의 조정이 필요할 수 있습니다.

마이그레이션 파일을 커밋하는 것이 중요합니다!갈등이 발생하면 장고가 그 갈등을 해결하는 데 도움을 줄 수도 있습니다;)

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

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

그린필드 프로젝트에서는 종종 마이그레이션을 삭제하고 릴리스할 때 0001_ 마이그레이션으로 처음부터 다시 시작할 수 있지만, 프로덕션 코드가 있는 경우에는 마이그레이션을 하나로 압축할 수 없습니다.

일반적으로 사용되는 솔루션은 마스터에 병합되기 전에 개발자가 원격 변경사항을 가져와야 한다는 것입니다.마이그레이션 버전에 충돌이 있는 경우 로컬 마이그레이션(원격 마이그레이션은 다른 개발자가 실행했으며 운영 중일 수도 있음)의 이름을 N+1로 변경해야 합니다.

중에는 커밋하지 될 하지 말고 마십시오.)add하지만 프로덕션 단계에 들어가면 모델 변경 사항과 스키마를 동기화하기 위해 필요합니다.

을▁the합을 변경해야 합니다.dependencies최신 원격 버전으로.

이것은 장고 마이그레이션뿐만 아니라 다른 유사한 앱(sqlalchemy+alembic, RoR 등)에서도 작동합니다.

개발, 스테이징 및 프로덕션 환경에 별도의 DB가 있는 경우 마이그레이션을 무시합니다.개발 목적으로 로컬 SQLite DB를 사용하고 로컬로 마이그레이션을 실행할 수 있습니다.4개의 지점을 추가로 생성하는 것이 좋습니다.

1. 마스터 - 마이그레이션 없이 새 코드를 치료합니다.이 분기에 연결된 사람이 없습니다.코드 검토에만 사용됨

2. 개발 - 일상적인 개발.푸시/풀 허용.각 개발자는 sqlite DB에서 작업하고 있습니다.

3. Cloud_DEV_env - 원격 클라우드/서버 DEV 환경.당기기만.Dev 데이터베이스의 코드 배포 및 원격 마이그레이션에 사용되는 시스템에서 로컬 마이그레이션 유지

4. Cloud_STAG_env - 원격 클라우드/서버 STARG 환경.당기기만.Stag 데이터베이스의 코드 배포 및 원격 마이그레이션에 사용되는 시스템에서 로컬 마이그레이션 유지

5. Cloud_PROD_env - 원격 클라우드/서버 DEV 환경.당기기만.Prod 데이터베이스의 코드 배포 및 원격 마이그레이션에 사용되는 시스템에서 로컬 마이그레이션 유지

참고: 2, 3, 4 - 마이그레이션은 저장소에 보관할 수 있지만, 풀 요청 병합에 대한 엄격한 규칙이 있어야 합니다. 따라서 배포를 담당하는 사람을 찾기로 결정했습니다. 따라서 모든 마이그레이션 파일을 보유한 유일한 사람이 바로 배포자입니다.모델을 변경할 때마다 원격 DB 마이그레이션을 유지합니다.

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

각 앱의 마이그레이션 파일은 해당 앱 내부의 "마이그레이션" 디렉터리에 상주하며, 코드베이스의 일부로 커밋되고 배포되도록 설계되었습니다.개발 시스템에서 이러한 마이그레이션을 한 번 만든 다음 동료의 시스템, 스테이징 시스템 및 최종적으로 프로덕션 시스템에서 동일한 마이그레이션을 실행해야 합니다.

골든 룰 : 개발 시 한 번 만들고 모두 마이그레이션

많은 마이그레이션 파일을 git에 저장하는 것은 번거롭습니다.마이그레이션 폴더에는 무시해서는 안 되는 파일이 하나만 있습니다.해당 파일은 init.py 파일이며, 이를 무시하면 python은 더 이상 디렉터리 내에서 하위 모듈을 찾지 않으므로 모듈을 가져오려는 시도는 실패합니다.그렇다면 문제는 init.py 을 제외한 모든 마이그레이션 파일을 무시하는 방법이어야 합니까?해결책은 다음과 같습니다. .gitignore 파일에 '0*.py'를 추가하면 작업이 완벽하게 수행됩니다.

이것이 누군가에게 도움이 되기를 바랍니다.

마이그레이션을 커밋하는 것은 재앙을 위한 방법일 뿐입니다.이전 마이그레이션(예: 프로젝트 라이프사이클의 특정 시점에 사용했다가 사용을 중단한 pip 모듈)에서 종속된 경우 마이그레이션은 추적할 수 있는 어느 정도 또는 체인이기 때문입니다.마이그레이션 스레드에서 이러한 종속성의 빵 부스러기를 발견할 수 있으므로 마이그레이션 파일에서 이러한 가져오기를 수동으로 제거해야 합니다.

평결, 당신이 god tier Django dev라는 것을 제외하고, 아마도 당신의 커밋에 마이그레이션을 추가하는 것을 피하세요.

간단한 답변입니다. 저는 보고서에서 마이그레이션을 제외할 것을 제안합니다.코드 병합 후 그냥 실행./manage.py makemigrations그리고 당신은 준비가 다 됐습니다.

긴 답변 마이그레이션 파일을 repo에 넣으면 안 된다고 생각합니다.다른 사용자의 개발 환경과 다른 개발 및 단계 환경의 마이그레이션 상태를 손상시킬 수 있습니다.(예를 들어 슈가 탕의 코멘트 참조).

제 관점에서, 장고 마이그레이션의 목적은 이전 모델 상태와 새로운 모델 상태 사이의 격차를 찾은 다음 그 격차를 직렬화하는 것입니다.코드 병합 후 모델이 변경된 경우 간단한 작업을 수행할 수 있습니다.makemigrations차이를 찾기 위해.동일한 작업을 자동으로 수행하고 버그 없이 수행할 수 있는데 다른 마이그레이션을 수동으로 신중하게 병합하려는 이유는 무엇입니까?장고 문서에는 다음과 같이 나와 있습니다.

이들*(마이그레이션)*은 대부분 자동으로 설계되었습니다.

그런 식으로 보관해주세요.마이그레이션을 수동으로 병합하려면 다른 사용자가 변경한 내용과 변경 사항의 종속성을 완전히 이해해야 합니다.많은 오버헤드가 발생하고 오류가 발생하기 쉽습니다.따라서 추적 모델 파일로 충분합니다.

워크플로우에서 좋은 주제입니다.저는 다른 선택지에 대해 열려 있습니다.

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