การจัดการไฟล์ไบนารีขนาดใหญ่ด้วย Git

ฉันกำลังมองหาความคิดเห็นเกี่ยวกับวิธีจัดการกับไฟล์ไบนารีขนาดใหญ่ซึ่งซอร์สโค้ดของฉัน (เว็บแอพพลิเคชัน) ขึ้นอยู่กับ ขณะนี้เรากำลังพูดถึงทางเลือกหลายทาง:

1. คัดลอกไฟล์ไบนารีด้วยมือ
   • Pro: ไม่แน่ใจ
   • Contra: ฉันต่อต้านสิ่งนี้อย่างมากเนื่องจากจะเพิ่มโอกาสเกิดข้อผิดพลาดเมื่อตั้งค่าไซต์ใหม่ / ย้ายข้อมูลเก่า สร้างอุปสรรค์อื่นที่จะใช้
2. จัดการกับพวกเขาทั้งหมดที่มีGit
   • Pro: ลบความเป็นไปได้ที่จะ 'ลืม' เพื่อคัดลอกไฟล์สำคัญ
   • Contra: ขยายพื้นที่เก็บข้อมูลและลดความยืดหยุ่นในการจัดการรหัสฐานและชำระเงินโคลน ฯลฯ จะใช้เวลาสักครู่
3. แยกที่เก็บ
   • Pro: การตรวจสอบ / การโคลนรหัสที่มานั้นรวดเร็วและภาพนั้นถูกเก็บถาวรอย่างถูกต้องในพื้นที่เก็บข้อมูลของตัวเอง
   • Contra: ลบความเรียบง่ายของการมีที่เก็บ Git หนึ่งเดียวในโครงการ มันแนะนำสิ่งอื่น ๆ ที่ฉันไม่ได้คิด

คุณมีประสบการณ์ / ความคิดเกี่ยวกับเรื่องนี้อย่างไร

นอกจากนี้: ไม่มีใครมีประสบการณ์กับที่เก็บ Git หลายแห่งและจัดการกับพวกเขาในโครงการเดียวหรือไม่?

ไฟล์เป็นรูปภาพสำหรับโปรแกรมที่สร้าง PDF พร้อมไฟล์เหล่านั้น ไฟล์จะไม่เปลี่ยนแปลงบ่อยนัก (เหมือนในปีที่ผ่านมา) แต่ไฟล์เหล่านี้เกี่ยวข้องกับโปรแกรมมาก โปรแกรมจะไม่ทำงานหากไม่มีไฟล์

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

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

นี่คือการแนะนำที่ดีสำหรับ submodulesจาก Git Book

ฉันค้นพบgit-annexเมื่อเร็ว ๆ นี้ซึ่งฉันพบว่ายอดเยี่ยม มันถูกออกแบบมาสำหรับการจัดการไฟล์ขนาดใหญ่ได้อย่างมีประสิทธิภาพ ฉันใช้สำหรับคอลเลกชันภาพถ่าย / เพลง (ฯลฯ ) การพัฒนาของ git-annex นั้นใช้งานได้ดีมาก เนื้อหาของไฟล์สามารถลบออกได้จากที่เก็บ Git เฉพาะลำดับชั้นต้นไม้เท่านั้นที่ถูกติดตามโดย Git (ผ่าน symlink) อย่างไรก็ตามเพื่อให้ได้เนื้อหาของไฟล์จำเป็นต้องมีขั้นตอนที่สองหลังจากดึง / ดันเช่น:

$ git annex add mybigfile
$ git commit -m'add mybigfile'
$ git push myremote
$ git annex copy --to myremote mybigfile ## This command copies the actual content to myremote
$ git annex drop mybigfile ## Remove content from local repo
...
$ git annex get mybigfile ## Retrieve the content
## or to specify the remote from which to get:
$ git annex copy --from myremote mybigfile

มีคำสั่งมากมายและมีเอกสารที่ยอดเยี่ยมบนเว็บไซต์ แพคเกจที่มีอยู่ในDebian

