ฉันควรเพิ่มไฟล์การโอนย้าย Django ในไฟล์. gitignore หรือไม่

ฉันควรเพิ่มไฟล์การโอนย้าย Django ใน.gitignoreไฟล์หรือไม่

เมื่อเร็ว ๆ นี้ฉันได้รับปัญหาเกี่ยวกับคอมไพล์มากมายเนื่องจากความขัดแย้งในการย้ายข้อมูลและสงสัยว่าฉันควรทำเครื่องหมายไฟล์การย้ายข้อมูลเป็นละเว้นหรือไม่

ถ้าเป็นเช่นนั้นฉันจะเพิ่มการย้ายข้อมูลทั้งหมดที่มีในแอปของฉันและเพิ่มลงใน.gitignoreไฟล์ได้อย่างไร

การอ้างอิงจากเอกสารการโยกย้าย Django :

ไฟล์การย้ายข้อมูลสำหรับแต่ละแอปจะอยู่ในไดเร็กทอรี "การย้ายข้อมูล" ภายในแอปนั้นและได้รับการออกแบบมาเพื่อให้ใช้งานและแจกจ่ายเป็นส่วนหนึ่งของ codebase คุณควรสร้างมันครั้งเดียวในเครื่องพัฒนาของคุณจากนั้นเรียกใช้การย้ายข้อมูลเดียวกันบนเครื่องของเพื่อนร่วมงานเครื่องจัดเตรียมของคุณและในที่สุดเครื่องจักรการผลิตของคุณ

หากคุณทำตามขั้นตอนนี้คุณไม่ควรได้รับความขัดแย้งในการรวมในไฟล์การย้ายข้อมูล

เมื่อรวมสาขาการควบคุมเวอร์ชันเข้าด้วยกันคุณอาจยังคงพบกับสถานการณ์ที่คุณมีการย้ายข้อมูลหลายรายการโดยอิงจากการย้ายข้อมูลระดับบนสุดเดียวกันเช่นในกรณีที่ผู้พัฒนารายอื่นแนะนำการโยกย้ายไปพร้อมกัน วิธีหนึ่งในการแก้ไขสถานการณ์นี้คือการแนะนำ _merge_migration_ บ่อยครั้งสิ่งนี้สามารถทำได้โดยอัตโนมัติด้วยคำสั่ง

./manage.py makemigrations --merge

ซึ่งจะแนะนำการย้ายข้อมูลใหม่ที่ขึ้นอยู่กับการย้ายหัวปัจจุบันทั้งหมด แน่นอนว่าจะใช้ได้เฉพาะเมื่อไม่มีความขัดแย้งระหว่างการย้ายข้อมูลส่วนหัวซึ่งในกรณีนี้คุณจะต้องแก้ไขปัญหาด้วยตนเอง

เนื่องจากมีบางคนในที่นี้แนะนำว่าคุณไม่ควรโอนย้ายข้อมูลไปยังการควบคุมเวอร์ชันฉันต้องการขยายเหตุผลว่าทำไมคุณจึงควรทำเช่นนั้น

ขั้นแรกคุณต้องมีบันทึกการย้ายข้อมูลที่ใช้กับระบบการผลิตของคุณ ถ้าคุณปรับใช้การเปลี่ยนแปลงในการใช้งานจริงและต้องการย้ายฐานข้อมูลคุณต้องมีคำอธิบายสถานะปัจจุบัน คุณสามารถสร้างการสำรองข้อมูลแยกต่างหากของการย้ายข้อมูลที่ใช้กับฐานข้อมูลการผลิตแต่ละรายการ แต่ดูเหมือนจะยุ่งยากโดยไม่จำเป็น

ประการที่สองการย้ายข้อมูลมักประกอบด้วยรหัสที่เขียนด้วยลายมือแบบกำหนดเอง เป็นไปไม่ได้ที่จะสร้างโดยอัตโนมัติด้วย./manage.py makemigrations.

