Artikel ini adalah sebahagian daripada siri "Advanced Git". Pastikan anda mengikuti kami di Twitter atau mendaftar untuk surat berita kami untuk melihat artikel masa depan!
Ciri "reflog" Git tidak diketahui, tetapi ia sangat praktikal. Sesetengah orang menyebutnya "jaring keselamatan" dan saya lebih suka memikirkannya sebagai "buku harian" git. Ini kerana GIT menggunakannya untuk merakam setiap langkah penunjuk kepala (iaitu, setiap komit, menggabungkan, rebase, memilih, menetapkan semula, dll.). Git log tindakan anda dalam reflog, menjadikannya buku log yang berharga dan titik permulaan yang baik apabila masalah timbul.
Di bahagian terakhir siri "Advanced Git" ini, saya akan menerangkan perbezaan antara git log
dan git reflog
dan menunjukkan kepada anda cara menggunakan reflog untuk memulihkan cawangan yang dipadam dan dipadam.
git log
atau git reflog
: Apa perbezaannya? Dalam jawatan terdahulu, saya mencadangkan agar anda menggunakan arahan git log
untuk menyemak peristiwa sebelumnya dan melihat sejarah komit anda, yang betul -betul apa yang dilakukannya. Ia memaparkan kepala semasa dan nenek moyangnya, iaitu ibu bapa, ibu bapa seterusnya, dan sebagainya. Log -balak itu kembali ke permulaan sejarah komit dengan mencetak secara rekursif ibu bapa setiap komit. Ia adalah sebahagian daripada repositori, yang bermaksud ia akan disalin selepas anda menolak, mengambil, atau menarik.
Sebaliknya, git reflog
adalah rekod yang berkaitan dengan ruang kerja swasta. Ia tidak melangkah ke atas senarai nenek moyang. Sebaliknya, ia memaparkan senarai yang diperintahkan dari semua komitmen yang ditunjuk oleh kepala pada masa lalu. Itulah sebabnya anda boleh memikirkannya sebagai semacam "sejarah membatalkan" seperti yang anda lihat dalam pemproses kata, editor teks, dll.
Rekod tempatan ini tidak secara teknikal sebahagian daripada repositori dan ia disimpan secara berasingan daripada komit. Reflog adalah fail dalam .git/logs/refs/heads/
yang menjejaki komitmen tempatan setiap cawangan. Buku harian Git biasanya dibersihkan selepas 90 hari (ini adalah lalai), tetapi anda boleh dengan mudah menyesuaikan tarikh tamat tempoh reflog. Untuk menukar bilangan hari menjadi 180, taipkan arahan berikut:
$ git config gc.reflogexpire 180.days.ago
Sebagai alternatif, anda boleh memutuskan bahawa reflog anda tidak akan luput:
$ git config gc.reflogexpire tidak pernah
Petua: Ingatlah bahawa git membezakan fail konfigurasi repositori ( .git/config
), konfigurasi pengguna global ( $HOME/.gitconfig
), dan tetapan seluruh sistem ( /etc/gitconfig
). Untuk menyesuaikan tarikh tamat tempoh pengguna atau sistem, tambahkan parameter --system
atau --global
ke arahan yang ditunjukkan di atas.
Latar belakang teoretikal yang cukup - biarkan saya menunjukkan kepada anda cara menggunakan git reflog
untuk membetulkan kesilapan.
Bayangkan senario berikut: Selepas melihat sejarah komit, anda memutuskan untuk memadamkan dua komitmen terakhir. Anda berani melaksanakan git reset
, dan kedua -dua komitmen itu hilang dari sejarah komit ... selepas beberapa ketika anda perasan bahawa ini adalah pepijat. Anda hanya kehilangan perubahan berharga anda dan mula panik!
Adakah anda benar -benar perlu bermula dari awal? Tidak perlu. Dengan kata lain: Tetap tenang dan gunakan git reflog
!
Oleh itu, mari kita merosakkan perkara ini dalam kehidupan sebenar. Imej seterusnya menunjukkan sejarah komit asal kami di Menara (pelanggan Git Grafik):
Kami mahu memadam kedua -dua komitmen dan menetapkan perubahan mengenai dan mencetak gelaran komit (ID: 2B504BEE) sebagai semakan terakhir pada cawangan induk kami. Kami hanya menyalin ID hash ke papan klip, kemudian gunakan git reset
dalam baris arahan dan masukkan nilai hash itu:
$ git reset -hard 2b504bee
Lihat! Penyerahan itu hilang. Sekarang, mari kita anggap ini adalah kesilapan dan melihat reflog untuk memulihkan data yang hilang. Taip git reflog
untuk melihat jurnal di terminal anda:
Anda akan melihat bahawa semua penyertaan disusun dalam susunan kronologi. Ini bermakna: komit terkini adalah di bahagian atas. Dan, jika anda melihat dengan teliti, anda akan melihat operasi git reset
yang mematikan di bahagian atas beberapa minit yang lalu.
Buku harian itu seolah -olah berfungsi - itu berita baik. Oleh itu mari kita gunakan untuk membatalkan tindakan terakhir dan memulihkan keadaan sebelum perintah semula. Seperti sebelum ini, salin Hash ID (E5B19E4 dalam contoh khusus ini) ke papan klip. Anda boleh menggunakan git reset
sekali lagi, yang berfungsi dengan sempurna. Tetapi dalam kes ini saya akan membuat cawangan baru berdasarkan keadaan lama:
$ git cawangan gembira e5b19e4
Mari kita lihat pelanggan Git Grafik kami sekali lagi:
Seperti yang anda dapat lihat, cawangan baru yang dipanggil Happy-endes telah dicipta dengan komitmen kami yang telah dipadam sebelum ini-hebat, tidak ada yang hilang!
Mari kita lihat contoh lain dan gunakan reflog untuk memulihkan seluruh cawangan.
Contoh seterusnya adalah sama dengan senario pertama kami: kami akan memadamkan sesuatu -masa ini seluruh cawangan. Mungkin pelanggan atau ketua pasukan anda memberitahu anda untuk memadamkan cawangan ciri, mungkin idea membersihkan diri anda. Lebih buruk lagi, komit (C3 dalam gambar) tidak termasuk dalam mana -mana cawangan lain, jadi anda pasti kehilangan data:
Mari kita lakukan ini dan kemudian memulihkan cawangan kemudian:
Anda perlu meninggalkannya sebelum anda boleh memadam cawangan feature/login
. (Seperti yang ditunjukkan dalam tangkapan skrin, ia adalah cawangan kepala semasa, anda tidak boleh memadam cawangan kepala dalam git.) Jadi kami akan menukar cawangan (untuk menguasai) dan kemudian kami akan memadam feature/login
:
Ok ... sekarang mari kita anggap bahawa pelanggan atau pemimpin pasukan kami telah mengubah fikirannya. Lagipun, cawangan feature/login
(termasuk komitmen mereka) diperlukan. Apa yang harus kita lakukan?
Mari kita lihat buku harian git:
$ git reflog 776f8ca (kepala -> master) kepala@{0}: checkout: bergerak dari ciri/log masuk ke tuan b1c249b (ciri/log masuk) kepala@{1}: checkout: bergerak dari tuan ke ciri/log masuk [...]
Kami telah terbukti bertuah lagi. Entri terakhir menunjukkan bagaimana kita beralih dari feature/login
ke menguasai. Mari cuba kembali ke negeri sebelumnya dan salin Hash ID B1C249B ke papan klip. Seterusnya, kami akan mencipta feature/login
yang dinamakan cawangan berdasarkan keadaan yang diperlukan:
Ciri Cawangan $ Git/Login B1C249B cawangan $ git -vv Ciri/Log masuk B1C249B Tukar tajuk halaman iPrint * Master 776F8CA Perubahan mengenai Tajuk dan Padam Halaman Ralat
Hebat - cawangan pulih dari kematian, dan juga termasuk komitmen yang berharga yang kita anggap hilang:
Jika anda menggunakan Git dalam GUI desktop seperti menara, anda boleh membatalkan tindakan terakhir anda hanya dengan menekan CMD Z seperti editor teks atau pemproses perkataan apabila anda menaip kesilapan.
Reflog Git boleh menjadi Juruselamat yang sebenar! Seperti yang anda dapat lihat, sangat mudah untuk menghilangkan komitmen yang hilang dari kubur atau bahkan seluruh cawangan. Apa yang perlu anda lakukan ialah mencari id hash yang betul dalam reflog - selebihnya adalah sekeping kek.
Sekiranya anda ingin menggali alat -alat Git Advanced, jangan ragu untuk menyemak (percuma!) Lanjutan Git Toolkit: Ini adalah koleksi video pendek mengenai topik seperti strategi cawangan, rebase interaktif, reflog, submodules, dan banyak lagi.
Ini adalah bahagian terakhir siri "Advanced Git" kami pada trik CSS. Saya harap anda menikmati artikel ini. Selamat Hacker!
Atas ialah kandungan terperinci Menggunakan reflog untuk memulihkan komitmen yang hilang. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!