อีกวิธีหนึ่งนับตั้งแต่เดือนเมษายน 2558 คือGit Large File Storage (LFS) (โดย GitHub)

มันใช้git-lfs (ดูgit-lfs.github.com ) และทดสอบกับเซิร์ฟเวอร์ที่รองรับ: lfs-test-server :
คุณสามารถเก็บข้อมูลเมตาได้เฉพาะใน git repo และไฟล์ขนาดใหญ่อื่น ๆ

ลองดูgit bupซึ่งเป็นส่วนขยาย Git เพื่อเก็บไบนารีขนาดใหญ่อย่างชาญฉลาดในที่เก็บ Git

คุณต้องการที่จะให้มันเป็น submodule แต่คุณไม่ต้องกังวลเกี่ยวกับที่เก็บยากที่จะจัดการ กรณีการใช้งานตัวอย่างอย่างใดอย่างหนึ่งคือการเก็บอิมเมจ VM ใน Git

ฉันไม่ได้เห็นอัตราการบีบอัดที่ดีขึ้น แต่ที่เก็บของฉันไม่มีไบนารีขนาดใหญ่จริงๆ

ไมล์สะสมของคุณอาจแตกต่างกันไป

คุณสามารถใช้git-fatได้เช่นกัน ฉันชอบที่มันมี rsyncแต่จะขึ้นอยู่กับหุ้นและงูหลาม นอกจากนี้ยังรองรับเวิร์กโฟลว์ Git ปกติด้วยคำสั่งอธิบายตนเองดังต่อไปนี้:

git fat init
git fat push
git fat pull

นอกจากนี้คุณต้องตรวจสอบไฟล์. gitfat ในพื้นที่เก็บข้อมูลของคุณและแก้ไข. gitattributes ของคุณเพื่อระบุนามสกุลไฟล์ที่คุณต้องการ git fatจัดการ

คุณเพิ่มไบนารีโดยใช้ปกติgit addซึ่งจะเรียกใช้git fatตามกฎ gitattributes ของคุณ

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

อัปเดต: อย่าใช้ git-fat หากคุณใช้สะพาน Git-SVN มันจะจบลงด้วยการลบไฟล์ไบนารีออกจากที่เก็บ Subversion ของคุณ อย่างไรก็ตามหากคุณใช้ที่เก็บ Git ล้วนๆมันทำงานได้อย่างสวยงาม

ฉันจะใช้ submodules (เป็น Pat Notz) หรือสอง repositories ที่แตกต่างกัน หากคุณแก้ไขไฟล์ไบนารีบ่อยเกินไปฉันจะพยายามลดผลกระทบของที่เก็บขนาดใหญ่ที่ล้างประวัติ:

ฉันมีปัญหาที่คล้ายกันมากเมื่อหลายเดือนที่ผ่านมา: ไฟล์ MP3 21 GB, ไม่ได้รับการจำแนกประเภท (ชื่อไม่ดี, id3 ที่ไม่ดีไม่ทราบว่าฉันชอบไฟล์ MP3 นั้นหรือไม่ ... ) และทำซ้ำในคอมพิวเตอร์สามเครื่อง

ฉันใช้ฮาร์ดดิสก์ไดรฟ์ภายนอกกับแหล่งเก็บข้อมูลหลักของ Git และฉันโคลนมันลงในคอมพิวเตอร์แต่ละเครื่อง จากนั้นฉันก็เริ่มแบ่งพวกมันออกเป็นนิสัย (ผลัก, ดึง, รวมเข้าด้วยกัน ... ลบและเปลี่ยนชื่อหลาย ๆ ครั้ง)

ในตอนท้ายฉันมีไฟล์ MP3 เพียง ~ 6 GB และ ~ 83 GB ในไดเรกทอรี. git ฉันใช้git-write-treeและgit-commit-treeสร้างคอมมิชชันใหม่โดยไม่ต้องคอมมิชชันบรรพบุรุษและเริ่มสาขาใหม่ที่ชี้ไปที่การคอมมิชชันนั้น "บันทึกคอมไพล์" สำหรับสาขานั้นแสดงการคอมมิชชันเดียวเท่านั้น

