Pertanyaan Kapan Anda menggunakan git rebase daripada git bergabung?


Kapan direkomendasikan untuk digunakan git rebase vs. git merge?

Apakah saya masih perlu menggabungkan setelah sukses melakukan rebase?


1246
2018-04-29 20:26


asal


Jawaban:


Versi pendek

  • Gabung mengambil semua perubahan dalam satu cabang dan menggabungkannya ke cabang lain dalam satu commit.
  • Rebase mengatakan saya ingin titik di mana saya bercabang untuk pindah ke titik awal yang baru

Jadi kapan kamu menggunakan salah satunya?

Menggabungkan

  • Katakanlah Anda telah membuat cabang untuk tujuan mengembangkan satu fitur. Ketika Anda ingin mengembalikan perubahan itu ke master, Anda mungkin menginginkannya menggabungkan (Anda tidak peduli tentang menjaga semua komitmen sementara).

Rebase

  • Skenario kedua adalah jika Anda mulai melakukan pengembangan dan kemudian pengembang lain membuat perubahan yang tidak terkait. Anda mungkin ingin menarik dan kemudian rebase untuk mendasari perubahan Anda dari versi saat ini dari repo.

973
2018-04-29 20:38



Ini sederhana, dengan rebase Anda katakan untuk menggunakan cabang lain sebagai yang baru mendasarkan untuk pekerjaanmu.

Jika Anda memiliki misalnya cabang master dan Anda membuat cabang untuk menerapkan fitur baru, katakanlah Anda beri nama cool-feature, tentu saja cabang master adalah basis untuk fitur baru Anda.

Sekarang pada titik tertentu Anda ingin menambahkan fitur baru yang Anda terapkan dalam master cabang. Anda hanya bisa beralih ke master dan menggabungkan cool-feature cabang:

$git checkout master
$git merge cool-feature

tetapi dengan cara ini komit boneka baru ditambahkan, jika Anda ingin menghindari spaghetti-history Anda bisa rebase:

$git checkout cool-feature
$git rebase master

lalu menggabungkannya master:

$git checkout master
$git merge cool-feature

Kali ini, karena cabang topik memiliki komitmen master yang sama ditambah komit dengan fitur baru, penggabungan akan menjadi cepat maju.


288
2018-02-05 06:28



