Haruskah CSS yang diperkecil disimpan di Git?

Saya menggunakan Gulp untuk menghasilkan CSS yang diperkecil dari kode SASS saya untuk proyek yang sedang saya kerjakan.

Saya bertanya-tanya apakah ini dianggap praktik terbaik untuk membuat ulang CSS yang diperkecil ini ketika mendorong langsung dari Git ...

atau

Untuk menyimpan file CSS yang diperkecil di Git sehingga mereka secara otomatis didorong langsung ke produksi tanpa bekerja lebih lanjut pada bagian server?

Saya menghargai ide orang tentang ini. Terima kasih!

— Connor Gurney
sumber

Hanya ada satu tempat css / js / etc yang diperkecil. harus disimpan: /dev/null.

— R .. GitHub BERHENTI MEMBANTU ICE

(Itu karena server web Anda benar-benar mampu menggunakan transportasi gzip.)

— R .. GitHub BERHENTI MEMBANTU ICE

Menyimpan CSS terkompresi dan tidak terkompresi berarti Anda sekarang memiliki dua versi untuk hal yang sama. Manakah versi kanoniknya? Sangat mudah untuk membayangkan skenario di mana satu dev memperbarui CSS yang dikompresi dan yang lain memperbarui CSS yang tidak terkompresi. Dua aset Anda sekarang telah menyimpang. Tentu saja proses harus mencegah hal ini tetapi prospek yang realistis dengan misalnya pengembang baru dalam tim.

— Qwerky

Jawaban:

"Tergantung." Untuk pelacakan pengembangan normal, tidak. Namun, untuk penggunaan cloud dan DevOps, sering kali nyaman, atau bahkan diperlukan.

Sebagian besar waktu, @ ptyx benar . Memang, "tidak" nya bisa dinyatakan agak lebih tegas. Sesuatu seperti "Tidak. Tidak! OMG TIDAK! "

Mengapa tidak menyimpan aset yang diperkecil atau dikompresi dalam sistem kontrol sumber seperti Git?

Mereka hampir bisa dibuat ulang secara sepele oleh proses build Anda dengan cepat dari kode sumber. Menyimpan aset terkompresi pada dasarnya menyimpan konten logis yang sama dua kali. Itu melanggar prinsip "jangan ulangi dirimu sendiri" (alias KERING ).
Alasan yang kurang filosofis tetapi lebih praktis adalah bahwa aset yang diperkecil / dioptimalkan memiliki kompresibilitas yang sangat buruk ketika disimpan di Git. Sistem kontrol sumber bekerja dengan mengenali perubahan ("delta") antara versi yang berbeda dari setiap file yang disimpan. Untuk melakukan itu, mereka "membedakan" file terbaru dengan versi sebelumnya, dan dan menggunakan delta-delta ini untuk menghindari penyimpanan salinan lengkap dari setiap versi file. Tetapi transformasi yang dilakukan pada langkah minify / optimalkan sering menghilangkan kesamaan dan titik arah yang digunakan algoritma diff / delta . Contoh paling sepele adalah menghapus jeda baris dan spasi putih lainnya; aset yang dihasilkan seringkali hanya satu garis panjang. Banyak bagian dari proses pembuatan Web - alat seperti Babel , UglifyJS , Browserify ,Kurang , dan Sass / SCSS - secara agresif mengubah aset. Keluaran mereka gelisah; perubahan input kecil dapat menyebabkan perubahan besar dalam output. Alhasil, algoritma-diff akan sering percaya itu melihat hampir semua file yang berbeda setiap kali. Akibatnya, repositori Anda akan tumbuh lebih cepat. Disk Anda mungkin cukup besar dan jaringan Anda cukup cepat yang tidak menjadi masalah besar, terutama jika ada nilai untuk menyimpan aset yang diperkecil / dioptimalkan dua kali - meskipun berdasarkan poin 1, salinan tambahan mungkin hanya 100% tidak berguna mengasapi.

Namun, ada pengecualian untuk hal ini: DevOps / cloud deployments. Sejumlah vendor cloud dan tim DevOps menggunakan Git dan sejenisnya tidak hanya untuk melacak pembaruan pengembangan, tetapi juga untuk secara aktif menyebarkan aplikasi dan aset mereka untuk menguji dan memproduksi server. Dalam peran ini, kemampuan Git untuk secara efisien menentukan "file apa yang berubah?" sama pentingnya dengan kemampuannya yang lebih terperinci untuk menentukan "apa yang berubah dalam setiap file?" Jika Git harus melakukan salinan file yang hampir penuh untuk aset yang diperkecil / dioptimalkan, itu membutuhkan waktu sedikit lebih lama daripada yang seharusnya, tetapi bukan masalah besar karena masih melakukan pekerjaan yang sangat baik membantu menghindari salinan "setiap file dalam proyek" pada masing-masing menyebarkan siklus.

