Git rebase: Semua yang Perlu Anda Ketahui

Perintah Git rebase menggabungkan dua cabang kode sumber menjadi satu. Perintah merge Git juga melakukan itu. Kami menjelaskan apa yang dilakukan rebase , bagaimana penggunaannya, dan kapan harus menggunakan merge .

Ledakan Git

Frustrasi dengan sistem kontrol versi lain dan pembaruan serta komitmennya yang lambat, Linus Torvalds, dari ketenaran kernel Linux, menyisihkan satu bulan di tahun 2005 untuk menulis sendiri. Dia menamakannya Git.

Situs seperti GitHub, GitLab, dan BitBucket telah mempromosikan dan memanfaatkan Git secara simbiosis. Saat ini Git digunakan secara global, dengan 98 persen dari 71 ribu responden dalam survei tahun 2022 menggunakan Git sebagai sistem kontrol versi.

Salah satu keputusan desain utama Git adalah kecepatan. Secara khusus, bekerja dengan cabang harus secepat mungkin. Cabang adalah bagian mendasar dari sistem kontrol versi. Repositori proyek akan memiliki cabang utama atau master. Di sinilah basis kode proyek berada. Pengembangan, seperti fitur baru, berlangsung di cabang samping yang terpisah. Ini menghentikan pekerjaan yang dilakukan di cabang dari mengacaukan cabang master, dan memungkinkan pengembangan simultan terjadi di berbagai bagian basis kode.

TERKAIT Cara Memilih Alur Kerja Git & Model Percabangan yang Tepat untuk Tim Anda

Saat pengembangan di cabang samping selesai, perubahan dipindahkan ke cabang master dengan menggabungkan cabang pengembangan ke cabang master. Di sistem kontrol versi lain yang bekerja dengan cabang sulit dan mahal secara komputasi. Bekerja dengan cabang di Git sangat cepat, dan sangat ringan. Apa yang dulunya merupakan latihan yang membosankan dan sering dihindari di sistem lain, menjadi sepele di Git.

Perintah Git rebase adalah cara lain untuk mentransfer perubahan dari satu cabang ke cabang lain. Perintah merge dan rebase memiliki tujuan yang serupa, tetapi mereka mencapai tujuannya dengan cara yang berbeda dan menghasilkan hasil yang sedikit berbeda.

Apa itu gabungan Git?

Jadi untuk apa perintah merge Git? Katakanlah Anda telah membuat cabang bernama dev-branch untuk mengerjakan fitur baru.

Anda membuat beberapa komitmen, dan menguji fitur baru Anda. Semuanya bekerja dengan baik. Sekarang Anda ingin mengirimkan fitur baru Anda ke cabang master . Anda harus berada di cabang master untuk menggabungkan yang lain dengannya.

Kami dapat memastikan kami berada di cabang master dengan memeriksanya secara eksplisit sebelum kami bergabung.

 master checkout git

Kami sekarang dapat memberi tahu Git untuk menggabungkan dev-branch saat ini, yang merupakan cabang master .

 git menggabungkan cabang dev 

merge kami selesai untuk kami. Jika Anda memeriksa cabang master dan mengompilasinya, itu akan memiliki fitur yang baru dikembangkan di dalamnya. Apa yang sebenarnya dilakukan Git adalah penggabungan tiga arah. itu membandingkan komit terbaru di cabang master dan dev-branch , dan komit di cabang master segera sebelum dev-branch dibuat. Itu kemudian melakukan komit pada cabang master .

Penggabungan dianggap tidak merusak karena tidak menghapus apa pun dan tidak mengubah riwayat Git apa pun. Cabang dev-branch masih ada, dan tidak ada komit sebelumnya yang diubah. Komit baru dibuat yang menangkap hasil penggabungan tiga arah.

Setelah penggabungan, repositori Git kita terlihat seperti garis waktu dengan garis alternatif bercabang dan kemudian kembali ke garis waktu utama.