จากนั้นฉันลบสาขาเก่าเก็บเฉพาะสาขาใหม่ลบบันทึกอ้างอิงและเรียกใช้ "git prune": หลังจากนั้นโฟลเดอร์. git ของฉันมีน้ำหนักเพียง ~ 6 GB ...

คุณสามารถ "ล้าง" พื้นที่เก็บข้อมูลขนาดใหญ่เป็นครั้งคราวในลักษณะเดียวกัน: "git clone" ของคุณจะเร็วขึ้น

โซลูชันที่ฉันต้องการนำเสนอขึ้นอยู่กับสาขาของเด็กกำพร้าและการใช้กลไกแท็กในทางที่ผิดซึ่งต่อไปนี้จะเรียกว่า * Orphan Tags Binary Storage (OTABS)

TL; DR 12-01-2017หากคุณสามารถใช้ LFS ของ GitHub หรือบุคคลที่สามอื่น ๆ ได้ทุกอย่างควรจะเป็น ถ้าคุณทำไม่ได้อ่านต่อ ได้รับคำเตือนทางออกนี้เป็นแฮ็คและควรได้รับการปฏิบัติเช่นนี้

คุณสมบัติที่พึงประสงค์ของ OTABS

• มันเป็นคอมไพล์และคอมไพล์เท่านั้นการแก้ปัญหา - มันได้รับงานทำโดยไม่ใช้ซอฟต์แวร์ของบุคคลที่ 3 (ชอบ Git-ภาคผนวก) หรือโครงสร้างพื้นฐานของบุคคลที่ 3 (ชอบ GitHub ของ LFS)
• มันจัดเก็บไฟล์ไบนารีอย่างมีประสิทธิภาพนั่นคือมันจะไม่ขยายประวัติของที่เก็บของคุณ
• git pullและgit fetchรวมถึงgit fetch --allยังคงมีแบนด์วิดท์ที่มีประสิทธิภาพนั่นคือไม่ได้ดึงไบนารีขนาดใหญ่ทั้งหมดจากระยะไกลโดยค่าเริ่มต้น
• การทำงานบนวินโดวส์
• จะเก็บทุกอย่างในเก็บคอมไพล์เดียว
• จะช่วยให้การลบไบนารีที่ล้าสมัย (ไม่เหมือน bup)

คุณสมบัติที่ไม่พึงประสงค์ของ OTABS

• มันgit cloneอาจทำให้ไม่มีประสิทธิภาพ (แต่ไม่จำเป็นขึ้นอยู่กับการใช้งานของคุณ) หากคุณปรับใช้วิธีนี้คุณอาจจะต้องให้คำแนะนำเพื่อนร่วมงานของคุณเพื่อใช้แทนgit clone -b master --single-branch <url> git cloneนี่เป็นเพราะ git clone โดยค่าเริ่มต้นจะทำการโคลนพื้นที่เก็บข้อมูลทั้งหมดรวมถึงสิ่งที่คุณไม่ต้องการเสียแบนด์วิดท์เหมือนปกติ ที่นำมาจากSO 4811434
• มันทำให้git fetch <remote> --tagsแบนด์วิดธ์ที่ไม่มีประสิทธิภาพ แต่ไม่จำเป็นต้องเก็บข้อมูลไม่มีประสิทธิภาพ คุณสามารถแนะนำเพื่อนร่วมงานของคุณไม่ให้ใช้
• คุณจะต้องใช้git gcเคล็ดลับในการทำความสะอาดพื้นที่เก็บข้อมูลของคุณจากไฟล์ใด ๆ ที่คุณไม่ต้องการอีกต่อไป
• มันไม่ได้เป็นที่มีประสิทธิภาพBUPหรือGit-bigfiles แต่มันก็เหมาะสมกว่าสำหรับสิ่งที่คุณพยายามจะทำและยิ่งเพิ่มมากขึ้น คุณมีแนวโน้มที่จะประสบปัญหากับไฟล์ขนาดเล็กหลายแสนไฟล์หรือไฟล์ในช่วงกิกะไบต์ แต่อ่านเพื่อแก้ไขปัญหา

