Haruskah gambar disimpan dalam repositori git?


202

Untuk tim terdistribusi yang menggunakan Git dan Github sebagai kontrol versi, haruskah gambar juga disimpan dalam repositori git?

Sebagian besar, gambar tidak akan berubah. Folder yang berisi mereka hanya akan bertambah besar seiring gambar ditambahkan. Kekhawatiran adalah bahwa folder gambar dapat tumbuh ke ukuran besar dari waktu ke waktu oleh kombinasi gambar besar, atau hanya banyak dari mereka.

Apakah ini dianggap praktik terbaik? Apa alternatif lain yang ada untuk berbagi file biner yang diperlukan dalam proyek-proyek yang dengan mudah diakses oleh tim terdistribusi?


17
Ketika Anda mengatakan "gambar" apakah kita berbicara tentang file mentah Raw 26mb, tekstur game 1mb 3d, atau ikon <100k png? (Saya akan menjawab "itu tergantung" tetapi saya akan menahan diri)
Brook

2
@ Brook: Saya kira diasumsikan kita berbicara ikon atau elemen grafis kecil untuk situs web. Tekstur gim, file mentah desain grafis atau gambar presisi untuk mengedit dokumentasi mungkin cerita yang berbeda, Anda benar.
haylem

6
Saya pribadi mengira maksudnya gambar ISO, bukan gambar.
Mahmoud Hossam

2
Ini harus benar-benar untuk gambar ramah-web berukuran kecil / menengah. Kekhawatiran adalah bahwa beberapa penandatangan-dev akan mulai menempel setiap gambar asli yang besar di sana, ketika saya berpikir bahwa mungkin harus menggunakan sesuatu yang lain.
Spong

6
Membaca pertanyaan ini hari ini? Lihatlah jawaban di bawah ini pada git lfs. Mungkin itu yang Anda inginkan. programmers.stackexchange.com/a/306882/92506
jonnybot

Jawaban:


188

Apakah gambar Anda asli atau dapatkah dipulihkan (dijamin?) Dari tempat lain? Apakah mereka perlu mengirimkan unit perangkat lunak yang dibangun dari sumber? Jika mereka asli, mereka perlu membuat cadangan. Tempatkan mereka di kontrol revisi Anda, jika mereka tidak pernah berubah, penalti ruang sama dengan cadangan, dan mereka di mana Anda membutuhkannya.

Bisakah mereka diedit untuk mengubah tampilan perangkat lunak, secara tidak sengaja atau sengaja? Ya - maka mereka HARUS direvisi terkontrol entah bagaimana, mengapa menggunakan cara lain ketika Anda sudah memiliki solusi yang sempurna. Mengapa memperkenalkan kontrol versi "salin dan ganti nama" dari zaman kegelapan?

Saya telah melihat karya seni asli seluruh proyek menjadi "poof" ketika hard drive desainer grafis MacBook meninggal, semua karena seseorang, dengan kebijaksanaan yang tak terbatas, memutuskan bahwa "biner tidak termasuk dalam kontrol putaran", dan desainer grafis (setidaknya yang ini ) cenderung tidak baik dengan cadangan.

Hal yang sama berlaku untuk semua dan semua file biner yang sesuai dengan kriteria di atas.

Satu-satunya alasan untuk tidak melakukannya adalah ruang disk. Saya takut $ 100 / terabyte, alasan itu agak tipis.


44
BTW: Internet BUKAN sumber yang dapat diandalkan. Jika Anda mengunduh gambar dari "bobsfreestuff.com", itu mungkin tidak akan ada di sana minggu depan.
mattnz

16
+1 - dan seharusnya + lebih banyak. Titik kontrol versi adalah untuk memungkinkan Anda memulihkan / mengembalikan ke barang, apa pun barangnya, SETIAP SAAT MASA LALU. Satu-satunya cara untuk menjadi 100% Anda bisa mendapatkan kembali apa yang seharusnya pada saat itu untuk menempatkan SEMUA di bawah kontrol versi. Sumber itulah, gambar, sumber daya, membantu / mendukung PDF. Heck, saya bahkan memasukkan gambar zip Zipped. Saya bahkan telah dikenal untuk menempatkan mesin virtual VM (termasuk VMDK) ke dalam kontrol sumber. Tampak ekstrim? Menyimpan bacon saya 2 tahun kemudian.
cepat_now