Cabang dev-branch telah dimasukkan ke dalam cabang master .

Jika Anda memiliki banyak cabang dalam satu proyek, riwayat proyek dapat menjadi membingungkan. Ini sering terjadi jika sebuah proyek memiliki banyak kontributor. Karena upaya pengembangan terbagi menjadi banyak jalur yang berbeda, riwayat pengembangan menjadi non-linier. Mengurai riwayat komit menjadi lebih sulit jika cabang memiliki cabangnya sendiri.

TERKAIT Bagaimana Cara Kerja Cabang Git?

Perhatikan bahwa jika Anda memiliki perubahan yang tidak dikomit di cabang master , Anda harus melakukan sesuatu dengan perubahan ini sebelum Anda dapat menggabungkan apa pun ke dalamnya. Anda bisa membuat cabang baru dan melakukan perubahan di sana, lalu melakukan penggabungan. Anda kemudian perlu menggabungkan cabang sementara Anda kembali ke cabang master.

Itu berhasil, tetapi Git memiliki perintah yang mencapai hal yang sama, tanpa harus membuat cabang baru. Perintah stash menyimpan perubahan yang belum dikomit untuk Anda, dan memungkinkan Anda memanggilnya kembali dengan stash pop .

Anda akan menggunakannya seperti ini:

 menyimpan

git menggabungkan cabang dev

simpanan pop

Hasil akhirnya adalah cabang gabungan, dengan perubahan yang belum disimpan dipulihkan.

Apa itu rebase Git?

Perintah Git rebase mencapai tujuannya dengan cara yang sama sekali berbeda. Dibutuhkan semua komit dari cabang yang akan Anda rebase dan memutarnya kembali ke ujung cabang tempat Anda melakukan rebase.

Mengambil contoh kami sebelumnya, sebelum kami melakukan tindakan apa pun, repositori Git kami terlihat seperti ini. Kami memiliki cabang bernama dev-branch dan kami ingin memindahkan perubahan tersebut ke cabang master .

Setelah rebase , sepertinya satu garis waktu perubahan yang sepenuhnya linier.

Cabang dev-branch telah dihapus, dan komit di dev-branch telah ditambahkan ke cabang master. Hasil akhirnya sama seperti jika komit di dev-branch sebenarnya telah langsung dikomit ke cabang master . Komit tidak hanya ditempelkan ke cabang master , tetapi juga "diputar ulang" dan ditambahkan segar.

Inilah mengapa perintah rebase dianggap merusak. Cabang yang diubah basisnya tidak lagi ada sebagai cabang terpisah, dan riwayat Git proyek Anda telah ditulis ulang. Anda tidak dapat menentukan di beberapa titik selanjutnya komit mana yang awalnya dibuat untuk dev-branch .

Namun, itu meninggalkan Anda dengan sejarah yang disederhanakan, linier. Dibandingkan dengan repositori dengan lusinan atau bahkan ratusan cabang dan penggabungan, membaca log Git atau menggunakan GUI grafis git untuk melihat grafik repositori, repositori yang dibuat ulang sangat mudah untuk dipahami.

Cara Rebase Ke Cabang Lain

Mari kita coba contoh git rebase . Kami punya proyek dengan cabang bernama new-feature . Kami akan mengubah rebase itu menjadi cabang master seperti ini.

Pertama, kami memeriksa bahwa cabang master tidak memiliki perubahan yang luar biasa.

 status git

Kami memeriksa cabang new-feature .

 git checkout fitur baru

Kami memberi tahu rebase untuk mengubah basis cabang saat ini ke cabang master.

 git rebase master

Kita dapat melihat bahwa kita masih memiliki dua cabang.

 cabang git

Kami bertukar kembali ke cabang master

 master checkout git

Kami menggabungkan cabang fitur baru ke cabang saat ini, yang dalam kasus kami adalah cabang master .

 git menggabungkan fitur baru 

