Django geçiş dosyalarını .gitignore dosyasına eklemeli miyim?

.gitignoreDosyaya Django geçiş dosyalarını eklemeli miyim?

Son zamanlarda göç çatışmaları nedeniyle çok fazla git sorunu yaşıyorum ve geçiş dosyalarını yoksay olarak işaretlemem gerekip gerekmediğini merak ediyordum.

Öyleyse, uygulamalarımda sahip olduğum tüm taşıma işlemlerini nasıl ekleyebilirim ve bunları .gitignoredosyaya ekleyebilirim ?

Django geçiş belgelerinden alıntı yapmak :

Her uygulamanın taşıma dosyaları, o uygulamanın içindeki bir "geçişler" dizininde bulunur ve kod tabanına bağlı olmak ve onun kod tabanının bir parçası olarak dağıtılmak üzere tasarlanmıştır. Bunları bir kez geliştirme makinenizde yapmalı ve ardından aynı geçişleri iş arkadaşlarınızın makinelerinde, evreleme makinelerinde ve nihayetinde üretim makinelerinizde çalıştırmalısınız.

Bu süreci izlerseniz, geçiş dosyalarında herhangi bir birleştirme çakışması görmemeniz gerekir.

Sürüm kontrol dallarını birleştirirken, aynı ana geçişe dayalı birden fazla geçişinizin olduğu bir durumla karşılaşabilirsiniz, örneğin, farklı geliştiricilere aynı anda bir geçiş başlattıysa. Bu durumu çözmenin bir yolu, bir _merge_migration_ oluşturmaktır. Genellikle bu komutla otomatik olarak yapılabilir

./manage.py makemigrations --merge

Bu, mevcut tüm kafa geçişlerine bağlı yeni bir geçişi getirecektir. Elbette bu yalnızca kafa geçişleri arasında herhangi bir çakışma olmadığında işe yarar, bu durumda sorunu manuel olarak çözmeniz gerekecektir.

Buradaki bazı kişilerin , geçişlerinizi sürüm kontrolüne dahil etmemenizi önerdiği göz önüne alındığında, gerçekte neden bunu yapmanız gerektiğinin nedenlerini genişletmek istiyorum .

Öncelikle, üretim sistemlerinize uygulanan geçişlerin bir kaydına ihtiyacınız var. Değişiklikleri üretime dağıtırsanız ve veritabanını taşımak istiyorsanız, mevcut durumun bir açıklamasına ihtiyacınız vardır. Her üretim veritabanına uygulanan geçişlerin ayrı bir yedeğini oluşturabilirsiniz, ancak bu gereksiz yere külfetli görünmektedir.

İkincisi, geçişler genellikle özel, el yazısıyla yazılmış kod içerir. Bunları ile otomatik olarak oluşturmak her zaman mümkün değildir ./manage.py makemigrations.

Üçüncü olarak, geçişler kod incelemesine dahil edilmelidir. Üretim sisteminizdeki önemli değişikliklerdir ve onlarda yanlış gidebilecek pek çok şey vardır.

Kısacası, üretim verilerinizle ilgileniyorsanız, lütfen sürüm kontrolüne geçişlerinizi kontrol edin.

Aşağıdaki süreci takip edebilirsiniz.

makemigrationsYerel olarak çalıştırabilirsiniz ve bu, geçiş dosyasını oluşturur. Bu yeni geçiş dosyasını depoya kaydedin.

Bence makemigrationsüretimde hiç çalışmamalısın . migrateÜretimde çalıştırabilirsiniz ve yerelden taahhüt ettiğiniz geçiş dosyasından geçişlerin uygulandığını göreceksiniz. Bu şekilde tüm çatışmalardan kaçınabilirsiniz.

YEREL ENV İÇİNDE , geçiş dosyalarını oluşturmak için,

python manage.py makemigrations 
python manage.py migrate

Şimdi bu yeni oluşturulan dosyaları işleyin, aşağıdaki gibi.

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

ÜRETİM ENV'DA , sadece aşağıdaki komutu çalıştırın.

python manage.py migrate

2018 belgeleri, Django 2.0'dan alıntı. (iki ayrı komut = makemigrationsve migrate)

Geçiş yapmak ve uygulamak için ayrı komutlar olmasının nedeni, sürüm kontrol sisteminize geçişleri gerçekleştirmeniz ve bunları uygulamanızla birlikte göndermenizdir; sadece geliştirmenizi kolaylaştırmakla kalmaz, aynı zamanda diğer geliştiriciler tarafından ve üretimde kullanılabilirler.

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

TL; DR: geçişleri gerçekleştirin, geçiş çakışmalarını çözün, git iş akışınızı ayarlayın.

Anlaşmazlıkları görmezden gelmek yerine git iş akışınızı ayarlamanız gerekiyormuş gibi geliyor .

İdeal olarak, her yeni özellik farklı bir dalda geliştirilir ve bir çekme isteği ile geri birleştirilir .

Bir çatışma varsa PR'ler birleştirilemez, bu nedenle göçler de dahil olmak üzere çatışmayı çözmek için kimin özelliğini birleştirmesi gerekiyor. Bunun için farklı ekipler arasında koordinasyon gerekebilir.

Yine de geçiş dosyalarını işlemek önemlidir! Bir çatışma ortaya çıkarsa, Django bu çatışmaları çözmenize bile yardımcı olabilir ;)

Taşıma işlemlerini bir şekilde düzenlemediğiniz sürece neden çatışmalar yaşayacağınızı hayal edemiyorum ? Bu genellikle kötü sonuçlanır - eğer birisi bazı ara taahhütleri kaçırırsa, doğru sürümden yükseltilmez ve veritabanının kopyası bozulur.