การเพิ่มไฟล์ไบนารี

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

1. สร้างสาขาใหม่ของเด็กกำพร้า git checkout --orphan binaryStuffจะทำเคล็ดลับ สิ่งนี้จะสร้างสาขาที่ถูกตัดการเชื่อมต่อจากสาขาอื่นอย่างสิ้นเชิงและสิ่งแรกที่คุณจะทำในสาขานี้จะไม่มีพาเรนต์ซึ่งจะทำให้รูทคอมมิท
2. git rm --cached * .gitignoreทำความสะอาดของคุณโดยใช้ดัชนี
3. หายใจลึก ๆ rm -fr * .gitignoreและลบต้นไม้ทำงานทั้งหมดโดยใช้ .gitไดเรกทอรีภายในจะไม่ถูกแตะต้องเพราะ*ไวด์การ์ดไม่ตรงกัน
4. คัดลอกใน VeryBigBinary.exe ของคุณหรือ VeryHeavyDirectory /
5. เพิ่ม & & กระทำมัน
6. ตอนนี้มันกลายเป็นเรื่องยาก - ถ้าคุณผลักมันไปที่รีโมตในฐานะสาขานักพัฒนาซอฟต์แวร์ของคุณจะดาวน์โหลดในครั้งต่อไปที่พวกเขาเรียกใช้git fetchการเชื่อมต่อของพวกเขา คุณสามารถหลีกเลี่ยงสิ่งนี้ได้ด้วยการกดแท็กแทนสาขา สิ่งนี้ยังคงส่งผลกระทบต่อแบนด์วิดท์และพื้นที่จัดเก็บระบบไฟล์ของเพื่อนร่วมงานของคุณหากพวกเขามีนิสัยในการพิมพ์git fetch <remote> --tagsแต่อ่านเพื่อหาวิธีแก้ปัญหา ไปข้างหน้าและgit tag 1.0.0bin
7. git push <remote> 1.0.0binกดแท็กเด็กกำพร้าของคุณ
8. git branch -D binaryStuffเพียงเพื่อให้คุณไม่เคยผลักดันสาขาไบนารีของคุณโดยบังเอิญคุณสามารถลบได้ ความมุ่งมั่นของคุณจะไม่ถูกทำเครื่องหมายสำหรับการรวบรวมขยะเนื่องจากแท็กเด็กกำพร้าที่ชี้ไปที่มัน1.0.0binเพียงพอที่จะทำให้มันมีชีวิตอยู่

ตรวจสอบไฟล์ไบนารี

1. ฉัน (หรือเพื่อนร่วมงาน) จะได้รับเช็ค VeryBigBinary.exe จากแผนผังการทำงานปัจจุบันได้อย่างไร git checkout 1.0.0bin -- VeryBigBinary.exeหากสาขาการทำงานปัจจุบันของคุณเป็นตัวอย่างต้นแบบที่คุณสามารถเพียง
2. สิ่งนี้จะล้มเหลวหากคุณไม่ได้1.0.0binดาวน์โหลดแท็กเด็กกำพร้าซึ่งในกรณีนี้คุณต้องทำgit fetch <remote> 1.0.0binก่อน
3. คุณสามารถเพิ่มสิ่งเหล่านี้VeryBigBinary.exeลงในปรมาจารย์ของ.gitignoreคุณเพื่อให้ไม่มีใครในทีมของคุณที่จะสร้างมลพิษประวัติศาสตร์หลักของโครงการด้วยไบนารีโดยไม่ได้ตั้งใจ

การลบไฟล์ไบนารีโดยสมบูรณ์

