Salah satu fitur utama Git adalah kemampuan untuk membuat beberapa versi proyek Anda. Seringkali, mereka digunakan untuk garpu jangka pendek yang disebut “cabang fitur”, yang digabungkan menjadi master. Namun, terkadang perlu untuk memiliki cabang yang benar-benar terpisah, yang membuatnya sulit untuk tetap sinkron.
Mengapa Mempertahankan Cabang Berbeda?
Biasanya, cabang berumur pendek, dan dimaksudkan untuk digabungkan kembali ke cabang rilis utama. Namun, dalam beberapa kasus, perlu untuk mempertahankan cabang yang benar-benar terpisah. Misalnya, Anda mungkin memiliki cabang yang menargetkan platform atau dependensi yang berbeda, dengan fitur yang berbeda, atau cabang rilis terpisah yang Anda tetap hidup untuk sementara waktu.
Ini adalah alur kerja yang sama di sebagian besar fork, dan bergantung pada volume dan tingkat keparahan perubahan, mungkin sulit untuk tetap sinkron di upstream. Jika dua cabang Anda sebagian besar sinkron dikurangi beberapa komit, Anda akan lebih mudah menangani konflik dan memperbarui semuanya.
Namun, dalam banyak kasus, Anda harus mencari alternatif untuk memisahkan cabang, karena ini bisa membosankan, terutama dengan penggabungan dan semua tes tambahan. Misalnya, jika Anda memiliki dua build yang menargetkan platform berbeda, banyak bahasa memiliki konfigurasi build dan praprosesor yang dapat menanganinya. C# memiliki #if NETVERSIONyang memungkinkan perubahan pada kode berdasarkan pada platform mana kode itu dikompilasi.
Apa pun alasan Anda, ini adalah alur kerja Git yang valid yang digunakan banyak orang.
Menjaga Cabang Disinkronkan Dengan Rebasing
Pada dasarnya ada dua opsi untuk melakukan ini. Metode pertama dan paling umum adalah rebasing, yang mirip dengan penggabungan, tetapi memungkinkan cabang untuk sepenuhnya independen.
Anda dapat menganggap komit Git seperti rantai perubahan yang kembali ke masa lalu, masing-masing menunjuk ke komit sebelumnya. Saat Anda membuat cabang baru, itu akan pecah dari yang utama master bercabang pada titik tertentu, basis dari cabang.
Rebasing biasanya meningkatkan keseluruhan feature cabang, dan memindahkannya ke titik waktu baru, di mana ujungnya menunjuk ke rantai komit lain. Ini paling berguna jika cabang bercabang hanya berisi beberapa komit, karena konflik gabungan akan lebih mudah diperbaiki. Dalam contoh ini, rebasing cabang ini mencakup komit B dan C, tetapi bukan D dan E, karena tidak perlu melakukan rebase di HEAD cabang.
Rebasing umumnya hanya digunakan untuk cabang lokal, dan menimbulkan beberapa masalah saat digunakan pada cabang bersama. Komit tidak benar-benar bergerak; mereka disalin, menghasilkan ID komit baru, dengan KEPALA cabang dipindahkan ke lokasi baru.
Ini berarti bahwa komit lama dibiarkan terdampar. Karena Git adalah sistem kontrol versi terdesentralisasi, rekan kerja Anda dapat memiliki komit un-Push yang merujuk pada komit yang dihapus. Rebasing harus menjadi sesuatu yang Anda komunikasikan dengan kolaborator mana pun, dan jika ada yang memiliki konflik, mereka harus memperbaikinya secara lokal dengan menyalin perubahan tersebut ke lokasi yang benar.
Rebasing cabang relatif mudah. Anda harus checkout feature cabang, tarik semua perubahan dari remote Anda, lalu jalankan rebase <branch> untuk memindahkan feature cabang ke cabang sasaran.
git checkout feature git pull git rebase master
Ini kemungkinan akan menghasilkan penggabungan konflik, yang perlu Anda selesaikan sendiri dan kemudian buat perubahannya.
Meskipun sebagian besar tugas Git sehari-hari dapat dengan mudah dilakukan dari baris perintah, rebasing secara inheren merupakan operasi visual yang cantik, jadi sebaiknya gunakan klien GUI Git seperti Fork atau GitKraken jika Anda bisa. Ini akan menunjukkan kepada Anda garis cabang dan membantu Anda merencanakan rebase lebih efektif, dan bahkan dapat melakukan rebase interaktif.
Karena rebasing pada dasarnya menerapkan setiap komit dari cabang fitur ke lokasi baru, Anda tidak perlu menyertakan semuanya, dan rebasing interaktif dapat menghapus komit yang tidak Anda perlukan. Itu mungkin dilakukan dari baris perintah, tetapi lebih masuk akal dari GUI.
Memperbaiki Komitmen yang Tidak Diinginkan
Apa yang terjadi jika Anda tidak ingin memasukkan beberapa komit saat Anda melakukan rebase? Jika Anda memiliki komit di feature cabang yang ingin Anda kecualikan saat melakukan rebasing master, maka Anda dapat melakukan rebase interaktif. Ini akan menghapus komit yang tidak diinginkan saat rebasing, secara efektif menghapusnya dari riwayat.
Tapi, kemungkinan besar ada komitmen untuk master cabang yang tidak ingin Anda miliki di cabang Anda feature cabang Karena rebasing menetapkan basis cabang baru untuk dikuasai, tidak ada cara untuk mengecualikan komit tersebut.
Jika hanya ada satu atau dua komit yang tidak ingin Anda miliki, Anda masih dapat melakukan rebase, dan memperbaikinya dengan konflik penggabungan, perbaiki secara manual, atau cukup kembalikan komit. Git memiliki perintah “kembalikan” yang akan menerapkan perubahan terbalik, pada dasarnya membalikkan komit dan membuatnya tampak seperti tidak pernah terjadi. Untuk menggunakannya, jalankan git log untuk menemukan komit yang ingin Anda kembalikan:
Kemudian, salin hash SHA1 dan kembalikan komit:
git revert 62ee517cc7c358eafbbffdebdde1b38dea92aa0f
Ini akan melakukan “kembalikan komit” ke feature cabang
Memetik Ceri Berkomitmen di Cabang Lain
Skenario terakhir yang dapat Anda hadapi adalah jika hanya ada sedikit komit master yang ingin kamu pakai feature. Ini biasa terjadi jika Anda memelihara cabang untuk versi yang berbeda, karena sering kali ada perbaikan terbaru dan tambalan yang perlu diterapkan ke versi perangkat lunak yang lebih lama.
Ini adalah cara yang paling menjengkelkan untuk menyinkronkan sesuatu, karena jika Anda tidak menjaga cabang Anda tetap sinkron, ada kemungkinan besar bahwa komit yang ingin Anda sertakan mungkin tidak kompatibel dengan cabang yang lebih lama.
Tapi, Git memiliki alat untuk menyalin dan menempelkan komit ke cabang lain. Tindakan ini disebut cherry-picking, karena Anda mengambil satu komit dalam sejarah dan menariknya keluar. Seperti rebasing, cherry-picking membuat komit yang baru disalin, tetapi Git biasanya cukup pintar untuk memperbaikinya, bahkan jika Anda menggabungkan cabang nanti.
Untuk memilih cherry, Anda harus mendapatkan ID komit. Jika riwayat cabang Anda rumit, Anda dapat menjalankan git log dengan --graph opsi untuk mendapatkan representasi visual dari riwayat Anda, meskipun klien GUI sangat berguna untuk tugas-tugas seperti ini.
git log --pretty=format:"%h %s" --graph
Kemudian, pastikan Anda aktif feature cabang, dan lari cherry-pick dengan ID komit untuk menyalinnya.
git checkout feature git cherry-pick 1da76d3
Hal ini dapat mengakibatkan konflik, yang harus Anda selesaikan.