Kedatangan de Git 2.54 Ini menandai langkah baru dalam evolusi sistem kontrol versi yang paling banyak digunakan di dunia untuk pengembangan perangkat lunak. Komunitas proyek, dengan lebih dari 130 orang yang berkolaborasi dalam siklus ini, telah berfokus pada penyederhanaan tugas-tugas umum tanpa mengorbankan kekuatan yang menjadi ciri khas Git.
Di antara fitur-fitur baru yang mungkin paling menarik adalah cara baru untuk menulis ulang sejarah Secara lebih langsung, kemampuan untuk mengkonfigurasi hook bersama dari file konfigurasi umum dan peningkatan internal yang bertujuan untuk menciptakan repositori yang lebih cepat dan mudah dipelihara, terutama dalam proyek-proyek besar atau korporat.
Git 2.54: Gambaran umum rilis baru
Git 2.54 adalah versi perantara menuju cabang 3.0 di masa mendatang, tetapi versi ini membawa perubahan yang memengaruhi pekerjaan sehari-hari banyak pengembang. Salah satunya adalah, Perintah eksperimental git history telah dirilis.Dirancang untuk operasi penulisan ulang riwayat yang sederhana. Selain itu, sistem hook diperluas dan dimodernisasi, dan sekarang dapat dikelola dari pengaturan; strategi pemeliharaan geometris sekarang menjadi default.
Selain itu, peningkatan juga disertakan dalam perintah yang sudah dikenal seperti git add -p, git replay, git status atau git rebaseserta penyesuaian pada transportasi HTTP, cara tampilan tanda tangan GPG, dan cara kerja internal basis data objek. Meskipun banyak fitur baru ini canggih, dampaknya akan terasa dalam alur kerja umum di bisnis, administrasi publik, dan proyek sumber terbuka dengan repositori besar.
Perintah eksperimental baru git history: penulisan ulang commit yang mudah
Salah satu tambahan utama di Git 2.54 adalah riwayat git, sebuah perintah yang masih bersifat eksperimental yang dimaksudkan untuk mencakup kasus-kasus di mana penggunaan rebase interaktif terlalu berlebihan. Hingga saat ini, alat utama untuk memodifikasi riwayat lokal adalah git rebase -i, sangat fleksibel tetapi juga lebih kompleks dan rentan membuat pengguna berada dalam kondisi yang saling bertentangan yang harus diselesaikan secara manual.
dengan riwayat git Pendekatan yang lebih langsung dicari untuk tugas-tugas spesifik: misalnya, memperbaiki kesalahan ketik dalam pesan commit dari beberapa perubahan sebelumnya, atau membagi commit yang sudah terlalu besar menjadi dua. Idenya adalah untuk menawarkan cara terkontrol untuk mengubah riwayat tanpa harus menyiapkan seluruh mekanisme rebase interaktif dengan daftar tugas dan langkah-langkah perantara.
Perintah reword: mengubah pesan commit tanpa menyentuh working tree.
Modus pertama yang diluncurkan oleh tatanan baru ini adalah... git history reword <commit>Saat dijalankan, Git membuka editor yang dikonfigurasi pengguna dengan pesan commit yang ditentukanHal ini memungkinkan Anda untuk memodifikasinya secara langsung. Saat Anda menyimpan dan menutup editor, Git akan menulis ulang commit tersebut dan secara otomatis memperbarui cabang-cabang yang diturunkan darinya untuk menunjuk ke versi baru.
Perbedaan utama dibandingkan dengan rebase interaktif adalah bahwa Perintah `git history reword` tidak mengubah working tree maupun index.Fungsinya hanya memperbarui riwayat. Hal ini membuatnya sangat berguna dalam lingkungan integrasi berkelanjutan atau skrip otomatis, karena bahkan dapat beroperasi pada repositori kosong, yang umum di server kode internal perusahaan atau institusi di mana tidak ada pohon kerja terkait.
subperintah split: membagi commit secara interaktif
Mode kedua, git history split <commit>Fitur ini dirancang untuk situasi di mana satu commit berisi perubahan yang perlu dipisahkan. Saat dijalankan, Git menampilkan bagian-bagian (hunks) yang terkait dengan commit tersebut dan memungkinkan Anda untuk memilih bagian mana yang harus diekstrak ke commit induk baru, mirip dengan cara kerja `git extract`. git tambahkan -p saat memutuskan bagian kode mana yang akan ditambahkan ke indeks.
Setelah fragmen dipilih, Git membuat sebuah Commit baru dengan bagian-bagian yang dipilih sebagai induk dari commit asli.Proses ini mempertahankan perubahan yang tidak dipilih pada commit sebelumnya. Kemudian, ia menulis ulang cabang-cabang turunan untuk menunjuk ke struktur riwayat yang baru. Sekali lagi, operasi ini berjalan tanpa mengubah isi pohon kerja saat ini, mengurangi kemungkinan meninggalkan repositori dalam keadaan perantara yang rumit.
Keterbatasan dan kompatibilitas dengan alur kerja lain
Untuk menjaga agar perilaku tetap terkendali, git history tidak mendukung riwayat dengan commit penggabungan (merge commits). dan menolak untuk melanjutkan jika operasi tersebut mengakibatkan konflik penggabungan. Ini dirancang untuk penyesuaian kecil, bukan untuk penulisan ulang besar-besaran seperti yang biasanya ditangani dengan git rebase -i atau strategi pembersihan riwayat yang lebih agresif.
Secara internal, komando tersebut bergantung pada mekanisme pemutaran ulang gityang telah berkembang sebagai alat eksperimental untuk mereproduksi commit pada basis lain tanpa menyentuh working tree. Sebagian dari pekerjaan ini terdiri dari mengekstrak logika tersebut ke dalam pustaka umum, sehingga keduanya git history karena fungsi-fungsi lain di masa mendatang dapat memanfaatkan infrastruktur yang lebih modular yang lebih mudah diotomatisasi dari skrip atau alat pihak ketiga.
Hook berbasis konfigurasi: berbagi dan menggabungkan otomatisasi
Fitur baru penting lainnya dari Git 2.54 adalah kemampuan untuk tentukan hook secara langsung di file konfigurasialih-alih hanya mengandalkan skrip yang ditempatkan di direktori tersebut .git/hooks atau pada rute yang ditunjukkan oleh core.hooksPathPerubahan ini membuat berbagi pemeriksaan antar repositori yang berbeda menjadi jauh lebih mudah tanpa harus mereplikasi file secara manual.
Sampai sekarang, untuk menerapkan, misalnya, pemformat kode atau penganalisis rahasia sebelum setiap commit di berbagai proyek, perlu untuk menyalin skrip hook ke setiap repositori atau menggunakan alat manajemen hook eksternal. Dengan pendekatan baru ini, dimungkinkan untuk mendefinisikan kait tengah di ~/.gitconfig atau dalam /etc/gitconfig perusahaan dan bahwa hal-hal ini diterapkan bila diperlukan.
Mendefinisikan hook melalui konfigurasi dan beberapa perintah per peristiwa.
Sintaks baru ini didasarkan pada kunci konfigurasi gaya. hook.<nombre>.command y hook.<nombre>.eventYang pertama menunjukkan perintah mana yang akan dieksekusi, dan yang kedua menentukan Peristiwa kait mana yang memicunya?misalnya sebuah pre-commit atau pre-pushKarena ini merupakan konfigurasi standar, pengaturan ini dapat ada secara bersamaan di berbagai tingkatan: pengguna, sistem, atau repositori.
Selain itu, Git sekarang memungkinkan hal tersebut. beberapa kait (hook) ditugaskan ke peristiwa yang samaDengan kata lain, Anda dapat mendefinisikan, misalnya, linter dan pemindai kredensial untuk dijalankan pada masing-masing pre-committanpa perlu menggabungkannya secara manual ke dalam satu skrip. Git mengulangi entri konfigurasi secara berurutan dan mengeksekusi setiap perintah, sambil tetap mempertahankan dukungan untuk skrip klasik. $GIT_DIR/hooks, yang terus berjalan hingga akhir agar tidak merusak konfigurasi sebelumnya.
Pengelolaan, penonaktifan, dan modernisasi internal dari pengait.
Untuk memeriksa hook mana yang aktif dan dari mana asalnya, perintah berikut digunakan. git hook listyang menunjukkan asal-usul masing-masing, sesuatu yang berguna saat mengelola. konfigurasi terpusat Dalam lingkungan perusahaan, jika repositori tertentu perlu mengecualikan hook yang diwarisi dari file global, cukup dengan mengatur hook.<nombre>.enabled = false, tanpa perlu menghapus atau memodifikasi konfigurasi asli.
Secara internal, Git memiliki menyatukan dan memodernisasi cara penanganannya terhadap banyak kait internalnya.Beberapa titik integrasi yang sebelumnya dikelola dengan rute ad hoc, seperti hook untuk pre-push, post-rewrite atau yang dari receive-packMereka sekarang menggunakan API hook yang baru. Ini tidak hanya menghadirkan konsistensi, tetapi juga mempermudah lingkungan integrasi berkelanjutan atau platform pembuatan kode untuk beradaptasi dengan perubahan di masa mendatang tanpa harus menulis ulang integrasi tertentu.
Pemeliharaan geometris sebagai strategi standar
Pada versi sebelumnya, Git memperkenalkan apa yang disebut strategi geometris dalam git maintenanceDirancang untuk mengurangi biaya tugas pengemasan ulang di repositori besar, strategi ini menganalisis file kemasan yang ada dan mencari kombinasi yang membentuk deret geometri berdasarkan jumlah objek, memadatkan isinya tanpa perlu melakukan pengumpulan sampah penuh setiap kali.
Dengan Git 2.54, pendekatan ini menjadi opsi default untuk perawatan manualSaat berjalan git maintenance run Tanpa menentukan strategi, pendekatan geometris secara otomatis dipilih, alih-alih langsung menggunakan tugas klasik yaitu gc yang mencoba mengelompokkan semuanya ke dalam satu paket.
Dalam praktiknya, hal ini berarti bahwa Repositori dikelola dengan lebih efisien. Sejak awal, ini sangat menarik untuk proyek-proyek dengan sejarah panjang atau untuk organisasi yang mengelola monorepositori besar. Strategi geometris menggabungkan paket inkremental bila masuk akal dan hanya menggunakan paket yang lebih besar. gc Selesai ketika semuanya benar-benar akan dikonsolidasikan ke dalam satu file paket. Selama proses tersebut, grafik commit, reflog, dan struktur tambahan lainnya terus diperbarui.
Mereka yang sudah melakukan konfigurasi maintenance.strategy = geometric Mereka tidak akan menyadari adanya perubahan, karena preferensi tersebut dihormati. Dan mereka yang lebih memilih untuk melanjutkan dengan pendekatan tradisional dapat memaksakan strategi gc pengaturan maintenance.strategy = gcsehingga tetap kompatibel dengan alur yang lebih konservatif.
Peningkatan pada perintah interaktif dan eksperimental.
Selain fitur-fitur baru utama, Git 2.54 menghadirkan berbagai perubahan yang ditujukan untuk menyempurnakan pengalaman pengguna sehari-harikhususnya pada perintah yang digunakan secara interaktif untuk mengelola perubahan.
Penyempurnaan pada git menambahkan opsi navigasi baru -py
Mode interaktif dari git add -p dan perintah terkait menerima berbagai peningkatan kegunaan. Saat bernavigasi antar bagian menggunakan tombol J y KGit sekarang menunjukkan apakah sebuah fragmen telah diterima atau dilewati sebelumnyamenghindari keharusan mengingat setiap keputusan secara manual.
Opsi tersebut juga ditambahkan. --no-auto-advanceyang mengubah perilaku saat menyelesaikan pemrosesan sebagian file. Alih-alih secara otomatis beralih ke file berikutnya, sesi tetap berada pada file saat ini, memungkinkan Anda untuk menggunakan < y > untuk berpindah antar file dengan lebih tenang. Cara kerja ini berguna ketika Anda ingin meninjau keseluruhan pilihan perubahan sebelum mengkonfirmasinya.
git replay: kematangan lebih untuk mengeksekusi ulang commit
Urutan percobaan pemutaran ulang gitFitur yang dirancang untuk mereplikasi commit pada basis baru tanpa memodifikasi working tree terus mendapatkan peningkatan kemampuan. Pada versi ini, fitur tersebut sekarang melakukan hal berikut: memperbarui referensi secara atomik Secara default, alih-alih menampilkan perintah update-ref pada keluaran standar.
Selain itu, ini juga mencakup sebuah mode. --revert memungkinkan membatalkan perubahan dari serangkaian commitFitur ini mampu membuang commit yang menjadi kosong selama proses berlangsung dan sekarang mendukung pemutaran ulang riwayat hingga commit akar. Perbaikan ini sangat sesuai dengan penggunaan git historyyang mengandalkan infrastruktur yang sama untuk menawarkan pengalaman yang lebih aman.
Opsi baru – trailer di git rebase
Penyesuaian menarik lainnya adalah penambahan --trailer en git rebaseyang memanfaatkan logika dari interpret-trailers ayat tambahkan trailer yang sama ke setiap commit yang melampaui batasAlih-alih membuat perintah panjang dengan -x dan panggilan untuk git commit --amend --no-edit --trailer=...Anda dapat langsung menentukan trailer yang diinginkan saat meluncurkan overrun.
Hal ini sangat menyederhanakan tugas-tugas berulang seperti memasukkan baris teks. Reviewed-by: atau anotasi yang mirip dengan serangkaian commit, sesuatu yang umum dalam proses tinjauan kode formal yang digunakan dalam tim yang tersebar.
Pengelolaan transportasi dan tanda tangan HTTP: perilaku yang lebih canggih.
Dari segi komunikasi jaringan, Git 2.54 memperkenalkan perubahan relevan dalam penanganan respons HTTP dan dalam interpretasi tanda tangan kriptografi yang terkait dengan commit dan tag.
Manajemen respons HTTP 429 dan percobaan ulang yang dapat dikonfigurasi.
Transport HTTP Git belajar untuk menginterpretasikan kode dengan benar. 429 «Terlalu Banyak Permintaan»Sampai sekarang, ketika server mengembalikan error 429, itu dianggap sebagai error fatal dan operasi gagal. Mulai versi ini, Git dapat mencoba kembali permintaan tersebut dengan tetap memperhatikan nilai header. Retry-After jika ada, atau menggunakan penundaan yang dapat dikonfigurasi melalui opsi baru http.retryAfter.
Penyesuaian juga ditambahkan http.maxRetries y http.maxRetryTime, yang memungkinkan mengontrol jumlah maksimum percobaan ulang dan total waktu yang dihabiskan untuk setiap percobaan ulang.Hal ini praktis di lingkungan perusahaan di mana akses diperlukan ke server yang kelebihan beban atau server dengan kebijakan pembatasan permintaan yang ketat, sehingga membantu menyederhanakan operasi. fetch y push Menjadi lebih tangguh tanpa menghukum server.
Menangani tanda tangan GPG dengan kunci yang kedaluwarsa
Terkait keamanan, perilaku yang berpotensi menyesatkan telah diperbaiki: ketika sebuah commit ditandatangani dengan kunci GPG yang kemudian kedaluwarsa, Git menampilkan tanda tangan tersebut di warna merah yang mengkhawatirkanHal ini menunjukkan bahwa tanda tangan tersebut tidak valid. Namun, jika tanda tangan tersebut valid pada saat itu, validitas tersebut seharusnya tetap berlaku meskipun kunci tersebut telah kedaluwarsa.
Git 2.54 menyesuaikan logika ini dan selanjutnya mempertimbangkan Tanda tangan yang dibuat dengan benar sebelum masa berlaku kunci berakhir adalah sah.Hal ini menghindari peringatan yang tidak perlu. Ini memberikan gambaran yang lebih akurat tentang riwayat repositori, yang relevan untuk proyek dengan siklus hidup yang panjang, seperti perangkat lunak institusional atau administrasi publik yang dipelihara selama bertahun-tahun.
Kemampuan inspeksi baru dan kustomisasi riwayat.
Beberapa perintah yang dirancang untuk menelusuri riwayat menerima peningkatan yang meningkatkan fleksibilitasnya dan memungkinkan keluaran yang lebih sesuai untuk setiap kasus.
`git log -L` terintegrasi dengan mekanisme diff standar.
pilihan git log -LFungsi yang memungkinkan pelacakan evolusi serangkaian baris dalam file tertentu telah diimplementasikan ulang untuk mengarahkan keluarannya melalui mekanisme perbedaan Git standarSebelumnya, ia menggunakan jalurnya sendiri, yang membuatnya tidak kompatibel dengan opsi yang sangat berguna seperti -S y -G (yang disebut "kapak"), atau dengan format tambalan yang berbeda.
Dengan perubahan yang diperkenalkan di Git 2.54, -L menjadi kompatibel dengan pencarian konten lanjutan dan format berbeda, termasuk --word-diff o --color-movedDengan cara ini, output dapat dibatasi pada fungsi tertentu dan, pada saat yang sama, difilter hanya untuk commit yang menambahkan atau menghapus simbol tertentu, yang mempermudah audit kode dan analisis regresi.
git blame dengan pemilihan algoritma diff
Perintah git blame, yang digunakan untuk melihat commit mana yang memperkenalkan setiap baris dalam sebuah file, mempelajari opsi baru. --diff-algorithmIni memungkinkan Anda untuk memilih di antara berbagai algoritma berbeda, seperti histogram, patience, atau minimal, saat menghitung atribusi garis.
Tergantung pada jenis perubahan yang telah dialami suatu file, Memilih satu algoritma dibandingkan algoritma lain dapat memberikan hasil yang lebih jelas.Hal ini mengurangi gangguan pada riwayat kode yang sangat aktif. Di lingkungan di mana tinjauan terperinci sangat dihargai, tingkat kontrol ini dapat membuat perbedaan besar ketika menyelidiki siapa yang memperkenalkan blok kode tertentu.
Optimasi penyimpanan dan basis data objek
Perubahan pada versi ini tidak hanya terbatas pada antarmuka pengguna; ada juga perbaikan signifikan pada cara kerja Git. mengatur dan mengakses data secara internalHal ini memiliki dampak yang sangat signifikan, terutama pada repositori berukuran besar.
Indeks multi-paket inkremental dan pemadatan
Panggilan indeks inkremental multi-paket (MIDX)Fitur-fitur yang sudah ditingkatkan di versi sebelumnya, Git 2.54 kini menyertakan dukungan untuk pemadatan lapisan (layer compaction). Mekanisme ini menggabungkan lapisan MIDX yang lebih kecil, beserta bitmap keterjangkauan (reachability bitmap) yang terkait, untuk menjaga ukuran rantai lapisan tetap wajar.
Langkah ini penting untuk Membuat MIDX inkremental menjadi praktis di repositori yang berumur panjang.seperti organisasi besar atau proyek komunitas dengan sejarah bertahun-tahun. Memadatkan lapisan mengurangi kompleksitas pencarian dan meningkatkan kinerja dalam operasi seperti fetch, clone Inspeksi sebagian atau inspeksi riwayat.
Restrukturisasi Basis Data Objek (ODB)
Secara internal, sebuah Refaktorisasi mendalam pada API basis data objek. (ODB). Sekarang digunakan desain backend yang dapat dipasang (pluggable backend), di mana fungsi-fungsi seperti read_object(), write_object() o for_each_object() Mereka dikirim menggunakan penunjuk fungsi berdasarkan asal.
Meskipun perubahan ini tidak langsung terlihat oleh pengguna akhir, perubahan ini meletakkan dasar bagi... backend penyimpanan alternatif di masa depan atau konfigurasi basis data objek yang lebih fleksibel. Bagi perusahaan dengan persyaratan kepatuhan peraturan khusus atau integrasi dengan sistem penyimpanan mereka sendiri, modularitas ini dapat membuka pintu bagi solusi yang lebih sesuai kebutuhan.
Peningkatan pada status, alias, pengisian data lama, dan detail lainnya.
Git 2.54 juga menyertakan sejumlah penyesuaian yang, meskipun kecil, berkontribusi pada penyempurnaan penggunaan sehari-hari dan adaptasi Git terhadap berbagai konteks linguistik dan jaringan.
git status dan perbandingannya dengan beberapa cabang jarak jauh
Perintah status git memperkenalkan opsi konfigurasi status.compareBranchesSecara default, perintah ini menunjukkan bagaimana cabang saat ini dibandingkan dengan upstream yang dikonfigurasi, sesuatu yang umum seperti origin/mainDengan opsi baru ini, Anda dapat meminta perbandingan dengan cabang push, atau dengan keduanya secara bersamaan.
Fungsi ini dirancang untuk aliran segitigaHal yang umum terjadi saat bekerja dengan fork: Anda dapat mengunduh dari remote resmi dan mengirimkan perubahan ke remote yang berbeda, dengan selalu menjaga kejelasan berapa banyak commit yang memisahkan setiap cabang, yang mengurangi kejutan saat menyinkronkan repositori.
Nama samaran dengan karakter internasional
Sampai sekarang, alias Git terbatas pada karakter alfanumerik ASCII dan tanda hubung, sehingga mencegah penggunaan nama dalam bahasa lain dengan aksen atau alfabet yang berbeda. Sintaks baru ini mendukung hampir semua karakter kecuali pemisah baris dan NUL. Pencocokan dilakukan sebagai byte mentah dan peka terhadap huruf besar dan kecil. Selain itu, sistem pelengkapan otomatis shell telah diperbarui untuk menangani alias ini, sehingga Git lebih mudah digunakan dalam tim multibahasa.
Git backfill lebih praktis pada kloning parsial.
Perintah eksperimental git backfillPerintah yang digunakan untuk mengunduh blob yang hilang dalam klon parsial juga sedang diperkuat. Sebelumnya, perintah tersebut selalu mengambil blob yang dapat dijangkau dari HEAD di seluruh struktur pohon, yang bisa menjadi berlebihan di repositori yang sangat besar.
Git 2.54 menambahkan dukungan untuk tinjau argumen dan pathspecsehingga pengisian data dapat dibatasi pada rentang sejarah tertentu (misalnya, main~100..main) atau ke rute-rute tertentu (git backfill -- '*.c'), termasuk pola wildcard. Hal ini membuat pekerjaan dengan klon parsial yang besar menjadi jauh lebih mudah, di mana Anda hanya perlu melengkapi riwayat bagian kode tertentu.
Penyesuaian dan peningkatan detail lainnya
Changelog Git 2.54 mencakup daftar panjang perbaikan kecil. Di antaranya adalah perbaikan untuk algoritma diff. histogramyang kini mencegah fase pemadatan memindahkan kelompok perubahan dengan cara yang merusak garis jangkar yang dipilih, menghasilkan perbedaan yang lebih bersih dan tidak berlebihan.
Alat-alat seperti git config list , yang semakin mapan sebagai cara resmi untuk mencantumkan konfigurasi, git merge-file yang kemudian menghormati konfigurasi yang tersedia bahkan di luar repositori, dan beberapa utilitas terkait. git send-emailyang memberikan dukungan untuk sertifikat klien dan penanganan yang lebih hati-hati terhadap kumpulan karakter yang dipilih pengguna.
Evolusi Git terus berlanjut dengan kecepatan yang baik pada versi 2.54, yang menggabungkan peningkatan yang terlihat bagi pengguna, seperti tatanan baru git history atau hook yang dapat dikonfigurasi, yang membutuhkan pekerjaan signifikan pada infrastruktur internal sistem. Semua ini mengarah pada ekosistem yang lebih kuat dan fleksibel, lebih siap menghadapi tantangan repositori yang semakin besar dan tim yang lebih beragam.
