ควรจัดเก็บ CSS แบบย่อใน Git หรือไม่

ฉันใช้ Gulp เพื่อสร้าง CSS แบบย่อจากรหัส SASS ของฉันสำหรับโครงการที่ฉันกำลังทำอยู่

ฉันสงสัยว่าเป็นวิธีปฏิบัติที่ดีที่สุดในการสร้าง CSS minified ใหม่นี้เมื่อทำการถ่ายทอดสดจาก Git ...

หรือ

ในการจัดเก็บไฟล์ CSS ขนาดเล็กใน Git พวกเขาจะถูกส่งไปยังการผลิตสดโดยอัตโนมัติโดยไม่ต้องทำงานเพิ่มเติมในส่วนของเซิร์ฟเวอร์?

ฉันขอขอบคุณความคิดของผู้คนในเรื่องนี้ ขอบคุณ!

"มันขึ้นอยู่กับ." สำหรับการติดตามการพัฒนาปกติไม่มี สำหรับการปรับใช้คลาวด์และ DevOps มักจะสะดวกหรือจำเป็น

ส่วนใหญ่เวลาที่ @ptyx ถูกต้อง อันที่จริง "ไม่" ของเขาอาจกล่าวได้ค่อนข้างเด่นชัด บางอย่างเช่น "ไม่ไม่! OMG ไม่! "

ทำไมไม่จัดเก็บเนื้อหาที่ย่อขนาดหรือบีบอัดไว้ในระบบควบคุมแหล่งข้อมูลเช่น Git

1. พวกมันสามารถสร้างขึ้นมาใหม่ได้เกือบเล็กน้อยโดยกระบวนการสร้างของคุณได้ทันทีจากซอร์สโค้ด การจัดเก็บเนื้อหาที่ถูกบีบอัดนั้นเป็นการจัดเก็บเนื้อหาโลจิคัลเดียวกันสองครั้ง มันละเมิดหลักการ "อย่าทำซ้ำตัวเอง" (aka DRY )

2. เหตุผลเชิงปรัชญาที่น้อยกว่า แต่มีประโยชน์มากกว่านั้นคือสินทรัพย์ที่มีขนาดเล็ก / ปรับให้เหมาะสมนั้นมีความสามารถในการบีบอัดที่ต่ำมากเมื่อเก็บไว้ใน Git ระบบควบคุมแหล่งที่มาทำงานได้โดยตระหนักถึงการเปลี่ยนแปลง ("deltas") ระหว่างรุ่นต่าง ๆ ของแต่ละไฟล์ที่จัดเก็บ ในการทำเช่นนั้นพวกเขา "diff" ไฟล์ล่าสุดกับเวอร์ชันก่อนหน้าและใช้ delta เหล่านี้เพื่อหลีกเลี่ยงการเก็บสำเนาที่สมบูรณ์ของไฟล์ทุกเวอร์ชัน แต่การเปลี่ยนแปลงที่เกิดขึ้นในขั้นตอนลดขนาด / ปรับให้เหมาะสมมักจะลบความเหมือนและจุดที่อัลกอริทึม diff / deltaใช้ ตัวอย่างที่น่าสนใจที่สุดคือการลบตัวแบ่งบรรทัดและช่องว่างอื่น ๆ สินทรัพย์ที่เกิดขึ้นมักจะเป็นเพียงหนึ่งบรรทัดยาว หลาย ๆ ส่วนของกระบวนการสร้างเว็บ - เครื่องมือเช่นBabel , UglifyJS , Browserify ,น้อยกว่าและSass / SCSS -แปลงสินทรัพย์อย่างจริงจัง เอาท์พุทของพวกเขาจะตกอกตกใจ; การเปลี่ยนแปลงอินพุตขนาดเล็กอาจนำไปสู่การเปลี่ยนแปลงครั้งสำคัญ ดังนั้นอัลกอริทึม diff มักจะเชื่อว่ามันเห็นไฟล์ที่แตกต่างกันเกือบทุกครั้ง ที่เก็บของคุณจะเพิ่มขึ้นอย่างรวดเร็ว ดิสก์ของคุณอาจมีขนาดใหญ่พอและเครือข่ายของคุณเร็วพอที่ไม่ต้องกังวลมากนักโดยเฉพาะอย่างยิ่งหากมีค่าในการจัดเก็บสินทรัพย์ที่มีขนาดเล็ก / ใหญ่เป็นสองเท่า - แม้ว่าจะขึ้นอยู่กับจุดที่ 1 สำเนาเพิ่มเติมอาจไร้จุดหมาย บวม

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

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

เลขที่

การควบคุมแหล่งที่มาควรมีแหล่งที่มาเท่านั้น ถ้ามันถูกสร้างขึ้นจากแหล่งที่มามันไม่ได้อยู่ในนั้น - และควรถูกสร้างขึ้นโดยกระบวนการสร้างของคุณ

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