ประการที่สามการย้ายข้อมูลควรรวมอยู่ในการตรวจสอบโค้ด เป็นการเปลี่ยนแปลงที่สำคัญในระบบการผลิตของคุณและมีหลายสิ่งหลายอย่างที่อาจผิดพลาดได้

ดังนั้นในระยะสั้นหากคุณสนใจเกี่ยวกับข้อมูลการผลิตของคุณโปรดตรวจสอบการย้ายข้อมูลเป็นการควบคุมเวอร์ชัน

คุณสามารถทำตามขั้นตอนด้านล่างนี้

คุณสามารถเรียกใช้makemigrationsภายในเครื่องและสิ่งนี้จะสร้างไฟล์การย้ายข้อมูล ยอมรับไฟล์การย้ายข้อมูลใหม่นี้เพื่อทำซ้ำ

ในความคิดของฉันคุณไม่ควรทำงานmakemigrationsในการผลิตเลย คุณสามารถเรียกใช้migrateในการใช้งานจริงและคุณจะเห็นว่ามีการใช้การย้ายข้อมูลจากไฟล์การย้ายข้อมูลที่คุณยืนยันจากโลคัล ด้วยวิธีนี้คุณสามารถหลีกเลี่ยงความขัดแย้งทั้งหมดได้

ใน ENV ท้องถิ่นเพื่อสร้างไฟล์การโอนย้าย

python manage.py makemigrations 
python manage.py migrate

ตอนนี้ยอมรับไฟล์ที่สร้างขึ้นใหม่เหล่านี้เช่นด้านล่าง

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

ในการผลิต ENVให้เรียกใช้คำสั่งด้านล่างเท่านั้น

python manage.py migrate

อ้างจากเอกสาร 2018, Django 2.0 (สองคำสั่งแยกกัน = makemigrationsและmigrate)

เหตุผลที่มีคำสั่งแยกต่างหากในการสร้างและใช้การย้ายเนื่องจากคุณจะโอนย้ายข้อมูลไปยังระบบควบคุมเวอร์ชันของคุณและจัดส่งพร้อมกับแอปของคุณ พวกเขาไม่เพียง แต่ทำให้การพัฒนาของคุณง่ายขึ้น แต่ยังสามารถใช้โดยนักพัฒนารายอื่นและในการผลิตอีกด้วย

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

TL; DR: กำหนดการย้ายข้อมูลแก้ไขข้อขัดแย้งในการย้ายข้อมูลปรับเวิร์กโฟลว์คอมไพล์ของคุณ

รู้สึกเหมือนต้องปรับคอมไพล์ขั้นตอนการทำงานแทนการเพิกเฉยต่อความขัดแย้ง

ตามหลักการแล้วคุณลักษณะใหม่ทั้งหมดได้รับการพัฒนาในสาขาอื่นและรวมกลับเข้ากับคำขอดึงคำขอดึง

PRs ไม่สามารถรวมเข้าด้วยกันได้หากมีข้อขัดแย้งดังนั้นผู้ที่ต้องการผสานคุณลักษณะของเขาจำเป็นต้องแก้ไขข้อขัดแย้งรวมถึงการโยกย้าย ซึ่งอาจต้องมีการประสานงานระหว่างทีมต่างๆ

เป็นสิ่งสำคัญแม้ว่าจะต้องยอมรับไฟล์การย้ายข้อมูล! หากความขัดแย้งเกิดขึ้นDjango อาจช่วยคุณแก้ปัญหาความขัดแย้งเหล่านั้นได้ ;)

ฉันนึกไม่ออกว่าทำไมคุณได้รับความขัดแย้งเว้นแต่คุณจะแก้ไขการย้ายข้อมูลด้วยวิธีใด? ซึ่งมักจะจบลงอย่างไม่ดี - หากมีคนพลาดการกระทำระดับกลางพวกเขาจะไม่ได้รับการอัปเกรดจากเวอร์ชันที่ถูกต้องและสำเนาฐานข้อมูลของพวกเขาจะเสียหาย