3
100% setuju. Jika gambar adalah bagian dari perangkat lunak, mereka harus dikendalikan dengan revisi.
Dean Harding

14
Satu-satunya alasan saya tidak setuju adalah jika repo Anda menjadi sulit untuk dikloning ke titik di mana pengembang harus benar-benar berpikir "apakah saya benar-benar ingin meluangkan waktu untuk mengkloning ini, atau dapatkah saya melakukan X di cabang lain ini". Jika ini terjadi, pastikan semuanya diatur kembali dengan sangat cepat
Brook

5
+1 untuk poin tentang perlunya penyebaran. Jika saya mengkloning repo Anda, karena saya anggota tim baru atau sesuatu, maka itu akan berhasil . Ini termasuk memiliki makefile yang cukup pintar untuk mendapatkan pustaka pihak ke-3 yang diperlukan jika perlu.
Spencer Rathbun

66

Kenapa tidak? :)

Menyimpan binari dianggap praktik buruk, ya, tapi saya tidak pernah terlalu khawatir tentang gambar.

Kasus terburuk, jika Anda memiliki banyak, simpan di tempat lain atau gunakan eksternal atau ekstensi untuk dukungan biner. Dan jika gambarnya tidak sering diubah, lalu di mana masalahnya? Anda tidak akan mendapatkan delta besar yang gemuk. Dan jika mereka dihapus dari waktu ke waktu, itu hanya server Anda yang sedikit menderita menyimpan sejarah, tetapi klien tidak akan melihat apa-apa.

Menurut pendapat saya, Anda tidak perlu khawatir tentang hal itu - asalkan Anda tidak menyimpan GB dari mereka.

Yang bisa Anda lakukan adalah menyimpan gambar "sumber": SVG, makro LaTeX, dll ... dan dapatkan gambar akhir yang dihasilkan oleh sistem build Anda. Itu mungkin lebih baik, jika Anda bisa. Jika tidak, maka jangan repot-repot.

(Semua yang dikatakan, Git bersinar untuk file teks, tetapi bukan VCS terbaik untuk gambar. Beri kami lebih banyak konteks dan metrik jika Anda bisa)


Untuk informasi tambahan, Anda mungkin ingin melihat Q & As ini:


4
+1 untuk menyimpan sumber, tetapi jika mereka dapat melakukan pengujian pengembangan tanpa build lengkap maka itu mungkin mengacaukannya. Itu juga berarti Anda harus membuat semua gambar sebelum mulai bekerja di pagi hari
TheLQ

@TheLQ: Saya kira, tapi mungkin Anda harus memiliki cascading build, di mana downstream Anda (test) builds hanya bisa mengandalkan build upstream (build sebenarnya). Dan kemudian ekspor ini ke folder publik untuk digunakan kembali oleh penguji secara lokal. Itu menyiratkan sedikit infrastruktur, tentu saja, tetapi itu akan menjadi cara saya melakukan sesuatu dalam tim yang relatif besar.
haylem

Apa itu binari?
Daniel Pendergast


5
"Kenapa tidak?" - karena jika repo Anda melebihi 2GB, Bitbucket (dan saya baru mencobanya dengan Github juga) akan menolak repo Anda. Jadi bersiaplah untuk meng-host repo Anda sendiri jika Anda mengasapi mereka dengan banyak gambar.
Jez

48

Pertanyaan ini cukup lama tetapi ini adalah pertanyaan umum yang muncul ketika berhadapan dengan Git dan ada beberapa kemajuan pada solusi modern untuk menyimpan file besar dalam repo Git sejak jawaban terakhir.

Untuk menyimpan file besar di Git ada proyek-proyek berikut:

  • git-annex - Ini sudah ada untuk sementara waktu tapi terus terang kompleksitasnya menghalangi.
  • git-media - Tidak ada pengalaman pribadi dengan ini. Tampak cukup rumit juga.
  • git-fit - Upaya membuat plugin yang lebih sederhana. Membutuhkan penyimpanan S3. Sementara saya menghargai kesederhanaan perhatian utama saya dengan plugin adalah bahwa itu tidak diketahui dan dikelola oleh 1 orang (pengungkapan penuh, saya adalah satu-satunya pengalih lainnya saat ini dan itu untuk masalah sepele).
  • git-lfs - Walaupun saya belum pernah menggunakan ini secara luas, tampaknya itu adalah grail suci. Ini didukung oleh Github dan tersedia di semua repo mereka pada Oktober 2015 dan menempatkan kompleksitas manajemen file di situs menyimpan repo Anda. Satunya downside adalah bahwa ini cukup baru, jadi di luar Github tidak ada banyak dukungan, meskipun Gitlab juga memiliki dukungan , seperti halnya Gitea , dan Bitbucket telah menyinggung dukungan di masa depan .

