Seberapa sering Anda harus menggunakan git-gc?


233

Seberapa sering Anda harus menggunakan git-gc?

The halaman pengguna hanya mengatakan:

Pengguna didorong untuk menjalankan tugas ini secara teratur dalam setiap repositori untuk mempertahankan pemanfaatan ruang disk yang baik dan kinerja operasi yang baik.

Apakah ada beberapa perintah untuk mendapatkan jumlah objek untuk mengetahui apakah sudah waktunya untuk gc?


Tugas seperti ini adalah kandidat utama untuk cron (jika Anda menggunakan linux) minhajuddin.com/2011/12/12/09/...
Khaja Minhajuddin

1
Catatan: pengaturan gc.autodetach(Git 2.0 Q2 2014) dapat membantu menjalankan git gc --autotanpa mengganggu pengguna. lihat jawaban saya di bawah ini .
VonC

Jawaban:


204

Sebagian besar tergantung pada seberapa banyak repositori digunakan. Dengan satu pengguna memeriksa sekali sehari dan operasi cabang / gabungan / dll seminggu sekali Anda mungkin tidak perlu menjalankannya lebih dari sekali setahun.

Dengan beberapa lusin pengembang bekerja pada beberapa lusin proyek masing-masing memeriksa dalam 2-3 kali sehari, Anda mungkin ingin menjalankannya setiap malam.

Tidak ada ruginya untuk menjalankannya lebih sering daripada yang dibutuhkan.

Apa yang saya lakukan adalah menjalankannya sekarang, lalu seminggu dari sekarang mengambil pengukuran pemanfaatan disk, jalankan lagi, dan mengukur pemanfaatan disk lagi. Jika ukurannya turun 5%, maka jalankan seminggu sekali. Jika turun lebih banyak, maka jalankan lebih sering. Jika kurang tetes, maka jalankan lebih jarang.


17
Manual mengatakan "Beberapa perintah git menjalankan git gc --auto setelah melakukan operasi yang dapat membuat banyak objek longgar." Adakah yang tahu perintah mana yang benar-benar menjalankannya?
Joshua Dance

2
Rebase besar git adalah contoh yang jelas, karena banyak komit yang ditulis ulang menjadi sejarah baru - meninggalkan banyak komit lama di repo Anda yang merupakan bagian dari cabang saat ini lagi
mafrosis

20
"Tidak ada ruginya untuk menjalankannya lebih sering daripada yang dibutuhkan" ... Saya tidak sepenuhnya setuju. Seperti yang ditunjukkan oleh Aristoteles, menggantung komitmen dapat membuat mekanisme cadangan yang baik.
Jason Baker

105

Perhatikan bahwa sisi negatif dari pengumpulan sampah repositori Anda adalah, yah, sampah dikumpulkan. Seperti kita ketahui sebagai pengguna komputer, file yang kita anggap sampah sekarang mungkin menjadi sangat berharga tiga hari di masa depan. Fakta bahwa git menyimpan sebagian besar puing-puingnya telah menyelamatkan bacon saya beberapa kali - dengan menelusuri semua komitmen yang menggantung, saya telah memulihkan banyak pekerjaan yang secara tidak sengaja saya kalengan.

Jadi jangan terlalu aneh dalam klon pribadi Anda. Hanya ada sedikit kebutuhan untuk itu.

OTOH, nilai pemulihan data dipertanyakan untuk repo yang digunakan terutama sebagai remote, misalnya. tempat semua devs dorong ke dan / atau ditarik dari. Di sana, mungkin masuk akal untuk memulai menjalankan GC dan pengemasan ulang sering.


38
FWIW tidak semua benda lepas adalah sampah yang dikumpulkan, hanya yang lebih dari 2 minggu secara default (lih. git gc --help, Khususnya --pruneopsi). Ada juga yang menyebutkan gc.reflogExpire, yang membuat saya percaya bahwa setiap komitmen yang Anda kunjungi dalam 90 hari terakhir tidak akan dikumpulkan. (Versi git saya: v1.7.6)
RobM

30