Menariknya, kami masih memiliki dua cabang setelah penggabungan terakhir.

Perbedaannya adalah, sekarang kepala cabang new-feature dan kepala cabang master diatur untuk menunjuk ke komit yang sama, dan sejarah Git tidak menunjukkan dulu ada cabang new-feature terpisah, selain dari label cabang.

Git Rebase vs. Merge: Yang Mana Yang Harus Anda Gunakan?

Ini bukan kasus rebase vs. merge . Keduanya adalah perintah yang kuat dan Anda mungkin akan menggunakan keduanya. Yang mengatakan, ada kasus penggunaan di mana rebase tidak berfungsi dengan baik. Kesalahan unpicking yang disebabkan oleh kesalahan menggunakan merge memang tidak menyenangkan, tetapi unpicking error yang disebabkan oleh rebase adalah neraka.

Jika Anda adalah satu-satunya pengembang yang menggunakan repositori, kecil kemungkinan Anda melakukan sesuatu dengan rebase yang membawa malapetaka. Anda masih bisa melakukan rebase ke arah yang salah misalnya, dan rebase cabang master Anda ke cabang new-feature Anda. Untuk mendapatkan kembali cabang master Anda, Anda perlu melakukan rebase lagi, kali ini dari cabang new-feature ke cabang master Anda. Itu akan memulihkan cabang master Anda, meskipun dengan riwayat yang tampak aneh.

Jangan gunakan rebase pada cabang bersama tempat orang lain cenderung bekerja. Perubahan Anda pada repositori Anda akan menyebabkan masalah bagi banyak orang saat Anda memasukkan kode rebased Anda ke repositori jarak jauh Anda.

Jika proyek Anda memiliki banyak kontributor, hal yang aman untuk dilakukan hanyalah menggunakan rebase di repositori lokal Anda, bukan di cabang publik. Demikian pula, jika permintaan penarikan merupakan bagian dari tinjauan kode Anda, jangan gunakan rebase . Atau setidaknya, jangan gunakan rebase setelah membuat pull request. Pengembang lain cenderung melihat komit Anda, yang berarti bahwa perubahan itu ada di cabang publik, meskipun tidak di cabang master .

Bahayanya adalah Anda akan melakukan rebase komit yang telah didorong ke repositori jarak jauh, dan pengembang lain mungkin sudah mendasarkan pekerjaan pada komit tersebut. rebase lokal Anda akan membuat komitmen yang ada menghilang. Jika Anda mendorong perubahan itu ke repositori, Anda tidak akan populer.

TERKAIT Cara Memperbaiki, Mengedit, atau Membatalkan Komitmen Git (Mengubah Riwayat Git)

Kontributor lain harus melalui merge yang berantakan agar pekerjaan mereka didorong kembali ke repositori. Jika Anda kemudian menarik perubahan mereka kembali ke repositori lokal Anda, Anda kemudian dihadapkan pada penghapusan perubahan duplikat yang berantakan.

Untuk Rebase, atau Tidak Rebase?

Rebase mungkin dilarang dalam proyek Anda. Mungkin ada keberatan lokal dan budaya. Beberapa proyek atau organisasi menganggap rebase sebagai bentuk bid'ah, dan tindakan penodaan. Beberapa orang percaya sejarah Git harus menjadi catatan permanen yang tidak dapat diganggu gugat tentang apa yang telah terjadi. Jadi, rebase mungkin tidak dapat dilakukan.

Tapi, digunakan secara lokal, di cabang pribadi, rebase adalah alat yang berguna.

Dorong setelah Anda melakukan rebase, dan batasi ke cabang tempat Anda satu-satunya pengembang. Atau setidaknya, di mana semua pengembangan telah berhenti, dan tidak ada orang lain yang mendasarkan pekerjaan lain dari komitmen cabang Anda.

Lakukan itu dan Anda akan terhindar dari masalah apa pun.

TERKAIT: Cara Memeriksa dan Memperbarui Versi Git Anda