TLDR: jika Anda bisa, gunakan git-lfs untuk menyimpan gambar atau file biner lainnya di git.


9
Untuk pertama kalinya dalam waktu yang lama, saya sangat senang saya menggulir ke bawah untuk membaca jawaban yang lebih rendah. git lfs tepat seperti yang saya inginkan, dan Atlassian bahkan menambahkan dukungan untuk itu ke BitBucket Server ! Jika saya dapat memperbaiki ini jutaan kali, saya akan melakukannya.
jonnybot

7
@jonnybot, terima kasih. Saya adalah jawaban yang terlambat jadi saya belum mendapatkan banyak visibilitas tetapi setelah menggunakan git-lfs sendiri, saya pikir itu adalah solusi terbaik saat ini untuk menyimpan file biner di git.
James McMahon

45

Seluruh "jangan simpan binari dalam kontrol sumber" ditetapkan untuk alasan tertentu: Jika Anda memiliki kode sumber yang mengkompilasi, jangan menyimpan kompilasi yang sebenarnya, tetapi hanya kode sumber. Gambar dan aset visual tidak memiliki "sumber," sehingga harus dilacak dalam kontrol versi.


4
Terkadang, aset visual memiliki "sesuatu seperti sumber", dan kemudian merupakan ide bagus untuk mengotomatiskan proses menciptakan hasil akhir dan hanya menyimpan sumber dalam kontrol versi. Contoh: versi grafik raster yang dibuat dari file SVG, aset situs web dipotong dari lembar sprite.
tanius

Benar, itu argumen yang sepenuhnya adil.
Jason T Featheringham

21

Saya percaya cara yang disarankan dengan Git adalah dengan menggunakan sub-modul (diperkenalkan pada Git 1.5.3) yang pada dasarnya adalah repositori terpisah yang dikaitkan dengan yang utama. Anda menyimpan gambar Anda (dan aset biner lainnya) dalam sub-modul. Ini kemudian dapat check-out dengan repositori utama atau kiri, tergantung pada apa yang diperlukan.

Dari http://book.git-scm.com/5_submodules.html

"Dukungan submodule Git memungkinkan repositori berisi, sebagai subdirektori, checkout dari proyek eksternal. Submodules mempertahankan identitas mereka sendiri; dukungan submodule hanya menyimpan lokasi repositori submodule dan melakukan komit, sehingga pengembang lain yang mengkloning proyek yang mengandung (" superproject ") dapat dengan mudah mengkloning semua submodul pada revisi yang sama. Pemeriksaan parsial dari superproyek dimungkinkan: Anda dapat meminta Git untuk mengkloning tidak ada, sebagian atau semua submodula."

Juga, ukuran seharusnya tidak menjadi masalah yang signifikan jika gambar tidak sering berubah. Anda juga dapat menjalankan perintah untuk memangkas / mengurangi ukuran, seperti:

git gc
git gc-aggressive
git prune

7

Ya .

Katakanlah Anda merilis perangkat lunak versi 1.0. Untuk versi 2.0 Anda memutuskan untuk mengulang semua gambar menjadi bayangan. Jadi Anda melakukan ini, dan lepaskan 2.0. Kemudian beberapa pelanggan yang menggunakan 1.0 dan tidak dapat memutakhirkan ke 2.0 memutuskan mereka ingin program dalam bahasa lain. Mereka memberi Anda $ 1G untuk melakukannya, jadi Anda mengatakan yakin. Namun dalam budaya yang berbeda, beberapa foto Anda tidak masuk akal, jadi Anda harus mengubahnya ...

Jika Anda ingin menyimpan gambar Anda di kontrol sumber, ini mudah, berdasarkan 1.0 Anda membuat perubahan pada gambar (antara lain), build, release. Jika Anda tidak memiliki ini dalam kontrol sumber, Anda akan memiliki waktu yang jauh lebih sulit, karena Anda harus menemukan gambar-gambar lama, mengubahnya, dan kemudian membangun.