Versi terbaru dari git menjalankan gc secara otomatis ketika diperlukan, jadi Anda tidak perlu melakukan apa pun. Lihat bagian Opsi man git-gc (1) : "Beberapa perintah git menjalankan git gc --auto setelah melakukan operasi yang dapat membuat banyak objek longgar."


13
Saya baru saja menjalankannya untuk pertama kalinya pada repositori berusia beberapa tahun, dan .git saya beralih dari 16 juta menjadi 2,9 juta, pengurangan ukuran 82%. Karena itu masih berguna untuk menjalankan perintah secara manual.
Darshan Rivka Whittle

@DarshanRivkaWhittle sudahkah Anda memperbarui git dalam beberapa tahun itu?
std''OrgnlDave

1
@ std''OrgnlDave Ya, saya selalu menjalankan versi apa pun yang saat ini ada di Arch. Saya hanya menjalankannya lagi, mungkin untuk pertama kalinya sejak komentar terakhir saya (terima kasih atas komentar Anda yang mengingatkan saya), dan .git saya berubah dari 81M menjadi 13M. Saya tidak boleh menjalankan perintah yang dijalankan gc --auto, saya kira.
Darshan Rivka Whittle

18

Jika Anda menggunakan Git-Gui , itu memberi tahu Anda saat Anda harus khawatir:

This repository currently has approximately 1500 loose objects.

Perintah berikut akan membawa nomor yang sama:

$ git count-objects

Kecuali, dari sumbernya , git-gui akan menghitung sendiri, menghitung sesuatu di .git/objectsfolder dan mungkin membawa perkiraan (saya tidak tahu tclcara membacanya dengan benar!).

Bagaimanapun, tampaknya memberikan peringatan berdasarkan angka sewenang-wenang sekitar 300 objek longgar.


Memang memang memperingatkan, tetapi setelah membiarkannya berjalan gc, sebagian besar waktu gc tidak akan melakukan apa pun. Jadi dengan mengandalkan git gui untuk melakukannya, adalah menunggu lebih dari 6000 objek longgar dengan selalu harus mengklik pada run gc dan menunggu sebentar atau membatalkan: / Mungkin seseorang harus memperbaiki git gui dengan cara itu memeriksa max longgar objek menghitung dan tidak repot menampilkan dialog sampai hitungan mencapai batas.
mlatu

Ya @mlatu saya setuju. Ketika saya menulis ini, saya hanya ingin menarik perhatian. Keduanya Git-Guidan count-objectsbukan jawaban yang tepat untuk pertanyaan di sini ... Tapi seharusnya begitu!
cregox

saya tidak bermaksud bahwa ini adalah jawaban yang buruk, hanya ingin menunjukkan bahwa sebagian besar waktu git gui tidak melakukan apa-apa. meskipun saya kira git gc tidak melakukan banyak hal baik, kecuali ketika ada cukup banyak untuk dilakukan atau Anda menggunakan saklar agresif.
mlatu

7

Jatuhkan dalam tugas cron yang berjalan setiap malam (sore?) Ketika Anda tidur.


7

Saya menggunakan git gc setelah saya melakukan checkout besar, dan memiliki banyak objek baru. itu bisa menghemat ruang. Misalnya jika Anda checkout proyek SVN besar menggunakan git-svn, dan melakukan git gc, Anda biasanya menghemat banyak ruang


Apakah ini masih benar? Bahkan di ruang '08 HDD itu murah, menggunakan itu sebagai pembenaran untuk menjalankannya tampaknya tidak ada gunanya
Thymine

7

Anda dapat melakukannya tanpa gangguan apa pun, dengan pengaturan baru (Git 2.0 Q2 2014) gc.autodetach.

Lihat komit 4c4ac4d dan komit 9f673f9 ( Nguyễn Thái Ngọc Duy, alias pclouds ):

gc --automembutuhkan waktu dan dapat memblokir pengguna untuk sementara waktu (tetapi tidak kurang mengganggu).
Jadikan itu berjalan di latar belakang pada sistem yang mendukungnya.
Satu-satunya hal yang hilang dengan berjalan di latar belakang adalah cetakan. Tapi gc outputitu tidak terlalu menarik.
Anda dapat menyimpannya di latar depan dengan mengubah gc.autodetach.