Untuk melengkapi jawaban saya sendiri tersebut oleh TSamper,

  • rebase sering kali merupakan ide bagus untuk dilakukan sebelum penggabungan, karena idenya adalah Anda mengintegrasikannya di cabang Anda Y pekerjaan kantor cabang B di mana Anda akan bergabung.
    Tetapi sekali lagi, sebelum bergabung, Anda menyelesaikan semua konflik anda cabang (yaitu: "rebase", seperti dalam "memutar ulang pekerjaan saya di cabang saya mulai dari titik baru dari cabang B)
    Jika dilakukan dengan benar, penggabungan berikutnya dari cabang Anda ke cabang B bisa maju cepat.

  • dampak gabungan langsung cabang tujuan B, yang berarti penggabungan lebih baik sepele, jika tidak cabang itu B bisa lama untuk kembali ke keadaan stabil (waktu untuk Anda menyelesaikan semua konflik)


titik penggabungan setelah rebase?

Dalam hal yang saya jelaskan, saya rebase B ke cabang saya, hanya untuk memiliki kesempatan untuk memutar ulang karya saya dari titik yang lebih baru dari B, tetapi saat tinggal di cabang saya.
Dalam hal ini, penggabungan masih diperlukan untuk membawa karya saya yang "dimainkan ulang" B.

Skenario lainnya (dijelaskan dalam Git Ready misalnya), adalah untuk membawa pekerjaan Anda langsung masuk B melalui rebase (yang menghemat semua komitmen baik Anda, atau bahkan memberi Anda kesempatan untuk mengatur ulang mereka melalui rebase interaktif).
Dalam hal ini (di mana Anda melakukan rebase saat berada di cabang B), Anda benar: tidak perlu penggabungan lebih lanjut:

Sebuah pohon git di default ketika kita tidak digabung atau di-rebased

rebase1 

kita dapatkan dengan rebase:

rebase3

Skenario kedua adalah tentang: bagaimana cara mengembalikan fitur baru ke dalam master.

Maksud saya, dengan menggambarkan skenario rebase pertama, adalah untuk mengingatkan semua orang bahwa rebase juga dapat digunakan sebagai langkah awal untuk itu (yang menjadi "mendapatkan fitur baru kembali ke master").
Anda dapat menggunakan rebase untuk terlebih dahulu membawa master "dalam" cabang fitur baru: rebase akan memutar ulang commit fitur baru dari HEAD master, tetapi masih di cabang fitur baru, secara efektif memindahkan titik awal cabang Anda dari master lama yang berkomitmen HEAD-master.
Yang memungkinkan Anda menyelesaikan konflik apa pun di anda cabang (artinya, dalam isolasi, sementara memungkinkan master untuk terus berevolusi secara paralel jika tahap resolusi konflik Anda terlalu lama).
Kemudian Anda dapat beralih untuk menguasai dan menggabungkan new-feature (atau rebase new-feature ke master jika Anda ingin mempertahankan komitmen yang dilakukan di Anda new-feature cabang).

Begitu:

  • "rebase vs. penggabungan" dapat dilihat sebagai dua cara untuk mengimpor pekerjaan, katakanlah, master.
  • Tetapi "rebase lalu bergabung" dapat menjadi alur kerja yang valid untuk menyelesaikan konflik secara terpisah, kemudian mengembalikan pekerjaan Anda.

253
2018-04-29 20:44



Banyak jawaban di sini mengatakan bahwa menggabungkan mengubah semua commit Anda menjadi satu, dan karena itu menyarankan untuk menggunakan rebase untuk mempertahankan komitmen Anda. Ini tidak benar. Dan ide yang buruk jika Anda sudah mendorong komitmen Anda.

Gabungkan tidak tidak lenyapkan komitmen Anda. Gabung mempertahankan sejarah! (lihat saja gitk) Riwayat penulisan ulang penulisan ulang, yang merupakan Bad Thing setelah Anda mendorong saya t.

Gunakan gabungan - bukan rebase setiap kali Anda sudah mendorong.

Di sini adalah Linus '(penulis git) mengambilnya. Ini benar-benar membaca yang bagus. Atau Anda dapat membaca versi saya sendiri dari ide yang sama di bawah ini.

Memutuskan cabang di master:

  • memberikan gagasan yang salah tentang bagaimana komitmen dibuat
  • pencemaran menguasai dengan sekelompok komit menengah yang mungkin belum diuji dengan baik
  • dapat benar-benar memperkenalkan membangun istirahat pada komit menengah ini karena perubahan yang dibuat untuk menguasai antara kapan cabang topik asli dibuat dan ketika itu telah di-rebased.
  • membuat mencari tempat yang baik di master untuk checkout sulit.
  • Menyebabkan cap waktu pada komitmen untuk tidak sejajar dengan urutan kronologis mereka di pohon. Jadi, Anda akan melihat bahwa komit A mendahului melakukan B di master, tetapi komit B adalah yang pertama kali dibuat. (Apa?!)
  • Menghasilkan lebih banyak konflik karena individu yang melakukan di cabang topik masing-masing dapat melibatkan menggabungkan konflik yang harus diselesaikan secara individual (Lebih lanjut berbaring dalam sejarah tentang apa yang terjadi di setiap commit).
  • adalah penulisan ulang sejarah. Jika cabang yang sedang di-rebide telah didorong ke mana saja (dibagikan dengan orang lain selain Anda sendiri) maka Anda telah mengacaukan orang lain yang memiliki cabang tersebut karena Anda telah menulis ulang sejarah.

Sebaliknya, menggabungkan cabang topik menjadi master:

  • mempertahankan sejarah di mana cabang topik dibuat, termasuk penggabungan dari master ke cabang topik untuk membantu menjaganya tetap terkini. Anda benar-benar mendapatkan ide yang akurat tentang kode apa yang digunakan pengembang ketika mereka membangun.
  • master adalah cabang yang sebagian besar terdiri dari gabungan, dan masing-masing dari mereka menggabungkan komit biasanya 'poin yang baik' dalam sejarah yang aman untuk diperiksa karena di situlah cabang topik siap untuk diintegrasikan.
  • semua komitmen individu dari cabang topik dipertahankan, termasuk fakta bahwa mereka berada di cabang topik, sehingga mengisolasi perubahan tersebut adalah hal yang alami dan Anda dapat meneliti di mana diperlukan.
  • menggabungkan konflik hanya harus diselesaikan sekali (pada titik penggabungan) sehingga perubahan komit menengah yang dibuat di cabang topik tidak harus diselesaikan secara independen.
  • dapat dilakukan beberapa kali dengan lancar. Jika Anda mengintegrasikan cabang topik Anda untuk dikuasai secara berkala, orang-orang dapat terus membangun di cabang topik dan dapat terus digabung secara independen.

151
2018-02-03 22:17



TL; DR

Jika Anda ragu, gunakan gabungan.

Jawaban singkat

Satu-satunya perbedaan antara rebase dan penggabungan adalah:

  • Struktur pohon yang dihasilkan dari sejarah (umumnya hanya terlihat ketika melihat grafik komit) berbeda (satu akan memiliki cabang, yang lain tidak akan).
  • Penggabungan umumnya akan membuat komitmen ekstra (misalnya node di pohon).
  • Gabung dan rebase akan menangani konflik secara berbeda. Rebase akan menampilkan konflik yang dilakukan pada saat menggabungkan akan menghadirkan semuanya sekaligus.

Jadi jawaban singkatnya adalah pilih rebase atau gabungkan berdasarkan apa yang Anda inginkan dari sejarah Anda.

Jawaban panjang

Ada beberapa faktor yang harus Anda pertimbangkan ketika memilih operasi yang akan digunakan.

Apakah cabang Anda mendapatkan perubahan dari dibagikan dengan pengembang lain di luar tim Anda (mis. Sumber terbuka, publik)?

Jika demikian, jangan rebase. Rebase menghancurkan cabang dan pengembang tersebut akan memiliki repositori yang rusak / tidak konsisten kecuali mereka menggunakannya git pull --rebase. Ini adalah cara yang baik untuk membuat pengembang lain kesal dengan cepat.

Seberapa terampil tim pengembangan Anda?

Rebase adalah operasi yang merusak. Itu artinya, jika Anda tidak menerapkannya dengan benar, Anda bisa kehilangan pekerjaan yang dilakukan dan / atau merusak konsistensi repositori pengembang lainnya.

Saya telah bekerja di tim di mana semua pengembang berasal dari saat ketika perusahaan mampu membayar staf yang berdedikasi untuk menangani percabangan dan penggabungan. Para pengembang itu tidak tahu banyak tentang Git dan tidak ingin tahu banyak. Dalam tim-tim ini saya tidak akan mengambil risiko merekomendasikan rebase untuk alasan apa pun.

Apakah cabang itu sendiri merupakan informasi yang berguna

Beberapa tim menggunakan model cabang-per-fitur di mana setiap cabang mewakili fitur (atau perbaikan bug, atau sub-fitur, dll.) Dalam model ini cabang membantu mengidentifikasi kumpulan komit terkait. Misalnya, seseorang dapat dengan cepat mengembalikan fitur dengan mengembalikan penggabungan cabang tersebut (agar adil, ini adalah operasi yang jarang). Atau diff fitur dengan membandingkan dua cabang (lebih umum). Rebase akan menghancurkan cabang dan ini tidak akan langsung.

Saya juga bekerja pada tim yang menggunakan model cabang per-pengembang (kita semua pernah berada di sana). Dalam hal ini cabang itu sendiri tidak menyampaikan informasi tambahan (komit sudah memiliki penulis). Tidak ada ruginya dalam melakukan rebasing.

Mungkin Anda ingin mengembalikan penggabungan karena alasan apa pun?

Mengembalikan (seperti membatalkan) rebase sangat sulit dan / atau tidak mungkin (jika rebase mengalami konflik) dibandingkan dengan mengembalikan gabungan. Jika Anda berpikir ada kemungkinan Anda akan ingin kembali, gunakan penggabungan.

Apakah Anda bekerja di tim? Jika demikian, apakah Anda bersedia untuk mengambil pendekatan semua atau tidak sama sekali di cabang ini?

Operasi rebase harus ditarik dengan yang sesuai git pull --rebase. Jika Anda bekerja sendiri, Anda mungkin dapat mengingat mana yang harus Anda gunakan pada waktu yang tepat. Jika Anda bekerja dalam tim, ini akan sangat sulit untuk dikoordinasikan. Inilah sebabnya mengapa sebagian besar alur kerja rebase merekomendasikan penggunaan rebase untuk semua gabungan (dan git pull --rebase untuk semua tarikan).

Mitos umum

Gabungkan menghancurkan sejarah (squashes commit)

Dengan asumsi Anda memiliki penggabungan berikut:

    B -- C
   /      \
  A--------D

Beberapa orang akan menyatakan bahwa penggabungan "menghancurkan" sejarah komit karena jika Anda melihat log dari hanya cabang master (A - D) Anda akan kehilangan pesan-pesan komit penting yang terkandung dalam B dan C.

Jika ini benar kita tidak akan memilikinya pertanyaan seperti ini. Pada dasarnya, Anda akan melihat B dan C kecuali Anda secara eksplisit meminta untuk tidak melihatnya (menggunakan --first-parent). Ini sangat mudah untuk dicoba sendiri.

Rebase memungkinkan penggabungan yang lebih aman / lebih sederhana

Kedua pendekatan bergabung secara berbeda, tetapi tidak jelas bahwa salah satu pendekatan selalu lebih baik daripada yang lain dan mungkin bergantung pada alur kerja pengembang. Misalnya, jika pengembang cenderung melakukan secara rutin (mis. Mungkin mereka melakukan dua kali sehari saat mereka bertransisi dari kerja ke rumah) maka mungkin ada banyak komitmen untuk cabang tertentu. Banyak dari mereka yang melakukan mungkin tidak terlihat seperti produk akhir (saya cenderung refactor pendekatan saya sekali atau dua kali per fitur). Jika orang lain bekerja di bidang kode yang terkait dan mereka mencoba untuk mengubah perubahan saya, itu bisa menjadi operasi yang cukup membosankan.

Rebase lebih dingin / lebih seksi / lebih profesional

Jika Anda suka alias rm untuk rm -rf untuk "menghemat waktu" maka mungkin rebase adalah untuk Anda.

My Two Cents

Saya selalu berpikir bahwa suatu hari nanti saya akan menemukan skenario di mana git rebase adalah alat luar biasa yang memecahkan masalah. Sama seperti saya pikir saya akan menemukan skenario di mana git reflog adalah alat luar biasa yang memecahkan masalah saya. Saya telah bekerja dengan git selama lebih dari lima tahun sekarang. Itu belum terjadi.

Sejarah yang berantakan tidak pernah benar-benar menjadi masalah bagi saya. Saya tidak pernah membaca sejarah komitmen saya seperti novel yang menarik. Sebagian besar waktu saya perlu sejarah saya akan menggunakan git blame atau git bisekt anyways. Dalam hal itu, menggabungkan komitmen sebenarnya berguna bagi saya karena jika penggabungan memperkenalkan masalah yang merupakan informasi yang berarti bagi saya.

Mutakhirkan (4/2017)

Saya merasa berkewajiban untuk menyebutkan bahwa saya secara pribadi telah melunak dengan menggunakan rebase meskipun saran saya tetap berlaku. Saya baru-baru ini berinteraksi banyak dengan Materi 2 Sudut proyek. Mereka telah menggunakan rebase untuk menjaga sejarah komitmen yang bersih. Ini memungkinkan saya untuk melihat dengan mudah apa yang dilakukan dengan memperbaiki cacat tertentu dan apakah komit itu dimasukkan dalam rilis atau tidak. Ini berfungsi sebagai contoh yang bagus untuk menggunakan rebase dengan benar.


114
2018-04-13 02:16



Gabung artinya: Buat satu commit baru yang menggabungkan perubahan saya ke tujuan.

Rebase berarti: Buat serangkaian commit baru, menggunakan rangkaian commit saya saat ini sebagai petunjuk. Dengan kata lain, hitunglah bagaimana perubahan saya akan terlihat jika saya mulai membuatnya dari titik yang saya rebal. Setelah rebase, Anda mungkin perlu menguji ulang perubahan Anda dan selama rebase, Anda mungkin memiliki beberapa konflik.

Mengingat hal ini, mengapa Anda melakukan rebase? Hanya untuk menjaga sejarah perkembangan menjadi jelas. Katakanlah Anda sedang mengerjakan fitur X dan setelah selesai, Anda menggabungkan perubahan Anda. Tujuan sekarang akan memiliki komitmen tunggal yang akan mengatakan sesuatu di sepanjang baris "Menambahkan fitur X". Sekarang, alih-alih penggabungan, jika Anda di-rebased dan kemudian digabungkan, sejarah pengembangan tujuan akan mengandung semua komitmen individual dalam satu perkembangan logis tunggal. Hal ini membuat perubahan review nantinya jauh lebih mudah. Bayangkan betapa sulitnya Anda akan menemukannya untuk meninjau sejarah pengembangan jika 50 pengembang menggabungkan berbagai fitur setiap saat.

Yang mengatakan, jika Anda telah mendorong cabang yang Anda kerjakan di hulu, Anda tidak boleh melakukan rebase, melainkan gabungkan. Untuk cabang yang belum terdorong ke hulu, rebase, tes, dan penggabungan.

Lain waktu Anda mungkin ingin rebase adalah ketika Anda ingin menyingkirkan komit dari cabang Anda sebelum mendorong ke hulu. Sebagai contoh: Komit yang memperkenalkan beberapa kode debug awal dan lainnya melakukan lebih lanjut pada yang membersihkan kode itu. Satu-satunya cara untuk melakukan ini adalah dengan melakukan rebase interaktif: git rebase -i <branch/commit/tag>

UPDATE: Anda juga ingin menggunakan rebase ketika Anda menggunakan Git untuk antarmuka ke sistem kontrol versi yang tidak mendukung sejarah non-linear (subversi misalnya). Saat menggunakan jembatan git-svn, sangat penting bahwa perubahan yang Anda gabungkan kembali menjadi subversi adalah daftar perubahan berurutan di bagian atas perubahan terbaru dalam bagasi. Hanya ada dua cara untuk melakukannya: (1) Buat kembali perubahan secara manual dan (2) Menggunakan perintah rebase, yang jauh lebih cepat.

UPDATE2: Salah satu cara tambahan untuk memikirkan rebase adalah memungkinkan pemetaan jenis dari gaya pengembangan Anda ke gaya yang diterima di repositori yang Anda lakukan. Katakanlah Anda suka melakukan dalam potongan kecil dan kecil. Anda memiliki satu komit untuk memperbaiki kesalahan ketik, satu berkomitmen untuk menyingkirkan kode yang tidak digunakan dan sebagainya. Pada saat Anda selesai melakukan apa yang perlu Anda lakukan, Anda memiliki serangkaian panjang commit. Sekarang katakanlah repositori yang Anda lakukan untuk mendorong komit besar, jadi untuk pekerjaan yang Anda lakukan, orang akan berharap satu atau mungkin dua komit. Bagaimana Anda mengambil string commit Anda dan memampatkan mereka untuk apa yang diharapkan? Anda akan menggunakan rebase interaktif dan menekan komitmen kecil Anda menjadi lebih sedikit. Hal yang sama berlaku jika kebalikannya diperlukan - jika gaya Anda adalah beberapa komit besar, tetapi repo menuntut string panjang komit kecil. Anda akan menggunakan rebase untuk melakukan itu juga. Jika Anda telah bergabung sebagai gantinya, Anda sekarang telah mencangkokkan gaya commit Anda ke repositori utama. Jika ada banyak pengembang, Anda dapat membayangkan betapa sulitnya mengikuti sejarah dengan beberapa gaya komit yang berbeda setelah beberapa waktu.

UPDATE3: Does one still need to merge after a successful rebase? Ya, benar. Alasannya adalah bahwa rebase pada dasarnya melibatkan "pengalihan" komitmen. Seperti yang sudah saya katakan di atas, komit ini dihitung, tetapi jika Anda memiliki 14 komit dari titik percabangan, maka dengan asumsi tidak ada yang salah dengan rebase Anda, Anda akan 14 komit di depan (dari titik yang Anda rebo) setelah rebase selesai. Anda memiliki cabang sebelum rebase. Anda akan memiliki cabang dengan panjang yang sama setelahnya. Anda masih perlu menggabungkan sebelum menerbitkan perubahan Anda. Dengan kata lain, rebase sebanyak yang Anda inginkan (sekali lagi, hanya jika Anda tidak mendorong perubahan Anda ke hulu). Gabung hanya setelah Anda melakukan rebase.


65
2018-02-05 06:47



sebelum menggabungkan / rebase:

A <- B <- C    [master]
^
 \
  D <- E       [branch]

setelah git merge master:

A <- B <- C
^         ^
 \         \
  D <- E <- F

setelah git rebase master:

A <- B <- C <- D' <- E'

(A, B, C, D, E dan F adalah commit)

contoh ini dan informasi yang jauh lebih baik tentang git dapat ditemukan di sini: http://excess.org/article/2008/07/ogre-git-tutorial/


54
2018-06-07 06:19



Kalimat ini mendapatkannya:

Secara umum cara untuk mendapatkan yang terbaik dari kedua dunia adalah dengan melakukan rebase lokal   perubahan yang Anda buat tetapi belum dibagikan sebelum Anda mendorongnya   untuk membersihkan cerita Anda, tetapi jangan pernah mencabut apa pun yang telah Anda dorong   suatu tempat.

Sumber: http://www.git-scm.com/book/en/v2/Git-Branching-Rebasing#Rebase-vs.-Merge


25
2018-01-05 13:50



Meskipun penggabungan jelas merupakan cara termudah dan paling umum untuk mengintegrasikan perubahan, itu bukan satu-satunya: Rebase merupakan sarana alternatif integrasi.

Memahami Gabungkan Sedikit Lebih Baik

Ketika Git melakukan penggabungan, ia mencari tiga komit:

  • (1) Komitmen leluhur bersama Jika Anda mengikuti sejarah dua cabang dalam sebuah proyek, mereka selalu memiliki setidaknya satu komitmen yang sama: pada titik waktu ini, kedua cabang memiliki konten yang sama dan kemudian berevolusi secara berbeda.
  • (2) + (3) Titik akhir dari setiap cabang Tujuan integrasi adalah untuk menggabungkan keadaan dua cabang saat ini. Oleh karena itu, revisi terbaru masing-masing adalah minat khusus. Menggabungkan ketiga komitmen ini akan menghasilkan integrasi yang kami tuju.

Fast-Forward atau Merge Commit

Dalam kasus yang sangat sederhana, salah satu dari dua cabang tidak memiliki komitmen baru sejak percabangan terjadi - komitmen terakhirnya masih merupakan nenek moyang yang sama.

enter image description here

Dalam hal ini, melakukan integrasi adalah mati sederhana: Git dapat menambahkan semua komit dari cabang lain di atas komitmen leluhur bersama. Di Git, bentuk integrasi yang paling sederhana ini disebut gabungan "maju cepat". Kedua cabang itu berbagi sejarah yang sama persis.

enter image description here

Namun dalam banyak kasus, kedua cabang bergerak maju secara individual. enter image description here

Untuk membuat integrasi, Git harus membuat komit baru yang berisi perbedaan di antara mereka - komit gabungan.

enter image description here

Komitmen Manusia & Komitmen Gabungan

Biasanya, komitmen dibuat dengan hati-hati oleh manusia. Ini adalah unit yang berarti yang hanya membungkus perubahan terkait dan memberi anotasi mereka dengan komentar.

Komitmen gabungan sedikit berbeda: alih-alih dibuat oleh pengembang, ini dibuat secara otomatis oleh Git. Dan bukannya membungkus serangkaian perubahan terkait, tujuannya adalah untuk menghubungkan dua cabang, seperti simpul. Jika Anda ingin memahami operasi penggabungan nanti, Anda perlu melihat sejarah kedua cabang dan grafik komit yang terkait.

Berintegrasi dengan Rebase

Sebagian orang memilih untuk pergi tanpa komit gabungan otomatis semacam itu. Sebaliknya, mereka ingin sejarah proyek terlihat seolah-olah berevolusi dalam satu garis lurus. Tidak ada indikasi tetap bahwa itu telah dipecah menjadi beberapa cabang di beberapa titik.

enter image description here

Mari berjalan melalui operasi rebase selangkah demi selangkah. Skenarionya sama dengan contoh sebelumnya: kita ingin mengintegrasikan perubahan dari cabang-B ke cabang-A, tetapi sekarang dengan menggunakan rebase.

enter image description here

Kami akan melakukan ini dalam tiga langkah

  1. git rebase branch-A // syncs the history with branch-A
  2. git checkout branch-A // change the current branch to branch-A
  3. git merge branch-B // merge/take the changes from branch-B to branch-A 

Pertama, Git akan "membatalkan" semua komit pada cabang-A yang terjadi setelah garis mulai bercabang (setelah leluhur bersama melakukan). Namun, tentu saja, itu tidak akan membuang mereka: sebagai gantinya Anda dapat menganggap mereka melakukan sebagai "terselamatkan sementara".

enter image description here

Selanjutnya, ia menerapkan komit dari cabang-B yang ingin kita integrasikan. Pada titik ini, kedua cabang terlihat persis sama.

enter image description here

Pada langkah terakhir, komitmen baru pada cabang-A sekarang telah diterapkan kembali - tetapi pada posisi baru, di atas komitmen terintegrasi dari cabang-B (mereka berbasis ulang). Hasilnya tampak seperti pembangunan yang terjadi dalam garis lurus. Alih-alih komit gabungan yang berisi semua perubahan gabungan, struktur komit asli dipertahankan.

enter image description here

Akhirnya Anda mendapat cabang bersih cabang-A tanpa ada komit yang tidak diinginkan dan dihasilkan secara otomatis.

catatan: Diambil dari yang luar biasa pos oleh git-tower. Itu kerugian dari rebase juga baik dibaca di pos yang sama.


23
2017-10-12 11:52



Buku pro git sebagai penjelasan yang sangat bagus tentang halaman rebase.

Pada dasarnya gabungan akan mengambil 2 commit dan menggabungkannya.

Rebase akan pergi ke leluhur bersama pada 2 dan secara bertahap menerapkan perubahan di atas satu sama lain. Ini membuat sejarah 'lebih bersih' dan lebih linier.

Tetapi ketika Anda me-rebase Anda meninggalkan commit sebelumnya dan membuat yang baru. Jadi Anda tidak boleh me-rebase repo yang bersifat publik. Orang lain yang bekerja di repo akan membencimu.

Untuk alasan itu saja saya hampir secara eksklusif bergabung. 99% waktu cabang saya tidak begitu berbeda, jadi jika ada konflik, itu hanya ada di satu atau dua tempat.


15
2017-12-20 21:41