7

Jika itu adalah bagian dari Proyek, itu harus di VCS . Cara mencapai yang terbaik ini mungkin bergantung pada VCS, atau bagaimana Anda mengatur Proyek. Mungkin repo untuk para desainer, dan hanya hasil dalam repo coder, atau hanya 'Sumber gambar' (saya pernah punya proyek dengan hanya file .svg, dan gambar di mana dihasilkan melalui make / inscape cli).

Tapi, jika VCS tidak bisa menangani itu, atau menjadi tidak dapat digunakan, saya akan mengatakan, bahwa itu bukan alat yang tepat untuk pekerjaan Anda.

Sejauh ini, saya tidak punya masalah dengan menempatkan jumlah grafik 'biasa' (maket, konsep, dan grafik halaman) untuk proyek web di git.


5

Jika Anda menyimpan gambar Anda di SCM: ya. Tanpa keraguan.

Jika Anda menyimpan gambar Anda di git: ini menjadi lebih rumit.

git sangat baik dengan file teks, tetapi pada dasarnya tidak terlalu panas dengan binari. Anda akan memiliki masalah dengan ukuran data yang ditransfer ketika Anda mengkloning atau mendorong, direktori .git Anda akan tumbuh, dan Anda bisa mendapatkan kekacauan yang tepat dengan penggabungan (yaitu bagaimana Anda menggabungkan 2 gambar!)

Satu jawaban adalah dengan menggunakan submodul, karena ini berarti hubungan antara proyek Anda dan gambar akan lebih lemah - jadi Anda tidak perlu mengelola gambar seolah-olah mereka adalah bagian dari sumber Anda, namun tetap membuat mereka terkontrol, dan tidak memiliki khawatir dengan percabangan mereka - dengan asumsi proyek hanya repositori data 'datar' yang tidak melalui churn yang sama selama proses pengembangan biasa.

Jawaban lainnya adalah menempatkan mereka di proyek yang berbeda, tidak pernah melakukan percabangan, dan memastikan bahwa setiap orang yang berkomitmen untuk proyek itu mendorongnya segera - jangan pernah membiarkan 2 orang mengubah versi file yang sama - Anda akan menemukan ini yang paling sulit Aspek seperti git tidak dirancang untuk alur kerja yang tidak terdistribusi. Anda harus menggunakan metode komunikasi kuno untuk mengikuti aturan ini.

Jawaban ketiga adalah menempatkan mereka dalam SCM yang sama sekali berbeda yang lebih baik diarahkan untuk bekerja dengan gambar.


0

Menambah jawaban @ haylem, perhatikan bahwa ukuran memainkan faktor besar dalam hal ini. Bergantung pada VCS, itu mungkin tidak bekerja dengan baik dengan banyak gambar. Ketika klon atau dorongan besar mulai mengambil sepanjang malam maka itu sudah sangat terlambat karena semua gambar sudah ada di repositori Anda.

Rencanakan gambar besar dan pertumbuhan di masa depan. Anda tidak ingin mendapatkan dua tahun ke dalam proyek ini dan memiliki "oh sial, mungkin repo itu agak terlalu besar."


1
Jawaban Anda agak tidak relevan, karena pertanyaannya khusus untuk git. Apakah Anda tahu kalau ukuran memainkan faktor besar (atau apa pun) untuk repositori git?
yannis

@Yannis Harus ketinggalan kalimat pertama itu ... AFAIK, git lebih baik dengan repositori yang lebih besar tetapi masalah ukuran masih relevan karena klon atau
desakan

Dengan GIT sepele mudah untuk mengatur ulang repositori dan membuat klon parsial dll, jika ini terjadi menjadi masalah. Jangan bingung molase historis alat kontrol revisi dari beberapa dekade yang lalu dengan yang ada saat ini.
mattnz

0

Saya setuju bahwa menyimpannya secara teknis dan ekonomis adalah layak. Pertanyaan yang saya inginkan adalah "apakah gambar-gambar ini bagian dari produk pengiriman atau bagian dari konten produk pengiriman?" Bukan berarti Anda tidak dapat menyimpan konten di GIT (atau VCS lainnya) tetapi itu merupakan masalah terpisah untuk VCS terpisah.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.