กระบวนการที่ฉันทำตามนั้นค่อนข้างง่าย - เมื่อใดก็ตามที่คุณเปลี่ยนโมเดลสำหรับแอปคุณจะทำการย้ายข้อมูลด้วยจากนั้นการย้ายข้อมูลนั้นจะไม่เปลี่ยนแปลง - หากคุณต้องการสิ่งที่แตกต่างออกไปในโมเดลคุณก็จะเปลี่ยนโมเดลและยอมรับ การโยกย้ายใหม่ควบคู่ไปกับการเปลี่ยนแปลงของคุณ

ในโครงการกรีนฟิลด์คุณมักจะสามารถลบการย้ายข้อมูลและเริ่มต้นใหม่ตั้งแต่ต้นด้วยการย้ายข้อมูล 0001_ เมื่อคุณเผยแพร่ แต่ถ้าคุณมีรหัสการใช้งานจริงคุณจะทำไม่ได้ (แม้ว่าคุณจะสามารถแยกการย้ายข้อมูลลงเป็นรายการเดียวได้)

วิธีแก้ปัญหาที่มักจะใช้คือก่อนที่จะรวมสิ่งใดเข้าเป็นหลักนักพัฒนาจะต้องดึงการเปลี่ยนแปลงระยะไกล หากมีข้อขัดแย้งในเวอร์ชันการย้ายข้อมูลเขาควรเปลี่ยนชื่อการย้ายข้อมูลภายในเครื่อง (รีโมตถูกรันโดย devs อื่นและอาจอยู่ในระหว่างการผลิต) เป็น N + 1

ในระหว่างการพัฒนาอาจเป็นเรื่องปกติที่จะไม่ทำการโอนย้ายข้อมูล (อย่าเพิ่มการเพิกเฉย แต่อย่าเพิ่งทำadd) แต่เมื่อคุณเริ่มใช้งานจริงแล้วคุณจะต้องใช้เพื่อให้สคีมาซิงค์กับการเปลี่ยนแปลงโมเดล

จากนั้นคุณต้องแก้ไขไฟล์และเปลี่ยนเป็นdependenciesรีโมตเวอร์ชันล่าสุด

สิ่งนี้ใช้ได้กับการโยกย้าย Django รวมถึงแอปอื่น ๆ ที่คล้ายกัน (sqlalchemy + alembic, RoR ฯลฯ )

การมีไฟล์โยกย้ายจำนวนมากในคอมไพล์นั้นยุ่งเหยิง มีเพียงไฟล์เดียวในโฟลเดอร์การย้ายข้อมูลที่คุณไม่ควรละเลย ไฟล์นั้นเป็นไฟล์init. py หากคุณเพิกเฉย python จะไม่มองหาโมดูลย่อยภายในไดเร็กทอรีอีกต่อไปดังนั้นความพยายามใด ๆ ในการนำเข้าโมดูลจะล้มเหลว ดังนั้นคำถามควรจะทำอย่างไรจึงจะละเว้นไฟล์การย้ายข้อมูลทั้งหมด แต่เริ่มต้น. py? วิธีแก้ปัญหาคือ: เพิ่ม '0 * .py' ลงในไฟล์. gitignore และทำงานได้อย่างสมบูรณ์แบบ

หวังว่านี่จะช่วยใครบางคนได้

Gitignore การโอนย้ายหากคุณมี DBs สำหรับการพัฒนาการจัดเตรียมและการผลิตแยกต่างหาก สำหรับ dev. วัตถุประสงค์คุณสามารถใช้ sqlite DB ในเครื่องและเล่นกับการย้ายข้อมูลในเครื่อง ฉันอยากจะแนะนำให้คุณสร้างสาขาเพิ่มเติมสี่สาขา:

1. Master - ทำความสะอาดโค้ดใหม่โดยไม่ต้องย้ายข้อมูล ไม่มีใครเชื่อมต่อกับสาขานี้ ใช้สำหรับการตรวจสอบโค้ดเท่านั้น

2. พัฒนาการ - การพัฒนารายวัน กด / ดึงได้รับการยอมรับ นักพัฒนาแต่ละคนกำลังทำงานบน sqlite DB