หากคุณตัดสินใจที่จะลบ VeryBigBinary.exe จากที่เก็บในเครื่องของคุณอย่างสมบูรณ์ที่เก็บระยะไกลของคุณและที่เก็บของเพื่อนร่วมงานคุณสามารถ:

1. ลบแท็กเด็กกำพร้าบนรีโมท git push <remote> :refs/tags/1.0.0bin
2. ลบแท็กเด็กกำพร้าในประเทศ (ลบแท็ก unreferenced อื่น ๆ git tag -l | xargs git tag -d && git fetch --tagsทั้งหมด) นำมาจากSO 1841341โดยมีการดัดแปลงเล็กน้อย
3. ใช้เคล็ดลับ git gc เพื่อลบการกระทำที่ไม่ได้รับการอ้างอิงในขณะนี้ของคุณ git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@". มันจะลบการกระทำที่ไม่ได้อ้างถึงอื่น ๆ ทั้งหมด นำมาจากSO 1904860
4. หากเป็นไปได้ให้ทำซ้ำเคล็ดลับ git gc บนรีโมท เป็นไปได้ถ้าคุณจัดการพื้นที่เก็บข้อมูลด้วยตนเองและอาจไม่สามารถทำได้กับผู้ให้บริการบางรายเช่น github หรือในสภาพแวดล้อมขององค์กร หากคุณกำลังโฮสต์กับผู้ให้บริการที่ไม่ให้สิทธิ์การเข้าถึงรีโมตแก่คุณ เป็นไปได้ว่าโครงสร้างพื้นฐานของผู้ให้บริการของคุณจะทำความสะอาดความมุ่งมั่นที่ไม่ได้อ้างถึงในช่วงเวลาที่แสนหวาน หากคุณอยู่ในสภาพแวดล้อมขององค์กรคุณสามารถให้คำปรึกษาด้านไอทีของคุณในการเรียกใช้งานขยะ cron รวบรวมระยะไกลของคุณหนึ่งครั้งต่อสัปดาห์หรือมากกว่านั้น ไม่ว่าจะทำหรือไม่จะไม่มีผลกระทบใด ๆ ในทีมของคุณในแง่ของแบนด์วิดธ์และการเก็บรักษานานเท่าที่คุณแนะนำให้เพื่อนร่วมงานของคุณเสมอแทนgit clone -b master --single-branch <url>git clone
5. เพื่อนร่วมงานทุกคนของคุณที่ต้องการกำจัดแท็กเด็กกำพร้าที่ล้าสมัยต้องใช้ขั้นตอนที่ 2-3 เท่านั้น
6. จากนั้นคุณสามารถทำซ้ำขั้นตอนที่ 1-8 ของการเพิ่มไฟล์ไบนารี2.0.0binสร้างแท็กใหม่เด็กกำพร้า หากคุณกำลังกังวลเกี่ยวกับเพื่อนร่วมงานของคุณพิมพ์คุณจริงสามารถตั้งชื่อมันอีกครั้งgit fetch <remote> --tags 1.0.0binสิ่งนี้จะทำให้แน่ใจว่าครั้งต่อไปที่พวกเขาดึงแท็กทั้งหมดที่เก่า1.0.0binจะไม่ได้รับการยืนยันและทำเครื่องหมายสำหรับการรวบรวมขยะในภายหลัง (ใช้ขั้นตอนที่ 3) เมื่อคุณพยายามที่จะเขียนทับแท็กบนรีโมทคุณต้องใช้-fสิ่งนี้:git push -f <remote> <tagname>

เล่ม

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

• ได้รับการยืนยันให้ทำงานบน Windows ด้วย git-bash

