क्या मुझे .gitignoreफ़ाइल में Django माइग्रेशन फ़ाइलों को जोड़ना चाहिए ?
मुझे हाल ही में माइग्रेशन संघर्षों के कारण बहुत सारे जीट मुद्दे मिल रहे हैं और सोच रहा था कि क्या मुझे माइग्रेशन फ़ाइलों को अनदेखा करना चाहिए।
यदि ऐसा है, तो मैं उन सभी माइग्रेशन को कैसे जोड़ूंगा, जो मैं अपने ऐप्स में रखता हूं, और उन्हें .gitignoreफ़ाइल में जोड़ रहा हूं ?
जवाबों:
Django माइग्रेशन प्रलेखन से उद्धरण :
प्रत्येक एप्लिकेशन के लिए माइग्रेशन फ़ाइलें उस ऐप के अंदर "माइग्रेशन" निर्देशिका में रहती हैं, और इसके कोडबेस के भाग के रूप में, और इसके लिए प्रतिबद्ध होने के लिए डिज़ाइन की गई हैं। आपको उन्हें एक बार अपनी विकास मशीन पर बनाना चाहिए और उसके बाद अपने सहयोगियों की मशीनों, अपनी स्टेजिंग मशीनों और अंततः अपनी उत्पादन मशीनों पर समान माइग्रेशन चलाना चाहिए।
यदि आप इस प्रक्रिया का पालन करते हैं, तो आपको माइग्रेशन फ़ाइलों में कोई मर्ज विरोध नहीं होना चाहिए।
संस्करण नियंत्रण शाखाओं को मर्ज करते समय, आप अभी भी ऐसी स्थिति का सामना कर सकते हैं जहां आपके पास एक ही मूल माइग्रेशन के आधार पर कई माइग्रेशन हैं, जैसे कि यदि अलग-अलग डेवलपर्स ने समवर्ती रूप से माइग्रेशन पेश किया है। इस स्थिति को हल करने का एक तरीका _merge_migration_ को लागू करना है। अक्सर यह स्वचालित रूप से कमांड के साथ किया जा सकता है
./manage.py makemigrations --mergeजो एक नया माइग्रेशन पेश करेगा जो सभी वर्तमान हेड माइग्रेशन पर निर्भर करता है। बेशक यह केवल तब काम करता है जब सिर के पलायन के बीच कोई संघर्ष नहीं होता है, जिस स्थिति में आपको समस्या को मैन्युअल रूप से हल करना होगा।
यह देखते हुए कि यहां कुछ लोगों ने सुझाव दिया कि आपको संस्करण नियंत्रण के लिए अपना माइग्रेशन नहीं करना चाहिए , मैं उन कारणों पर विस्तार करना चाहूंगा कि आप वास्तव में क्यों हैं ऐसा करना चाहिए ।
सबसे पहले, आपको अपने उत्पादन प्रणालियों पर लागू होने वाले पलायन का रिकॉर्ड चाहिए। यदि आप उत्पादन में परिवर्तन करते हैं और डेटाबेस को स्थानांतरित करना चाहते हैं, तो आपको वर्तमान स्थिति का विवरण चाहिए। आप प्रत्येक उत्पादन डेटाबेस पर लागू किए गए माइग्रेशन का एक अलग बैकअप बना सकते हैं, लेकिन यह अनावश्यक रूप से बोझिल लगता है।
दूसरा, माइग्रेशन में अक्सर कस्टम, हस्तलिखित कोड होते हैं। उनके साथ स्वचालित रूप से उत्पन्न करना हमेशा संभव नहीं होता है ./manage.py makemigrations।
तीसरा, माइग्रेशन को कोड समीक्षा में शामिल किया जाना चाहिए। वे आपके उत्पादन प्रणाली में महत्वपूर्ण बदलाव हैं, और बहुत सारी चीजें हैं जो उनके साथ गलत हो सकती हैं।
इसलिए संक्षेप में, यदि आप अपने उत्पादन डेटा की परवाह करते हैं, तो कृपया अपने माइग्रेशन को संस्करण नियंत्रण में जांचें।
आप नीचे दी गई प्रक्रिया का पालन कर सकते हैं।
आप makemigrationsस्थानीय रूप से चला सकते हैं और यह माइग्रेशन फ़ाइल बनाता है। रेपो के लिए इस नई माइग्रेशन फ़ाइल को कमिट करें।
मेरी राय में आपको 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 migratemigrateऔर makemigrationsप्रतिबद्ध पलायन के लिए कभी नहीं । ऐसा कभी नहीं सोचा था।
2018 डॉक्स, Django 2.0 से उद्धरण। (दो अलग-अलग कमांड = makemigrationsऔर migrate)
कारण यह है कि माइग्रेशन बनाने और लागू करने के लिए अलग-अलग कमांड हैं क्योंकि आप अपने संस्करण नियंत्रण प्रणाली के लिए माइग्रेशन करेंगे और उन्हें अपने ऐप के साथ शिप करेंगे; वे न केवल आपके विकास को आसान बनाते हैं, वे अन्य डेवलपर्स और उत्पादन में भी उपयोग करने योग्य होते हैं।
TL; DR: माइग्रेशन प्रतिबद्ध करें, माइग्रेशन संघर्षों को हल करें, अपने git वर्कफ़्लो को समायोजित करें।
लगता है कि आपको अपना समायोजन करने की आवश्यकता होगी संघर्षों को अनदेखा करने के बजाय git वर्कफ़्लो ।
आदर्श रूप से, हर नई सुविधा को एक अलग शाखा में विकसित किया जाता है, और वापस एक के साथ विलय कर दिया जाता है पुल अनुरोध के ।
यदि कोई विरोध है, तो PRs को मर्ज नहीं किया जा सकता है, इसलिए संघर्ष को हल करने के लिए उनकी विशेषता को मर्ज करने की आवश्यकता है, जिसमें माइग्रेशन शामिल हैं। इसके लिए विभिन्न टीमों के बीच समन्वय की आवश्यकता हो सकती है।
यह महत्वपूर्ण है, हालांकि माइग्रेशन फ़ाइलों को करने के लिए! यदि कोई विरोध उत्पन्न होता है, तो Django आपको उन संघर्षों को हल करने में भी मदद कर सकता है ;)
मैं कल्पना क्यों नहीं कर सकता सकता कि जब तक आप किसी तरह से माइग्रेशन संपादित नहीं कर रहे हैं, तब तक आपको संघर्ष हो रहा है? यह आमतौर पर बुरी तरह से समाप्त होता है - अगर किसी को कुछ मध्यवर्ती छूट जाती है तो वे सही संस्करण से अपग्रेड नहीं होंगे, और डेटाबेस की उनकी प्रतिलिपि दूषित हो जाएगी।
मेरे द्वारा अनुसरण की जाने वाली प्रक्रिया बहुत सरल है - जब भी आप किसी एप्लिकेशन के लिए मॉडल बदलते हैं, तो आप एक माइग्रेशन भी करते हैं, और फिर वह माइग्रेशन नहीं बदलता है - यदि आपको मॉडल में कुछ अलग करने की आवश्यकता है, तो आप मॉडल को बदलते हैं और एक प्रतिबद्ध करते हैं आपके परिवर्तनों के साथ नया प्रवासन।
ग्रीनफील्ड परियोजनाओं में, आप अक्सर माइग्रेशन को हटा सकते हैं और रिलीज़ होने पर 0001_ माइग्रेशन के साथ खरोंच से शुरू कर सकते हैं, लेकिन यदि आपके पास उत्पादन कोड है, तो आप (हालांकि आप एक में माइग्रेशन को स्क्वैश कर सकते हैं) नहीं कर सकते।
आमतौर पर उपयोग किया जाने वाला समाधान, यह है कि, कुछ भी मास्टर में विलय करने से पहले, डेवलपर को किसी भी दूरस्थ परिवर्तन को खींचना चाहिए। यदि माइग्रेशन संस्करणों में कोई विरोध है, तो उसे अपने स्थानीय का नाम बदलना चाहिए माइग्रेशन का (दूरस्थ एक को अन्य devs द्वारा चलाया गया है, और, संभवतः, उत्पादन में), N + 1 के लिए।
विकास के दौरान यह सिर्फ न-कमिटेड माइग्रेशन के लिए ठीक हो सकता है (हालांकि एक अनदेखी न addकरें , बस उन्हें न करें)। लेकिन एक बार जब आप उत्पादन में चले गए, तो स्कीमा को मॉडल परिवर्तन के साथ सिंक करने के लिए आपको उनकी आवश्यकता होगी।
फिर आपको फ़ाइल को संपादित करने, और dependenciesनवीनतम दूरस्थ संस्करण में बदलने की आवश्यकता है।
यह Django के माइग्रेशन के साथ-साथ अन्य समान ऐप (sqlalchemy + alembic, RoR, etc) के लिए काम करता है।
Git में माइग्रेशन फ़ाइलों का एक गुच्छा गड़बड़ है। माइग्रेशन फ़ोल्डर में केवल एक फ़ाइल है जिसे आपको अनदेखा नहीं करना चाहिए। वह फ़ाइल init .py फ़ाइल है, यदि आप इसे अनदेखा करते हैं, तो अजगर अब निर्देशिका के अंदर सबमॉड्यूल की तलाश नहीं करेगा, इसलिए मॉड्यूल आयात करने का कोई भी प्रयास विफल हो जाएगा। तो सवाल यह होना चाहिए कि सभी माइग्रेशन फ़ाइलों को अनदेखा कैसे करें लेकिन init .py? इसका समाधान है: .gitignore फ़ाइलों में '0 * .py' जोड़ें और यह पूरी तरह से काम करता है।
आशा है कि यह किसी की मदद करता है।
माइग्रेशन Gitignore, यदि आपके पास विकास, मंचन और उत्पादन पर्यावरण के लिए अलग-अलग DBs हैं। देव के लिए। उद्देश्य आप स्थानीय साइक्लाइट डीबी का उपयोग कर सकते हैं और स्थानीय स्तर पर पलायन के साथ खेल सकते हैं। मैं आपको चार अतिरिक्त शाखाएँ बनाने की सलाह दूंगा:
मास्टर - माइग्रेशन के बिना साफ ताजा कोड। कोई भी इस शाखा से नहीं जुड़ा है। केवल कोड समीक्षाओं के लिए उपयोग किया जाता है
विकास - दैनिक विकास। पुश / पुल स्वीकृत। प्रत्येक डेवलपर sqlite DB पर काम कर रहा है
Cloud_DEV_env - दूरस्थ क्लाउड / सर्वर DEV वातावरण। केवल खींचो। मशीन पर स्थानीय रूप से माइग्रेशन रखें, जिसका उपयोग देव डेटाबेस के कोड परिनियोजन और दूरस्थ माइग्रेशन के लिए किया जाता है
Cloud_STAG_env - दूरस्थ क्लाउड / सर्वर STAG वातावरण। केवल खींचो। मशीन पर स्थानीय रूप से माइग्रेशन रखें, जिसका उपयोग कोड तैनाती और स्टैग डेटाबेस के दूरस्थ माइग्रेशन के लिए किया जाता है
Cloud_PROD_env - दूरस्थ क्लाउड / सर्वर DEV वातावरण। केवल खींचो। मशीन पर स्थानीय रूप से माइग्रेशन रखें, जिसका उपयोग कोड और उत्पाद डेटाबेस के दूरस्थ माइग्रेशन के लिए किया जाता है
नोट: 2, 3, 4 - माइग्रेशन को रिपोज में रखा जा सकता है, लेकिन पुल अनुरोध मर्जिंग के सख्त नियम होने चाहिए, इसलिए हमने एक व्यक्ति को खोजने का फैसला किया, जो तैनाती के लिए जिम्मेदार है, इसलिए केवल वही व्यक्ति जिसके पास सभी माइग्रेशन फाइलें हैं - हमारी तैनाती -er। वह हर बार जब हम मॉडल्स में कोई बदलाव करते हैं तो वह दूरस्थ DB माइग्रेशन रखता है।
लघु उत्तर
मैं रेपो में पलायन को छोड़कर प्रस्तावित करता हूं। कोड मर्ज के बाद, बस चलाएं ./manage.py makemigrationsऔर आप सभी सेट हैं।
लंबा जवाब मुझे नहीं लगता कि आपको रेपो में माइग्रेशन फाइल डालनी चाहिए। यह दूसरे व्यक्ति के देव वातावरण और अन्य ठेस और मंच के माहौल में प्रवासन राज्यों को खराब करेगा। (उदाहरण के लिए सुगर तांग की टिप्पणी देखें)।
मेरे विचार में, Django प्रवास का उद्देश्य पिछले मॉडल राज्यों और नए मॉडल राज्यों के बीच अंतराल को खोजना है, और फिर अंतराल को क्रमबद्ध करना है। यदि आपका मॉडल कोड मर्ज के बाद बदलता है, तो आप makemigrationsअंतर का पता लगाने के लिए सरल कर सकते हैं। जब आप मैन्युअल रूप से और सावधानीपूर्वक अन्य माइग्रेशन को मर्ज करना चाहते हैं, तो आप उसी और स्वचालित रूप से बग को कैसे प्राप्त कर सकते हैं? Django प्रलेखन कहते हैं,
वे * (माइग्रेशन) * ज्यादातर स्वचालित होने के लिए डिज़ाइन किए गए हैं
; कृपया इसे इस तरह रखें। माइग्रेशन को मैन्युअल रूप से मर्ज करने के लिए, आपको पूरी तरह से समझना होगा कि दूसरों ने क्या बदला है और परिवर्तनों की कोई निर्भरता। यह बहुत अधिक उपरि और त्रुटि प्रवण है। इसलिए ट्रैकिंग मॉडल फ़ाइल पर्याप्त है।
यह वर्कफ़्लो पर एक अच्छा विषय है। मैं अन्य विकल्पों के लिए खुला हूं।
manage.py makemigrations --mergeमेरे लिए पूरी तरह से स्वचालित रूप से काम करता है।
makemigrations some_app, तो न केवल उस सदस्य के नियंत्रण में आने वाले मॉडल प्रभावित होंगे, बल्कि अन्य संबंधित मॉडल भी प्रभावित होंगे। यही है, अन्य ऐप्स में माइग्रेशन फ़ाइलें (00 * _ *) बदल दी जाएंगी। और यह GitHub से धक्का या खींचने के दौरान कई संघर्ष समस्याओं का कारण बनता है। चूंकि वर्तमान में हमारा सिस्टम उत्पादन के लिए तैयार नहीं है, इसलिए हम सिर्फ.gitignoreमाइग्रेशन फ़ाइल। हम अभी भी नहीं जानते कि सिस्टम के उत्पादन के बाद इसे कैसे हल किया जाए। क्या किसी के पास कोई उपाय है?