Seringkali, pengembang memiliki pilihan antara Gabung (gabung) dan Rebase (relokasi). Di Google Anda akan melihat pendapat yang berbeda, banyak yang disarankan untuk tidak menggunakan Rebase, karena ini dapat menyebabkan masalah serius. Dalam artikel ini, saya akan menjelaskan apa itu penggabungan dan pemindahan, mengapa Anda harus (atau tidak seharusnya) menggunakannya, dan bagaimana melakukannya.
Git Merge dan Git Rebase berbagi tujuan yang sama. Mereka dirancang untuk mengintegrasikan perubahan dari satu cabang ke cabang lainnya. Meskipun tujuan akhirnya sama, prinsip-prinsip operasi berbeda.
Beberapa orang berpikir Anda harus selalu menggunakan Rebase, yang lain lebih suka Penggabungan. Ini memiliki pro dan kontra.
Git bergabung
Penggabungan adalah praktik umum bagi pengembang yang menggunakan sistem kontrol versi. Terlepas dari apakah cabang dibuat untuk pengujian, memperbaiki bug, atau karena alasan lain, penggabungan menangkap perubahan di tempat lain. Penggabungan mengambil konten dari cabang sumber dan menggabungkannya dengan cabang target. Dalam proses ini, hanya cabang target yang diubah. Sejarah cabang sumber tetap tidak berubah.
Pro:- kesederhanaan;
- menjaga sejarah penuh dan tatanan kronologis;
- memelihara konteks cabang.
Cons:- sejarah komit dapat diisi (tercemar) dengan banyak komit;
- debugging menggunakan git bisect bisa menjadi lebih rumit.
Bagaimana cara melakukannyaGabungkan cabang master ke cabang fitur menggunakan perintah
checkout dan
gabung .
$ git checkout feature $ git merge master (or) $ git merge master feature
Ini akan membuat "Gabung komit" baru di cabang fitur, yang berisi riwayat kedua cabang.
Git rebase
Rebase adalah cara lain untuk mendorong perubahan dari satu cabang ke cabang lainnya. Rebase mengkompres semua perubahan menjadi satu tambalan. Kemudian mengintegrasikan patch ke cabang target.
Tidak seperti penggabungan, memindahkan menimpa riwayat karena transfer menyelesaikan pekerjaan dari satu cabang ke cabang lainnya. Proses menghilangkan cerita yang tidak diinginkan.
Pro:- Menyederhanakan kisah yang berpotensi rumit
- Penyederhanaan manipulasi dengan komit tunggal
- Menghindari penggabungan komitmen dalam repositori dan cabang yang sibuk
- Membersihkan komit antara, menjadikannya komit tunggal, yang berguna untuk perintah DevOps
Cons:- Mengompres fitur ke beberapa commit dapat menyembunyikan konteksnya
- Memindahkan repositori publik dapat berbahaya saat bekerja dalam tim
- Lebih banyak pekerjaan muncul
- Untuk pemulihan dengan cabang yang dihapus, diperlukan dorongan. Ini mengarah pada pembaruan semua cabang yang memiliki nama yang sama, baik lokal maupun jarak jauh, dan ini mengerikan.
Jika Anda melakukan langkah yang salah, ceritanya akan berubah, dan ini dapat menyebabkan masalah serius, jadi pastikan Anda melakukannya!
Bagaimana cara melakukannyaPindahkan cabang fitur ke cabang utama menggunakan perintah berikut.
$ git checkout feature $ git rebase master
Ini memindahkan seluruh cabang fungsi ke cabang utama. Sejarah proyek berubah, komit baru dibuat untuk setiap komit di cabang utama.
Gerakan interaktif
Ini memungkinkan Anda untuk mengubah komit ketika dipindahkan ke cabang baru. Ini lebih baik daripada pemindahan otomatis karena memberikan kontrol penuh atas riwayat commit. Biasanya digunakan untuk menghapus riwayat sebelum menggabungkan cabang fitur ke master.
$ git checkout feature $ git rebase -i master
Ini akan membuka editor, mendaftar semua komit yang akan dipindahkan.
pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3
Ini menentukan dengan tepat seperti apa cabang itu setelah pindah. Dengan mengatur objek, Anda dapat membuat cerita seperti yang Anda inginkan. Anda dapat menggunakan perintah
fixup ,
squash ,
edit , dan sebagainya.
Yang mana yang akan digunakan?
Jadi apa yang lebih baik? Apa yang para ahli rekomendasikan?Sulit untuk membuat satu-satunya keputusan yang tepat tentang mana yang lebih baik untuk digunakan, karena semua tim berbeda. Itu semua tergantung pada kebutuhan dan tradisi di dalam tim.
Buat keputusan berdasarkan kompetensi tim di Git. Apakah kesederhanaan atau penulisan ulang sejarah penting bagi Anda, atau mungkin sesuatu yang lain?
Apa yang saya rekomendasikan?Seiring pertumbuhan tim, menjadi sulit untuk mengelola atau melacak perubahan pengembangan menggunakan merger. Untuk memiliki riwayat komit yang bersih dan dapat dipahami, sebaiknya gunakan Rebase.
Manfaat Rebase:- Anda berkembang secara lokal: jika Anda belum membagikan pekerjaan Anda dengan orang lain. Untuk saat ini, Anda sebaiknya memilih menggabungkan penggabungan agar cerita Anda tetap teratur. Jika Anda memiliki garpu repositori pribadi yang tidak dibagikan dengan pengembang lain, Anda dapat rebase bahkan setelah pindah ke cabang Anda.
- Kode Anda siap ditinjau: Anda telah membuat permintaan tarik. Orang lain menganalisis pekerjaan Anda dan berpotensi menariknya ke colokan mereka untuk tinjauan lokal. Saat ini, Anda tidak boleh memindahkan pekerjaan Anda. Anda harus membuat "redo" komit dan memperbarui cabang. Ini membantu melacak permintaan untuk menarik permintaan dan mencegah pemecahan cerita yang tidak disengaja.
- Tinjauan selesai dan siap untuk diintegrasikan ke cabang target. Selamat! Anda akan menghapus cabang fitur Anda. Karena mulai sekarang, pengembang lain tidak akan menggabungkan perubahan ini, ini adalah kesempatan Anda untuk mengubah cerita Anda. Pada titik ini, Anda dapat menulis ulang riwayat dan mengatur ulang komit asli, dan "perubahan" dan "penggabungan" yang mengganggu ini bergabung menjadi sekumpulan kecil komit yang ditargetkan. Membuat gabungan eksplisit untuk komit ini adalah opsional, tetapi itu penting. Ini merekam ketika fungsi telah mencapai master.
Sekarang Anda tahu, meskipun tidak signifikan, tetapi perbedaan antara Merge dan Rebase. Saya yakin Anda akan membuat keputusan yang tepat dan akan menggunakan apa yang tepat untuk Anda.
Jangan lupa: code = coffee + developer