• มันเป็นความคิดที่ดีที่จะใช้ ชุดของ trics มาตรฐานเพื่อให้การจัดเก็บไฟล์ไบนารีมีประสิทธิภาพมากขึ้น การใช้งานบ่อยครั้งgit gc(โดยไม่มีข้อโต้แย้งเพิ่มเติม) ทำให้ git เพิ่มประสิทธิภาพการจัดเก็บข้อมูลพื้นฐานของไฟล์ของคุณโดยใช้ไบนารีเดลต้า อย่างไรก็ตามหากไฟล์ของคุณไม่น่าจะคล้ายกันจากการคอมมิทถึงการคอมมิทคุณสามารถปิดเดลตาไบนารีได้ทั้งหมด นอกจากนี้เนื่องจากไม่สามารถบีบอัดไฟล์ที่ถูกบีบอัดหรือเข้ารหัสได้แล้วเช่น. zip, .jpg หรือ. crypt ดังนั้น git จึงช่วยให้คุณสามารถปิดการบีบอัดหน่วยความจำพื้นฐานได้ น่าเสียดายที่การตั้งค่าทั้งหมดหรือไม่มีอะไรส่งผลกระทบต่อซอร์สโค้ดของคุณเช่นกัน

• คุณอาจต้องการสคริปอัพบางส่วนของ OTABS เพื่อให้สามารถใช้งานได้เร็วขึ้น โดยเฉพาะอย่างยิ่งการเขียนสคริปต์ขั้นตอน 2-3 จากลบไฟล์ไบนารีทั้งหมดลงในupdateตะขอคอมไพล์สามารถให้ความหมายที่น่าสนใจ แต่อาจเป็นอันตรายถึงความหมายในการเรียก git ("ดึงและลบทุกอย่างที่ล้าสมัย")

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

• ในโลก Java เป็นไปได้ที่จะรวมโซลูชันนี้เข้าด้วยกัน maven --offlineเพื่อสร้างบิลด์ออฟไลน์ที่ทำซ้ำได้ซึ่งถูกจัดเก็บไว้ในการควบคุมเวอร์ชันของคุณ ใน golang โลกจะเป็นไปได้ที่จะสร้างในการแก้ปัญหานี้เพื่อจัดการ GOPATH go getของคุณแทน ในโลกหลามมันเป็นไปได้ที่จะรวมสิ่งนี้เข้ากับ virtualenv เพื่อสร้างสภาพแวดล้อมการพัฒนาที่มีในตัวเองโดยไม่ต้องพึ่งพาเซิร์ฟเวอร์ PyPi สำหรับทุกการสร้างตั้งแต่เริ่มต้น

• หากไฟล์ไบนารีของคุณเปลี่ยนแปลงบ่อยเช่นการสร้างสิ่งประดิษฐ์ที่มันอาจจะเป็นความคิดที่ดีในการแก้ปัญหาสคริปต์ที่ร้านค้า 5 รุ่นล่าสุดของสิ่งประดิษฐ์ในแท็กเด็กกำพร้าmonday_bin, tuesday_bin, ... , friday_binและยังมีแท็กเด็กกำพร้าสำหรับแต่ละรุ่น1.7.8bin 2.0.0binฯลฯ คุณสามารถหมุนweekday_binและลบไบนารีเก่าได้ทุกวัน วิธีนี้จะทำให้คุณได้รับสองโลกที่ดีที่สุด: คุณเก็บประวัติทั้งหมดของซอร์สโค้ดของคุณ แต่จะมีเพียงประวัติที่เกี่ยวข้องของการพึ่งพาไบนารีของคุณ นอกจากนี้ยังง่ายมากที่จะได้รับไฟล์ไบนารีสำหรับแท็กที่กำหนดโดยไม่ได้รับซอร์สโค้ดทั้งหมดพร้อมประวัติทั้งหมด: git init && git remote add <name> <url> && git fetch <name> <tag>ควรทำเพื่อคุณ

ในความคิดของฉันถ้าคุณมักจะแก้ไขไฟล์ขนาดใหญ่เหล่านั้นหรือถ้าคุณตั้งใจจะทำมากgit cloneหรือgit checkoutอย่างนั้นคุณควรพิจารณาใช้พื้นที่เก็บข้อมูล Git อื่นอย่างจริงจัง (หรืออาจเป็นวิธีอื่นในการเข้าถึงไฟล์เหล่านั้น)

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