İzlediğim süreç oldukça basit - ne zaman bir uygulamanın modellerini değiştirirseniz, bir geçiş de yaparsınız ve sonra bu geçiş değişmez - modelde farklı bir şeye ihtiyacınız varsa, modeli değiştirir ve bir değişikliklerinizle birlikte yeni göç.

Yeşil alan projelerinde, yayınladığınızda genellikle taşıma işlemlerini silebilir ve 0001_ geçişi ile sıfırdan başlayabilirsiniz, ancak üretim kodunuz varsa, o zaman yapamazsınız (ancak taşıma işlemlerini bir taneye indirgeyebilirsiniz).

Genellikle kullanılan çözüm, herhangi bir şey ana ile birleştirilmeden önce, geliştiricinin herhangi bir uzaktan değişikliği çekmesi gerektiğidir. Geçiş sürümlerinde bir çakışma varsa, yerel geçişini (uzaktaki başka geliştiriciler tarafından yürütülmüştür ve muhtemelen üretimde) N + 1 olarak yeniden adlandırmalıdır.

Geliştirme sırasında, geçişleri taahhüt etmemek sorun olabilir (yine de bir göz ardı etmeyin, sadece addbunları yapmayın ). Ancak üretime geçtiğinizde, şemayı model değişiklikleriyle uyumlu tutmak için bunlara ihtiyacınız olacak.

Daha sonra dosyayı düzenlemeniz ve dependenciesen son uzak sürüme değiştirmeniz gerekir .

Bu, Django geçişlerinin yanı sıra diğer benzer uygulamalar (sqlalchemy + alembic, RoR, vb.) İçin çalışır.

Git'te bir sürü taşıma dosyasına sahip olmak dağınıktır. Taşıma klasöründe göz ardı etmemeniz gereken tek bir dosya var. Bu dosya init .py dosyasıdır, bunu göz ardı ederseniz, python artık dizin içindeki alt modülleri aramayacaktır, bu nedenle modülleri içe aktarma girişimleri başarısız olacaktır. Öyleyse soru, başlangıç .py dışındaki tüm taşıma dosyalarının nasıl yoksayılacağı olmalıdır. Çözüm şudur: .gitignore dosyalarına '0 * .py' ekleyin ve işi mükemmel bir şekilde yapar.

Umarım bu birine yardımcı olur.

Geliştirme, Aşama ve Üretim ortamı için ayrı DB'leriniz varsa geçişleri gitignore edin. Dev için. Amaçlar Yerel sqlite DB'yi kullanabilir ve yerel olarak geçişlerle oynayabilirsiniz. Dört ek şube oluşturmanızı tavsiye ederim:

1. Master - Geçiş yapmadan taze kodu temizleyin. Bu şubeye kimse bağlı değil. Yalnızca kod incelemeleri için kullanılır

2. Gelişim - günlük gelişme. İtme / çekme kabul edildi. Her geliştirici sqlite DB üzerinde çalışıyor

3. Cloud_DEV_env - uzak bulut / sunucu DEV ortamı. Sadece çekin. Geliştirme veritabanının kod dağıtımı ve uzaktan geçişleri için kullanılan makinede taşıma işlemlerini yerel olarak tutun

4. Cloud_STAG_env - uzak bulut / sunucu STAG ortamı. Sadece çekin. Stag veritabanının kod dağıtımı ve uzaktan geçişleri için kullanılan makinede geçişleri yerel olarak tutun

5. Cloud_PROD_env - uzak bulut / sunucu DEV ortamı. Sadece çekin. Taşıma işlemlerini, Prod veritabanının kod dağıtımı ve uzaktan geçişleri için kullanılan makinede yerel olarak tutun

Notlar: 2, 3, 4 - geçişler depolarda tutulabilir, ancak birleştirme istekleri için katı kurallar olmalıdır, bu nedenle dağıtımlardan sorumlu bir kişi bulmaya karar verdik, bu nedenle tüm taşıma dosyalarına sahip olan tek kişi - bizim dağıtımımız -er. Modellerde her değişiklik olduğunda uzak DB geçişlerini tutar.

Kısa cevap Depodaki göçleri dışlamayı öneriyorum. Kod birleştirmeden sonra, sadece çalıştırın ./manage.py makemigrationsve hazırsınız.

Uzun cevap Geçiş dosyalarını depoya koymanız gerektiğini düşünmüyorum. Diğer kişinin geliştirme ortamındaki ve diğer üretim ve sahne ortamındaki göç durumlarını bozacaktır. (örnekler için Sugar Tang'ın yorumuna bakın).

Benim görüşüme göre, Django geçişlerinin amacı, önceki model durumları ile yeni model durumları arasındaki boşlukları bulmak ve ardından boşluğu serileştirmektir. Kod birleştirmeden sonra modeliniz değişirse makemigrations, boşluğu bulmak için basitçe yapabilirsiniz . Aynısını otomatik olarak ve hatasız olarak elde edebildiğiniz halde neden diğer geçişleri manuel ve dikkatli bir şekilde birleştirmek istiyorsunuz? Django belgeleri diyor ki,

Bunlar * (geçişler) * çoğunlukla otomatik olacak şekilde tasarlanmıştır

; lütfen öyle kalsın. Taşıma işlemlerini manuel olarak birleştirmek için, başkalarının nelerin değiştiğini ve değişikliklere olan bağımlılığı tam olarak anlamanız gerekir. Bu çok fazla ek yük ve hataya meyillidir. Bu yüzden modeller dosyasını takip etmek yeterlidir.

İş akışında iyi bir konudur. Diğer seçeneklere açığım.