3. Cloud_DEV_env - สภาพแวดล้อม DEV บนคลาวด์ / เซิร์ฟเวอร์ระยะไกล ดึงเท่านั้น เก็บการย้ายข้อมูลไว้ในเครื่องซึ่งใช้สำหรับการปรับใช้โค้ดและการย้ายฐานข้อมูล Dev จากระยะไกล

4. Cloud_STAG_env - สภาพแวดล้อม STAG ของคลาวด์ / เซิร์ฟเวอร์ระยะไกล ดึงเท่านั้น เก็บการย้ายข้อมูลไว้ในเครื่องซึ่งใช้สำหรับการปรับใช้โค้ดและการย้ายฐานข้อมูล Stag จากระยะไกล

5. Cloud_PROD_env - สภาพแวดล้อม DEV บนคลาวด์ / เซิร์ฟเวอร์ระยะไกล ดึงเท่านั้น เก็บการย้ายข้อมูลไว้ในเครื่องซึ่งใช้สำหรับการปรับใช้โค้ดและการย้ายฐานข้อมูล Prod จากระยะไกล

หมายเหตุ: 2, 3, 4 - สามารถเก็บการย้ายข้อมูลไว้ใน repos ได้ แต่ควรมีกฎที่เข้มงวดในการรวมการร้องขอการดึงดังนั้นเราจึงตัดสินใจที่จะหาบุคคลที่รับผิดชอบในการปรับใช้ดังนั้นคนเดียวที่มีไฟล์การย้ายข้อมูลทั้งหมด - การปรับใช้ของเรา เอ้อ เขาเก็บการย้ายฐานข้อมูลระยะไกลทุกครั้งที่เรามีการเปลี่ยนแปลงในโมเดล

คำตอบสั้น ๆ ฉันเสนอให้ยกเว้นการย้ายข้อมูลใน repo หลังจากการรวมรหัสเพียงแค่เรียกใช้./manage.py makemigrationsเท่านี้คุณก็พร้อมแล้ว

คำตอบยาว ฉันไม่คิดว่าคุณควรใส่ไฟล์การย้ายข้อมูลลงใน repo มันจะทำลายสถานะการย้ายข้อมูลในสภาพแวดล้อม dev ของบุคคลอื่นและสภาพแวดล้อม prod และ stage อื่น ๆ (ดูตัวอย่างความคิดเห็นของ Sugar Tang)

ในมุมมองของฉันจุดประสงค์ของการโยกย้าย Django คือการหาช่องว่างระหว่างสถานะของโมเดลก่อนหน้ากับสถานะโมเดลใหม่จากนั้นจึงทำให้ช่องว่างเป็นลำดับ หากโมเดลของคุณเปลี่ยนไปหลังจากการผสานโค้ดคุณสามารถทำได้ง่ายๆmakemigrationsเพื่อค้นหาช่องว่าง เหตุใดคุณจึงต้องการผสานการย้ายข้อมูลอื่น ๆ ด้วยตนเองและอย่างระมัดระวังเมื่อคุณสามารถบรรลุสิ่งเดียวกันโดยอัตโนมัติและปราศจากข้อบกพร่อง เอกสาร Djangoกล่าวว่า

พวกเขา * (การย้ายข้อมูล) * 'ได้รับการออกแบบให้ทำงานโดยอัตโนมัติเป็นส่วนใหญ่

; โปรดเก็บไว้อย่างนั้น ในการรวมการย้ายข้อมูลด้วยตนเองคุณต้องเข้าใจอย่างถ่องแท้ถึงสิ่งที่ผู้อื่นเปลี่ยนแปลงและการพึ่งพาการเปลี่ยนแปลงใด ๆ นั่นเป็นค่าใช้จ่ายและข้อผิดพลาดมากมาย ดังนั้นการติดตามไฟล์โมเดลก็เพียงพอแล้ว

เป็นหัวข้อที่ดีในขั้นตอนการทำงาน ฉันเปิดรับตัวเลือกอื่น ๆ