Jika Anda menggunakan Git sebagai mesin penyebaran, menyimpan aset yang diperkecil / dioptimalkan di Git dapat beralih dari "tidak!" untuk diinginkan. Memang, mungkin diperlukan, katakanlah jika Anda tidak memiliki peluang membangun / pasca-pemrosesan yang kuat pada server / layanan yang Anda gunakan. (Bagaimana mengelompokkan pengembangan dan penyebaran aset dalam kasus itu adalah kaleng cacing yang terpisah. Untuk saat ini, cukup untuk mengetahui bahwa dapat dikelola beberapa cara, termasuk dengan satu repositori terpadu, beberapa cabang, subrepositori, atau bahkan beberapa repositori yang tumpang tindih. )

— Jonathan Eunice
sumber

Terima kasih untuk ini! Sangat dihargai. Saya telah menandai ini sebagai jawaban sebagai gantinya karena tampaknya jauh lebih baik dijelaskan.

— Connor Gurney

git tidak hanya menyimpan delta. SVN melakukannya, tetapi git menggunakan mekanisme yang jauh lebih kompleks untuk menyimpan file. Beberapa orang mengatakan Anda menyimpan salinan lengkap dari setiap file, tetapi dari apa yang saya pahami, ini juga tidak benar. Saya tidak akan mencoba masuk ke dalam apa yang dilakukannya, karena saya sendiri tidak sepenuhnya jelas tentang hal itu.

— jpmc26

Saya pikir Anda dapat mencapai nuansa hanya dengan mengubah, "dan hanya menyimpan delta baru" ke sesuatu di sepanjang baris, "dan menggunakan delta ini untuk menghindari menyimpan salinan lengkap dari setiap versi file." Itu akan membuat poin Anda, menjadi faktual benar, dan menghindari menggali masalah tentang bagaimana hal itu dilakukan untuk sistem kontrol sumber yang diberikan.

— jpmc26

Bisakah DevOps hanya menggunakan kait git untuk secara otomatis memicu minifikasi pada server yang digunakan, mendapatkan yang terbaik dari kedua dunia?

— Buttle Butkus

@ButtleButkus Tergantung pada pada server yang digunakan. Untuk bergantung pada kait pos, Anda harus 1 / mengasumsikan transparansi, minifiers, dan pengoptimal yang tepat ada pada target, atau 2 / memuatnya sebelum menjalankan kait pos. 1 / tidak pasti. 2 / membebankan biaya / latensi beban pada setiap penyebaran. Ini juga memperkenalkan kemungkinan mode kegagalan baru dan persyaratan untuk men-debug kait pos di lingkungan yang jauh, buram, dan sementara. Tidak ideal Jadi kait bukan peluru perak. Aset pra-konversi / optimalisasi mungkin tidak sempurna, tetapi kuat dan pragmatis.

— Jonathan Eunice

Tidak.

Kontrol sumber hanya boleh mengandung sumber. Jika itu dihasilkan dari sumber, itu bukan milik di sana - dan harus dihasilkan oleh proses build Anda.

Alasan mendasar Anda tidak ingin sumber kontrol artefak membangun menengah adalah bahwa jika Anda melakukannya, akan sangat sulit untuk percaya apakah apa yang Anda jalankan berasal dari sumber yang baru saja Anda modifikasi, atau dari produk perantara yang Anda gagal untuk membangun kembali .

— ptyx
sumber

Pikirkan kode yang dihasilkan dengan cara Anda memikirkan kode yang dapat dieksekusi.

— candied_orange

Prinsip ini tidak selalu benar. Jika Anda memiliki file yang dibuat dengan alat kelas berat yang tidak bisa Anda harapkan dimiliki pengguna, mungkin masuk akal untuk meletakkan file yang dihasilkan di git. Banyak orang bahkan memasukkan configureskrip autoconf yang dihasilkan di git untuk alasan ini.

— R .. GitHub BERHENTI MEMBANTU ICE

@R ..: Idealnya, Anda mempertahankan repositori artefak terpisah untuk hal-hal itu, tetapi kenyataannya jarang ideal.

— Kevin

@R Anda bisa berkompromi - tapi hanya itu. Dan dalam hal minifikasi CSS, saya tidak berpikir alat tersebut memenuhi syarat sebagai 'kelas berat' atau 'lambat' atau 'tidak nyaman'. Juga, ada mekanisme injeksi ketergantungan alternatif (maven, ivy ...) yang berfungsi dengan baik dan tidak mengharuskan Anda untuk meletakkan kode yang dihasilkan dalam kontrol sumber Anda.

— ptyx

@ButtleButkus Saya tidak memiliki banyak keahlian dalam kasus devops. Apa yang saya lihat adalah git digunakan sebagai mekanisme transportasi / rilis / penyebaran (sangat nyaman dan fleksibel), bukan murni sebagai kontrol sumber. Kecuali jika git 'sumber' dan git 'pengiriman' terpisah (repo atau cabang terpisah terpisah), ini berarti Anda harus sedikit mengompromikan rantai yang dapat dikirimkan sumber-> build-> sedikit - mis. Anda akan berakhir dengan produksi yang memiliki kode sumber dan cabang tambahan tergeletak di sekitar, dan pengembangan dengan produk biner yang tidak digunakan. Ini kompromi pragmatis, tetapi saya lebih suka memisahkan masalah ketika saya bisa.

— ptyx