เค้าโครงที่เก็บ GIT สำหรับเซิร์ฟเวอร์ที่มีหลายโครงการ

สิ่งหนึ่งที่ฉันชอบเกี่ยวกับวิธีที่ฉันตั้งค่า Subversion คือฉันสามารถมีที่เก็บหลักเดียวกับหลายโปรเจ็กต์ เมื่อฉันต้องการทำงานในโครงการฉันสามารถตรวจสอบโครงการนั้นได้ แบบนี้

\main
    \ProductA
    \ProductB
    \Shared

แล้ว

svn checkout http://.../main/ProductA

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

1. ตั้งค่าโครงการแยกกันสำหรับแต่ละผลิตภัณฑ์
2. ตั้งค่าโปรเจ็กต์ขนาดใหญ่รายการเดียวและจัดเก็บผลิตภัณฑ์ในโฟลเดอร์ย่อย

มีการพึ่งพาระหว่างผลิตภัณฑ์ดังนั้นโครงการขนาดใหญ่เดียวจึงเหมาะสม เราจะใช้เซิร์ฟเวอร์ที่นักพัฒนาทุกคนสามารถแชร์โค้ดของพวกเขาได้ ฉันได้ทำงานผ่าน SSH และ HTTP แล้วและส่วนนั้นฉันชอบ อย่างไรก็ตามที่เก็บใน SVN มีขนาดหลาย GB อยู่แล้วดังนั้นการลากไปรอบ ๆ ที่เก็บทั้งหมดในแต่ละเครื่องดูเหมือนจะเป็นความคิดที่ไม่ดีโดยเฉพาะอย่างยิ่งเมื่อเราถูกเรียกเก็บเงินสำหรับแบนด์วิดท์เครือข่ายที่มากเกินไป

ฉันคิดว่าที่เก็บโครงการเคอร์เนลของลินุกซ์มีขนาดใหญ่พอ ๆ กันดังนั้นจึงต้องมีวิธีจัดการกับ Git ที่เหมาะสม แต่ฉันก็ยังไม่เข้าใจ

มีแนวทางหรือแนวทางปฏิบัติที่ดีที่สุดสำหรับการทำงานกับที่เก็บหลายโปรเจ็กต์ขนาดใหญ่มากหรือไม่

แนวทางนั้นง่ายมากเกี่ยวกับขีด จำกัด Git :

• หนึ่ง repo ต่อโครงการ
• โครงการหลักที่มีsubmodules

แนวคิดไม่ได้อยู่ที่การจัดเก็บทุกอย่างไว้ใน git repo ขนาดใหญ่ แต่สร้าง repo ขนาดเล็กเป็นโครงการหลักซึ่งจะอ้างอิงการกระทำที่ถูกต้องของ repos อื่น ๆ แต่ละรายการเป็นตัวแทนของโครงการหรือส่วนประกอบทั่วไปของตัวเอง

OP พอลอเล็กซานเด ความคิดเห็น :

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

@ พอล: ใช่แทนที่จะอัปเดตเวอร์ชันจากโปรเจ็กต์หลักคุณจะ:

• พัฒนาโครงการย่อยของคุณโดยตรงจากภายในโครงการหลัก (ตามที่อธิบายไว้ใน " ลักษณะที่แท้จริงของโมดูลย่อย ")
• หรือคุณอ้างอิงใน repo ย่อยและoriginไปยังrepo ย่อยเดียวกันที่กำลังพัฒนาที่อื่น: จากตรงนั้นคุณต้องดึงจาก repo ย่อยนั้นจากการเปลี่ยนแปลงที่ทำที่อื่น

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

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

ฉันตอบ:

สุจริตคุณอาจได้รับสิทธิ ... นั่นคือจนกระทั่งล่าสุดGit ปล่อย 1.7.1
git diffและgit statusทั้งคู่เรียนรู้ที่จะคำนึงถึงสถานะของโมดูลย่อยแม้ว่าจะดำเนินการจากโครงการหลักก็ตาม
คุณไม่ควรพลาดการปรับเปลี่ยนโมดูลย่อย

ที่ถูกกล่าวว่า:

• โมดูลย่อยแตกต่างจาก SVN ภายนอก: โปรดดู " เหตุใดโมดูลย่อยของ git จึงไม่สามารถใช้ร่วมกับ svn externals ได้ "
• การจัดการโมดูลย่อยอาจเป็นเรื่องยุ่งยากโปรดดูที่ " โมดูลย่อย git ทำงานอย่างไร "

GitSlave ช่วยให้คุณจัดการ repos อิสระหลาย ๆ ที่เป็นหนึ่งเดียว แต่ละ repo สามารถจัดการได้โดยคำสั่ง git ทั่วไปในขณะที่ gitslave ช่วยให้คุณสามารถรันคำสั่งเพิ่มเติมบน repos ทั้งหมดได้

super-repo
+- module-a-repo
+- module-b-repo

gits clone url-super-repo
gits commit -a -m "msg"

Repo-per-project มีข้อได้เปรียบในการประกอบและสร้างแบบง่ายด้วยเครื่องมือเช่น Maven Repo-per-project จะเพิ่มการป้องกันโดย จำกัด ขอบเขตของสิ่งที่นักพัฒนากำลังเปลี่ยนแปลง - ในแง่ของการทิ้งขยะที่ผิดพลาด