SVN ดูเหมือนว่าจะจัดการกับ delta แบบไบนารีอย่างมีประสิทธิภาพมากกว่า Git

ฉันต้องตัดสินใจเกี่ยวกับระบบการกำหนดเวอร์ชันสำหรับเอกสารประกอบ (ไฟล์ JPEG, ไฟล์ PDF และไฟล์. odt) ฉันเพิ่งทดสอบการเพิ่มไฟล์ JPEG และหมุน 90 องศาสี่ครั้ง (เพื่อตรวจสอบประสิทธิภาพของเดลต้าไบนารี) พื้นที่เก็บข้อมูลของ Git เพิ่มขึ้น 400% พื้นที่เก็บข้อมูลของ SVN เพิ่มขึ้นเพียง 11%

ดังนั้นดูเหมือนว่า SVN จะมีประสิทธิภาพมากขึ้นกับไฟล์ไบนารี

ดังนั้นตัวเลือกของฉันคือ Git สำหรับซอร์สโค้ดและ SVN สำหรับไฟล์ไบนารีเช่นเอกสาร

git clone --filter จาก Git 2.19 + โคลนนิ่งตื้น

ตัวเลือกใหม่นี้ในที่สุดอาจจะกลายเป็นทางออกสุดท้ายที่จะเป็นปัญหาแฟ้มไบนารีถ้า Git และ GitHub devs และทำให้ผู้ใช้ที่เป็นมิตรมากพอ (ซึ่งพวกเขาเนื้อหาที่ยังไม่ได้ประสบความสำเร็จสำหรับ submodulesตัวอย่าง)

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

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

แม้จะมีอยู่แล้ว --filter=blob:limit<size>ซึ่งช่วยให้การ จำกัด ขนาดหยดสูงสุดที่จะดึง

ฉันได้ให้ตัวอย่างที่มีรายละเอียดน้อยที่สุดเกี่ยวกับลักษณะที่ปรากฏของ: ฉันจะโคลนไดเรกทอรีย่อยของที่เก็บ Git ได้อย่างไร

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

ผมเองยังวิ่งเข้ามาในความล้มเหลวของการประสานกับ Gitกับบางส่วนของเจ้าภาพเมฆของฉันเมื่อใช้งานเว็บข้อมูลไบนารีของฉันมีรอยบากข้างต้นเครื่องหมาย 3 GB ฉันพิจารณาBFT Repo Cleanerในเวลานั้น แต่มันรู้สึกเหมือนแฮ็ค ตั้งแต่นั้นมาฉันเริ่มเก็บไฟล์ไว้นอกขอบเขตของ Git แทนที่จะใช้ประโยชน์จากเครื่องมือที่สร้างขึ้นเองเช่น Amazon S3 สำหรับจัดการไฟล์การกำหนดเวอร์ชันและการสำรองข้อมูล

ใครบ้างมีประสบการณ์กับที่เก็บ Git หลายแห่งและจัดการมันในโครงการเดียว

ใช่. ธีมของ Hugoได้รับการจัดการด้วยวิธีนี้เป็นหลัก มันเป็นความดุดันเล็กน้อย แต่ก็ทำให้งานเสร็จ

ข้อเสนอแนะของฉันคือการเลือกเครื่องมือที่เหมาะสมสำหรับงาน ถ้าเป็นของ บริษัท และคุณกำลังจัดการ codeline ของคุณใน GitHub จ่ายเงินและใช้ Git-LFS มิฉะนั้นคุณสามารถสำรวจตัวเลือกที่สร้างสรรค์มากขึ้นเช่นการจัดเก็บไฟล์ที่เข้ารหัสแบบกระจายโดยใช้ blockchainblockchain

ตัวเลือกเพิ่มเติมในการพิจารณารวมถึงMinioและs3cmd

มีลักษณะที่camlistore มันไม่ได้ใช้ Git แต่ฉันคิดว่ามันเหมาะสมกว่าสำหรับสิ่งที่คุณต้องทำ