Perintah Git rebase memindahkan cabang ke lokasi baru di kepala cabang lain. Tidak seperti perintah gabungan Git, rebase melibatkan penulisan ulang riwayat proyek Anda. Ini adalah alat yang hebat, tetapi jangan rebase melakukan pekerjaan yang didasarkan pada pengembang lain. Perintah rebase Git menggabungkan dua cabang kode sumber menjadi satu. Perintah penggabungan Git juga melakukan itu. Kami menjelaskan apa yang dilakukan rebase, bagaimana penggunaannya, dan kapan sebaiknya menggunakan penggabungan. . Dia menamainya Git. Situs seperti GitHub, GitLab, dan BitBucket telah secara simbiosis mempromosikan dan mendapat manfaat dari Git. Hari 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 ini memungkinkan pengembangan simultan terjadi di berbagai bagian basis kode. cabang selesai, perubahan ditransfer 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 rebase Git adalah cara lain untuk mentransfer perubahan dari satu cabang ke cabang lain. Perintah penggabungan dan rebase memiliki tujuan yang serupa, tetapi mereka mencapai tujuan mereka dengan cara yang berbeda dan menghasilkan hasil yang sedikit berbeda.

Apa itu penggabungan Git?

Jadi untuk apa perintah penggabungan 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 ke dalamnya. Kita dapat memastikan bahwa kita berada di cabang master dengan memeriksanya secara eksplisit sebelum kita menggabungkan. git checkout master Kita sekarang dapat memberi tahu Git untuk menggabungkan cabang dev ke dalam cabang saat ini, yang merupakan master branch. git gabungan dev-branch Penggabungan kami selesai untuk kami. Jika Anda checkout 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 cabang dev, dan komit di cabang master segera sebelum cabang dev dibuat. Itu kemudian melakukan komit pada master branch. Merges dianggap tidak merusak karena tidak menghapus apa pun dan tidak mengubah riwayat Git apa pun. Cabang dev 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. The dev- branch branch telah dimasukkan ke dalam master branch. 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 sejarah komit menjadi lebih sulit jika cabang memiliki cabang sendiri. . Anda bisa membuat cabang baru dan melakukan perubahan di sana, lalu melakukan penggabungan. Anda kemudian perlu menggabungkan cabang sementara Anda kembali ke cabang master. Nbsp Itu berfungsi, 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: stash git merge dev-branch stash pop Hasil akhirnya adalah cabang gabungan, dengan perubahan yang belum disimpan dipulihkan.

Apakah Git rebase?

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 rebasing. Mengambil contoh kami sebelumnya, sebelum kami melakukan tindakan apa pun, repositori Git kami terlihat seperti ini. Kami memiliki cabang yang disebut dev-branch dan kami ingin memindahkan perubahan itu ke cabang master. Setelah rebase , sepertinya garis waktu perubahan tunggal yang sepenuhnya linier. The dev-branch telah dihapus, dan commit di dev-branch telah ditambahkan ke master branch. Hasil akhirnya sama seperti jika komit di cabang dev sebenarnya telah langsung dikomit ke cabang master. Komit tidak hanya ditempelkan ke cabang master, tetapi juga "diputar ulang" dan ditambahkan fresh. 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 riwayat yang disederhanakan, linier. Dibandingkan dengan repositori dengan lusinan atau bahkan ratusan cabang dan penggabungan, membaca log Git atau menggunakan grafis git GUI untuk melihat grafik repositori, repositori yang direvisi sangat mudah dipahami. contoh git rebase. Kami punya proyek dengan cabang bernama fitur baru. Kami akan mengubah basis cabang itu ke cabang master seperti ini. Pertama, kami memeriksa bahwa cabang master tidak memiliki perubahan yang luar biasa. git status Kami memeriksa cabang fitur baru. git memeriksa fitur barubspKami memberi tahu Git untuk mengubah basis cabang saat ini ke master branch. git rebase master Kita dapat melihat bahwa kita masih memiliki dua cabang. git branch Kami menukar kembali ke master branch git checkout master Kami menggabungkan cabang fitur baru ke dalam cabang saat ini, yang dalam kasus kami adalah cabang master. git menggabungkan fitur baruDave McKay/How-To Geek Menariknya, kami masih memiliki dua cabang setelah penggabungan terakhir. Perbedaannya adalah, sekarang kepala cabang fitur baru dan kepala cabang master ditetapkan untuk menunjuk ke komit yang sama, dan riwayat Git tidak menunjukkan bahwa dulu ada cabang fitur baru yang terpisah, selain dari cabang label.

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

Tidak kasus rebase vs. penggabungan. Keduanya adalah perintah yang kuat dan Anda mungkin akan menggunakan keduanya. Yang mengatakan, ada kasus penggunaan di mana rebase tidak bekerja dengan baik. Menghapus kesalahan yang disebabkan oleh kesalahan menggunakan penggabungan tidak menyenangkan, tetapi menghapus kesalahan yang disebabkan oleh rebase adalah hal yang mengerikan. Jika Anda satu-satunya pengembang yang menggunakan repositori, kecil kemungkinan Anda melakukan sesuatu dengan rebase yang membawa bencana. Anda masih bisa melakukan rebase ke arah yang salah misalnya, dan rebase cabang master Anda ke cabang fitur baru Anda. Untuk mendapatkan kembali cabang master Anda, Anda perlu melakukan rebase lagi, kali ini dari cabang fitur baru ke cabang master Anda. Itu akan mengembalikan cabang master Anda, meskipun dengan riwayat yang tampak aneh. Jangan gunakan rebase pada cabang bersama di mana orang lain cenderung bekerja. Perubahan Anda pada repositori Anda akan menyebabkan masalah bagi banyak orang ketika Anda mendorong kode rebased Anda ke repositori jarak jauh Anda. Jika proyek Anda memiliki banyak kontributor, hal yang aman untuk dilakukan adalah hanya menggunakan rebase pada repositori lokal Anda, dan bukan pada 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 kemungkinan akan melihat komit Anda, yang berarti bahwa perubahan itu ada di cabang publik, meskipun tidak di cabang master. Nbsp Bahayanya adalah Anda akan mengubah ulang komit yang telah didorong ke repositori jarak jauh, dan pengembang lain mungkin sudah mendasarkan pekerjaan pada komitmen tersebut. Rebase lokal Anda akan membuat komitmen yang ada menghilang. Jika Anda mendorong perubahan tersebut ke repositori, Anda tidak akan populer. gudang. Jika Anda kemudian menarik perubahan mereka kembali ke repositori lokal Anda, Anda kemudian dihadapkan dengan unpicking kekacauan duplikat perubahan.

To Rebase, or Not to 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 di luar tabel. Tapi, digunakan secara lokal, di cabang pribadi, rebase adalah alat yang berguna. Push setelah Anda melakukan rebase, dan batasi ke cabang di mana Anda adalah satu-satunya pengembang. Atau setidaknya, di mana semua pengembangan telah berhenti, dan tidak ada orang lain yang mendasarkan pekerjaan lain dari komitmen cabang Anda. Nbsp Lakukan itu dan Anda akan terhindar dari masalah apa pun. Disadur dari HowToGeek.com.