Git submodule กับ Git clone

ฉันกำลังทำงานในโครงการโอเพนซอร์ซบน GitHub

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

นักพัฒนาคนหนึ่งส่งคำขอดึงด้วยความคิดที่จะเปลี่ยนนี้สำเนาโดยsubmodule คอมไพล์

และฉันกำลังพิจารณาว่ามันเป็นความคิดที่ดีหรือไม่

Git submodule ข้อดี:

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

Git submodule ข้อเสีย:

• ดูเหมือนว่า submodules git จะเพิ่มความซับซ้อนจากผู้ดูแลไปยังบุคคลที่จะโคลน / ดึงโครงการ (ขั้นตอนเพิ่มเติมที่จำเป็นหลังจากที่คุณโคลนเพื่อเริ่มทำงานกับโครงการ: "git submodule init", "git submodule update"

คุณมีความคิดเห็นอย่างไรกับเรื่องนี้?

อีกหนึ่งสิ่ง. ปัญหานี้เป็นไลบรารี่ขนาดเล็กที่มีการพึ่งพาภายนอกที่ จำกัด มาก ฉันคิดว่าเครื่องมือสร้างใด ๆ จะ overkill สำหรับตอนนี้

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

• แยกที่เก็บของบุคคลที่สามในภายหลังหากมีการเปลี่ยนแปลงที่น่าสนใจ
• ผสานในการปรับปรุงใหม่จากที่เก็บของบุคคลที่สาม (การผสานบันทึกย่อไม่ใช่เขียนทับ)

สำหรับผู้ใช้ Git ที่ไม่ซับซ้อนพอที่จะเข้าใจ submodules แนวทางย่อยทำให้การโคลนโครงการของคุณไม่ยากกว่าโคลนอื่น ๆ ข้อความสั้น ๆ จากเอกสาร:

Subtrees อนุญาตให้โครงการย่อยรวมอยู่ในไดเรกทอรีย่อยของโครงการหลักทางเลือกรวมถึงประวัติทั้งหมดของโครงการย่อย

ตัวอย่างเช่นคุณสามารถรวมซอร์สโค้ดของไลบรารีเป็นไดเรกทอรีย่อยของแอปพลิเคชันของคุณ

Subtrees จะไม่สับสนกับ submodules ซึ่งมีความหมายสำหรับงานเดียวกัน subtrees แตกต่างจาก submodules ไม่จำเป็นต้องมีสิ่งปลูกสร้างพิเศษใด ๆ (เช่นไฟล์. gitmodule หรือ gitlinks) อยู่ในที่เก็บของคุณและไม่บังคับให้ผู้ใช้ปลายทางของที่เก็บของคุณทำอะไรเป็นพิเศษหรือเพื่อทำความเข้าใจวิธีการทำงานของ subtrees ทรีย่อยเป็นเพียงไดเรกทอรีย่อยที่สามารถผูกพันแยกและรวมเข้ากับโครงการของคุณในแบบที่คุณต้องการ

ฉันได้ตั้งโครงการในที่ทำงานโดยใช้ submodules และปัญหาในการรักษา submodules ให้ทันสมัยอยู่เสมอใน clones ของทุกคนนั้นทำงานมากเกินไป เมื่อเร็ว ๆ นี้ฉันเปลี่ยนไปใช้ subtrees ทุกที่และปัญหาเหล่านั้นก็หายไป

โปรดทราบว่า git-subtree เป็นส่วนหนึ่งของgit/contribไดเรกทอรีและจะต้องติดตั้งแยกต่างหาก

ข้อเสียเปรียบประการหนึ่งของการใช้ submodules คือ tarballs หรือ zip-archives บน Github (และบริการอื่น ๆ อีกมากมาย) ไม่รวมถึงแหล่งที่มาของ submodules นั่นคือจดหมายเหตุไม่ได้อยู่ในตัวเอง นี่เป็นปัญหาถ้าที่เก็บมีขนาดเล็กและไม่มีสคริปต์บิลด์เช่นไซต์ HTML แบบสแตติกขึ้นอยู่กับไลบรารี JavaScript

นี่คือสถานที่ที่เหมาะสำหรับการใช้ submodules มันลดขนาดและความซับซ้อนของที่เก็บของคุณและทำให้ง่ายต่อการอัปเดตไลบรารีภายนอกเป็นเวอร์ชันใหม่

พวกเขาไม่ยากที่จะเข้าใจวิธีการใช้และพวกเขามักใช้ในสถานการณ์นี้ดังนั้นโปรดจดบันทึกใน README ของโครงการที่คุณใช้ประโยชน์จาก submodules และสิ่งที่ต้องทำและผู้คนควรจะสามารถคิดได้ มันออกมา ครั้งแรกที่ฉันพบที่เก็บข้อมูลที่มี submodule ฉันได้รับมันและทำงานใน 10 ถึง 15 นาทีและไม่เคยมีปัญหากับการหาสิ่งที่ต้องทำตั้งแต่

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

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