Sejak rilis 2.0, ada bug meskipun: git 2.7 (Q4 2015) akan memastikan untuk tidak kehilangan pesan kesalahan .
Lihat komit 329e6e8 (19 Sep 2015) oleh Nguyễn Thái Ngọc Duy ( pclouds) .
(Digabung oleh Junio ​​C Hamano - gitster- dalam komit 076c827 , 15 Okt 2015)

gc: simpan log dari daemonized gc --autodan cetak waktu berikutnya

Sementara komit 9f673f9 ( gc: opsi config untuk berjalan --autodi latar belakang - 2014-02-08) membantu mengurangi beberapa keluhan tentang ' gc --auto' memonopoli terminal, itu menciptakan serangkaian masalah lain.

Yang terbaru dalam set ini adalah, sebagai hasil daemonisasi, stderrditutup dan semua peringatan hilang. Peringatan di akhir cmd_gc()ini sangat penting karena memberi tahu pengguna cara " gc --auto" menghindari berjalan berulang kali.
Karena stderr ditutup, pengguna tidak tahu, secara alami mereka mengeluh tentang ' gc --auto' buang-buang CPU.

Daemonized gcsekarang menyimpan stderrke $GIT_DIR/gc.log.
Mengikuti gc --autotidak akan berjalan dan gc.logdicetak sampai pengguna menghapusgc.log
.


6

Kutipan ini diambil dari; Kontrol Versi dengan Git

Git menjalankan pengumpulan sampah secara otomatis :

• Jika ada terlalu banyak objek longgar di repositori

• Ketika push ke repositori jarak jauh terjadi

• Setelah beberapa perintah yang mungkin memperkenalkan banyak objek longgar

• Ketika beberapa perintah seperti git reflog kedaluwarsa memintanya secara eksplisit

Dan akhirnya, pengumpulan sampah terjadi ketika Anda secara eksplisit memintanya menggunakan perintah git gc. Tetapi kapan itu seharusnya? Tidak ada jawaban yang kuat untuk pertanyaan ini, tetapi ada beberapa saran bagus dan praktik terbaik.

Anda harus mempertimbangkan menjalankan git gc secara manual dalam beberapa situasi:

• Jika Anda baru saja menyelesaikan cabang git filter. Ingatlah bahwa cabang-filter menulis ulang banyak komit, memperkenalkan yang baru, dan membiarkan yang lama pada ref yang harus dihapus ketika Anda puas dengan hasilnya. Semua benda mati (yang tidak lagi direferensikan karena Anda baru saja menghapus satu referensi yang menunjuk kepada mereka) harus dihapus melalui pengumpulan sampah.

• Setelah beberapa perintah yang mungkin memperkenalkan banyak objek longgar. Ini mungkin merupakan upaya rebase besar, misalnya.

Dan di sisi lain, kapan Anda harus waspada terhadap pengumpulan sampah?

• Jika ada wasit yatim yang mungkin ingin Anda pulihkan

• Dalam konteks git rerere dan Anda tidak perlu menyimpan resolusi selamanya

• Dalam konteks hanya tag dan cabang yang cukup untuk menyebabkan Git mempertahankan komit secara permanen

• Dalam konteks pengambilan FETCH_HEAD (pengambilan URL-direct via git fetch) karena mereka segera dikenai pengumpulan sampah


2
Saya memiliki komitmen yang tidak dapat dijangkau di pohon saya (sebagai akibat dari git commit --amend). Ini dapat diverifikasi dengan git log --reflog. Saya mendorong cabang ke repositori jarak jauh dan memeriksa pohon saya lagi; komitmen yang tidak terjangkau masih ada di sana. Rupanya git gctidak berjalan ketika dorongan ini terjadi. …?
chharvey

4

Saya menggunakan ketika saya melakukan komit besar, terutama ketika saya menghapus lebih banyak file dari repositori .. setelah itu, komit lebih cepat


1

Anda tidak harus git gcsering menggunakannya , karena git gc(Pengumpulan sampah) dijalankan secara otomatis pada beberapa perintah yang sering digunakan:

git pull
git merge
git rebase
git commit

Sumber: praktik terbaik dan FAQ git gc

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.