ภาพควรถูกเก็บไว้ในที่เก็บคอมไพล์หรือไม่?

สำหรับทีมกระจายที่ใช้ Git และ Github เป็นตัวควบคุมเวอร์ชันรูปภาพควรถูกเก็บไว้ในที่เก็บ git หรือไม่?

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

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

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

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

ฉันเคยเห็นงานศิลปะดั้งเดิมของโครงการทั้งหมดว่า "poof" เมื่อฮาร์ดไดรฟ์ MacBook ของผู้ออกแบบกราฟิกเสียชีวิตเพราะทุกคนมีภูมิปัญญาที่ไม่มีที่สิ้นสุดตัดสินใจว่า "ไบนารีไม่ได้อยู่ในการควบคุมรอบ" และนักออกแบบกราฟิก (อย่างน้อยหนึ่งนี้) ) มีแนวโน้มที่จะไม่ดีกับการสำรองข้อมูล

เช่นเดียวกับไฟล์ไบนารีใด ๆ และทั้งหมดที่ตรงกับเกณฑ์ด้านบน

เหตุผลเดียวที่ไม่ควรใช้คือพื้นที่ดิสก์ ฉันกลัวที่ $ 100 / เทราไบต์ข้อแก้ตัวนั้นค่อนข้างผอม

ทำไมนรกถึงไม่ได้? :)

การจัดเรียงไบนารีถือว่าเป็นการปฏิบัติที่ไม่ดีใช่ แต่ฉันไม่เคยกังวลเกี่ยวกับรูปภาพมากนัก

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

ในความคิดของฉันคุณไม่ควรกังวลเกี่ยวกับมัน - อนุญาตให้คุณไม่เก็บ GB เหล่านั้น

สิ่งที่คุณสามารถทำได้คือเก็บเฉพาะภาพ "แหล่งที่มา": SVGs, มาโคร LaTeX, ฯลฯ ... และมีภาพสุดท้ายที่สร้างโดยระบบสร้างของคุณ นั่นอาจจะดีกว่าถ้าคุณสามารถ ถ้าไม่เช่นนั้นก็อย่าไปรบกวน

(ทั้งหมดที่กล่าวไปนั้น Git ฉายแสงสำหรับไฟล์ข้อความ แต่ไม่ใช่ VCS ที่ดีที่สุดสำหรับรูปภาพโปรดให้บริบทและตัวชี้วัดแก่เรามากขึ้นถ้าคุณทำได้)

สำหรับข้อมูลเพิ่มเติมคุณอาจต้องการดูคำถาม & คำตอบเหล่านี้:

• การจัดเก็บไฟล์ภาพใน SubVersion / Git
• Git vs SVN พร้อมไฟล์ที่ไม่ใช่ข้อความ
• การจัดการไฟล์ไบนารีขนาดใหญ่ด้วย Git และ Git-submodule

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

สำหรับการจัดเก็บไฟล์ขนาดใหญ่ใน Git มีโครงการดังต่อไปนี้:

• git-annex - สิ่งนี้ได้รับมานานแล้ว แต่ก็มีความซับซ้อนตรงไปตรงมา
• git-media - ไม่มีประสบการณ์ส่วนตัวกับอันนี้ ดูเหมือนจะค่อนข้างซับซ้อนเช่นกัน
• git-fit - ความพยายามในการสร้างปลั๊กอินที่ง่ายกว่า ต้องใช้ที่เก็บข้อมูล S3 ในขณะที่ฉันชื่นชมความเรียบง่ายหลัก ๆ ของฉันเกี่ยวกับปลั๊กอินคือมันไม่เป็นที่รู้จักและเก็บรักษาไว้โดยบุคคลที่ 1 (การเปิดเผยอย่างเต็มรูปแบบฉันเป็นคนเดียวที่ได้รับมอบหมายในเวลานี้
• git-lfs - ในขณะที่ฉันไม่ได้ใช้สิ่งนี้อย่างกว้างขวาง แต่ดูเหมือนว่าจะเป็นจอกศักดิ์สิทธิ์ ได้รับการสนับสนุนจาก Github และพร้อมให้บริการบน repos ทั้งหมดของพวกเขาในเดือนตุลาคม 2558และทำให้ความซับซ้อนของการจัดการไฟล์บนไซต์ที่จัดเก็บ repos ของคุณ เพียง แต่ข้อเสียคือว่าเรื่องนี้ค่อนข้างใหม่เพื่อให้เกิน Github ไม่มีการสนับสนุนมากแม้ว่าGitlab ยังมีการสนับสนุน , เช่นเดียวกับ GiteaและBitbucket ได้พูดพาดพิงถึงการสนับสนุนในอนาคต

TLDR: หากทำได้ให้ใช้git-lfsเพื่อเก็บภาพหรือไฟล์ไบนารีอื่น ๆ ในคอมไพล์

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

ฉันเชื่อว่าวิธีที่แนะนำกับ Git คือการใช้โมดูลย่อย (แนะนำใน Git 1.5.3) ซึ่งโดยพื้นฐานแล้วเป็นพื้นที่เก็บข้อมูลแยกต่างหากที่เชื่อมโยงกับโมดูลหลัก คุณเก็บรูปภาพของคุณ (และสินทรัพย์ไบนารีอื่น ๆ ) ในโมดูลย่อย ซึ่งสามารถถูกเช็กเอาต์ด้วยที่เก็บหลักหรือทางซ้ายขึ้นอยู่กับสิ่งที่ต้องการ

จากhttp://book.git-scm.com/5_submodules.html

"การสนับสนุน submodule ของ Git ช่วยให้ที่เก็บประกอบด้วยไดเรกทอรีย่อยการเช็คเอาต์ของโครงการภายนอก Submodules รักษาเอกลักษณ์ของตนเองการสนับสนุน submodule เพียงแค่เก็บตำแหน่งที่เก็บ submodule และยอมรับ ID ดังนั้นนักพัฒนาคนอื่นที่โคลนโครงการที่มี (" superproject ") สามารถโคลน submodules ทั้งหมดได้อย่างง่ายดายในการแก้ไขเดียวกันการ checkouts บางส่วนของ superproject นั้นมีความเป็นไปได้: คุณสามารถบอก Git ให้ไม่มีการโคลนบางส่วนหรือทั้งหมดของ submodules"

ขนาดไม่ควรเป็นปัญหาสำคัญหากภาพไม่เปลี่ยนบ่อย คุณยังสามารถเรียกใช้คำสั่งเพื่อตัด / ลดขนาดเช่น:

git gc
git gc-aggressive
git prune

ใช่แล้ว

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

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

ถ้ามันเป็นส่วนหนึ่งของโครงการก็จะต้องมีใน VCS วิธีการบรรลุเป้าหมายที่ดีที่สุดนี้อาจขึ้นอยู่กับ VCS หรือวิธีที่คุณจัดระเบียบโครงการ อาจเป็น repo สำหรับนักออกแบบและมีเพียงผลลัพธ์ใน repo ของ coder หรือเฉพาะ 'แหล่งรูปภาพ' (ฉันเคยมีโครงการที่มีไฟล์. svg เท่านั้นและภาพที่สร้างขึ้นโดย make / inscape cli)

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

จนถึงตอนนี้ฉันไม่มีปัญหากับการใส่กราฟิก 'ปกติ' จำนวนมาก (จำลอง, แนวคิดและกราฟิกหน้า) สำหรับโครงการเว็บในคอมไพล์

คุณควรเก็บภาพไว้ใน SCM: ใช่ ไม่ต้องสงสัยเลย

คุณควรเก็บภาพของคุณไว้ในคอมไพล์ไหม

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

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

คำตอบอื่น ๆ คือการวางพวกเขาในโครงการที่แตกต่างไม่เคยสาขาและให้แน่ใจว่าทุกคนที่มุ่งมั่นที่จะผลักโครงการต้นน้ำทันที - ไม่ให้ 2 คนเปลี่ยนไฟล์รุ่นเดียวกัน - คุณจะพบว่ามันยากที่สุด ด้านเนื่องจาก git ไม่ได้รับการออกแบบสำหรับเวิร์กโฟลว์ที่ไม่ได้รับการแจกจ่าย คุณจะต้องใช้วิธีการสื่อสารที่ล้าสมัยเพื่อปฏิบัติตามกฎนี้

คำตอบที่สามคือทำให้พวกเขาอยู่ใน SCM ที่แตกต่างกันโดยสิ้นเชิงซึ่งเหมาะสำหรับการทำงานกับภาพ

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

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

ฉันเห็นด้วยอย่างแน่นอนว่าการจัดเก็บพวกเขาทั้งในเชิงเทคนิคและเชิงเศรษฐศาสตร์เป็นไปได้ คำถามที่ฉันต้องการคือ "ภาพเหล่านี้เป็นส่วนหนึ่งของผลิตภัณฑ์การจัดส่งหรือเนื้อหาส่วนหนึ่งของผลิตภัณฑ์การจัดส่งหรือไม่" ไม่ใช่ว่าคุณไม่สามารถจัดเก็บเนื้อหาใน GIT (หรือ VCS อื่น ๆ ) แต่เป็นปัญหาแยกต่างหากสำหรับ VCS แยกต่างหาก