Apakah yang dilakukan git-rebase dan git-merge? Apa bezanya?

Apakah yang dilakukan git-rebase dan git-merge? Apakah perbezaan antara git-rebase dan git-merge? Artikel berikut akan memperkenalkan kepada anda perbezaan antara git-rebase dan git-merge Saya harap ia akan membantu anda!

Menggunakan Git untuk kawalan versi sepatutnya menjadi salah satu aliran kerja yang kebanyakan jurutera hadapi setiap hari, tetapi apa yang saya gunakan tidak lebih daripada push, pull, merge, checkout atau log dan arahan lain. ?" ”

Selepas mendengar ini, saya langsung keliru. Bagi saya, rebase ialah alat yang digunakan untuk mengatur komitmen. Bagaimanakah ia boleh dibandingkan dengan gabungan? [Pembelajaran yang disyorkan: "Tutorial Git"]

git-rebase

Mula-mula, mari kita bincangkan tentang apa yang biasanya saya gunakan perintah rebase. , jika saya menambah ujian unit baharu, dan kemudian commit, maka log akan mempunyai rekod tambahan commit:

Tetapi ia tidak akan menjadi sehingga komit selesai saya mendapati saya terlepas menulis kes ujian lain, jadi selepas menebusnya, saya komited sekali lagi:

Pada masa ini, akan ada satu lagi dalam rekod commit , tetapi pada saya, kedua-dua commit ini sebenarnya melakukan perkara yang sama, jadi sebelum saya menolak ke jauh, saya ingin menyusun komit dan menggabungkan kedua-dua rekod.

Terdapat dua cara untuk menggabungkan kedua-dua rekod ini Yang pertama ialah reset sebelum menambah kes ujian pertama, dan kemudian melakukannya terus commit. Kaedah kedua ialah menggunakan rebase untuk mengendalikannya!

Mula-mula mari kita lihat log semasa:

Tujuan saya adalah untuk menyusun 9dc67ff dan 87af945 menjadi satu, jadi saya perlu untuk melaraskan Komit adalah daripada init, iaitu, semua komit selepas id komit ialah 7eb57cb Apabila dipasangkan dengan perintah rebase, ia adalah:

git rebase -i 7eb57cb

Selepas memasukkan, ia akan melompat ke. skrin penyuntingan vim:

Anda akan melihat semua komit selepas 7eb57cb pada skrin (pada masa ini hanya 9dc67ff dan 87af945), kemudian tukar 9dc67ff daripada pick kepada squash bermaksud menggabungkannya dengan komitmen sebelumnya. Klik i dahulu dan kemudian mula mengedit kandungan dengan vim:

Selepas mengedit, anda boleh klik esc dan masukkan :wq untuk menyimpan Jika anda hanya ingin tahu, masuk dan lihat untuk menyimpan, masukkan :q!. Selepas menyelesaikan proses di atas, semak log sekali lagi dan anda akan mendapati bahawa dua komit telah menjadi satu. Selepas menyimpan, ia akan melompat ke skrin mesej komit Di sini anda boleh memasukkan mesej komit yang digabungkan, tetapi saya tidak akan mengubahnya dan hanya menyimpannya terus:

Tamat. di atas Selepas proses, semak log sekali lagi, dan anda akan mendapati bahawa kedua-dua komit telah menjadi satu:

Baik dahulu, operasi di atas ialah mod interaktif rebase, dalam git rebase -i yang dimasukkan kemudian sebenarnya adalah singkatan daripada interactive.

git-merge

Semua orang sepatutnya sangat biasa dengan arahan gabungan, kerana apabila membuat ciri baharu, anda biasanya mengeluarkan cawangan dan kemudian menyelesaikannyamerge Kembali ke cabang utama seperti master atau develop. Proses operasi adalah seperti berikut:

在 merge 的时候会有两种情况，第一种是  fast-forward，会把被合并分支的 HEAD 的 reference 移到要合併分支内最新的 commit 上，上方操作的 merge 结果就是 fast-forward，master 的 HEAD 被移到 string-library 的最新 commit，画成图的话就是这样子：

但是如果在执行 merge 的时候产生冲突，那分支的合并行为就会和 fast-forward 有点不同了。举例来说，我分别在 master 和 string-library 的同一个文件添加内容，那当我执行 merge 的时候就会要求先修复冲突：

修复完后，再执行 commit 完成合并，而这一次合并时，会再多一个 commit 是有关 merge 了 string-library 分支的纪录：

这个情况画成图就会像这样子：

git-rebase 与 git-merge 的差异

看完上方对 rebase 和 merge 的介绍后，你也许会想说：

「咦？那这两个不是完全不同的东西吗？」

对的，原本我也是这麽认为，一直到我去看了 git-rebase 的文档，才发现原来我一直误会它了。在 git book 的 rebase 篇章，第一段就说明了，在 Git 里有两种方法可以用来整合两个分支，而这两个在上方都有提到，分别为 merge 和 rebase：

从上方的 merge 例子已经知道了，merge 在合并的时候会有 fast-forward，和冲突时用一个 commit 记录合并变更的两种情形。而 rebase 的整合方式非常有趣，依照关于 rebase 的另一段说明，它可以「把某个分支中所有 commit 的过程，以另一个分支的 commit 为基础重播一遍」：

这是什麽意思呢？首先让我们回到上述的例子，并在 master 分支上用 reset，让 master 的版本回到合并 string-library 之前：

现在我们要用 rebase 指令，将 string-library 所有的 commit 修改，以 master 的 commit 为基础跑一次。使用 rebase 合并的第一步，要先切到想重播 commit 的分支：

git checkout string-library

然后再输入 git rebase 指令，并于后方指定要在哪个分支上重播：

git rebase master

执行结果：

在 rebase 重播 commit 的过程中，和 merge 相似的地方在于，如果有冲突的话还是需要解决，但在解决后，并不是使用 commit 指令进行合并，而是要输入 git rebase --continue，让 rebase 可以继续重播接下来的 commit：

重播完成时，会显示目前重播到哪个 commit，以 string-library 来说就是最新的add string unit test D。这时候的分支关系，画成图就会变成：

上图在经过 rebase 之后，string-library 里 07e38fb 修改，会以 master 的 commit 为基底再重播一次。

需要注意的是，重播后的 commit id 会和原本的不一样，这等于完全改写了分支内所有的 commit 历史纪录。

Selain itu, selepas melaksanakan rebase, string-library sebenarnya belum digabungkan kembali ke cawangan induk, jadi anda masih perlu bertukar kembali ke cawangan induk untuk melaksanakan gabungan bagi melengkapkan gabungan:

Oleh kerana pangkalan semula telah digunakan untuk mengendalikan konflik komit semasa main semula, kini cantuman akan terus ke cantuman ke hadapan pantas dan tidak akan ada rekod komit lain untuk gabungan itu.

Kebaikan dan keburukan menggunakan git-rebase untuk bergabung

Kelebihan

• Tiada komit berlebihan akan dihasilkan semasa penggabungan .

• Konflik boleh dikendalikan dalam unit komit semasa main semula.

• Apabila digabungkan, ia akan diatur mengikut komitmen cawangan, supaya isu semakan atau proses pemprosesan ciri dapat difahami dengan jelas. Jika anda menggunakan gabungan, komit kedua-dua cawangan akan disusun dalam susunan kronologi selepas gabungan.

• Apabila menyumbang kepada projek sumber terbuka, jika anda meletakkan semula sebelum menolak, pengarang boleh terus bergabung dengan cara yang pantas tanpa perlu menyelesaikan konflik secara berasingan.

Kelemahan

Kelemahan terbesar ialah yang disebut di atas akan mengubah suai sejarah komitmen atau cawangan secara setempat anda secara tidak sengaja menukar cawangan terpencil, dan kemudian secara tidak sengaja menggunakan git push -f, anda mungkin dibenci oleh rakan sekerja anda, atau anda mungkin diserahkan kepada jurutera utara semata-mata.

Perlukah saya menggunakan git-rebase atau git-merge?

Setelah menyemak beberapa maklumat, saya mendapati bahawa kedua-dua rebase dan merge mempunyai penyokong sendiri, saya akan menerangkan idea mereka dahulu dan kemudian secara subjektif menyebut pendapat saya sendiri.

puak git-merge

menyokong git-merge jurutera percaya bahawa nilai rekod versi terletak pada komit projek, iaitu " "Apa yang sebenarnya berlaku dalam sejarah?" Ia akan menjadi sangat buruk jika anda mengubah suai rekod sejarah ini. Jadi walaupun kandungan cawangan yang berbeza dicampurkan bersama selepas penggabungan, mereka masih menggambarkan sejarah projek. Jurutera yang dihantar oleh

git-rebase menghantar

untuk menyokong git-rebase merasakan bahawa komitmen itu bercakap tentang "proses evolusi" projek, dan apa yang berlaku adalah Yang penting, walaupun sejarah komit diubah suai, apa yang berlaku tetap tidak berubah Memandangkan rekod yang lebih jelas dan ringkas boleh digunakan untuk dibaca oleh generasi akan datang, ini harus dilakukan.

Pendapat subjektif peribadi

Saya secara peribadi masih menggunakan git-rebase untuk mengubah suai komitmen untuk menjadikan rekod sejarah lebih mudah dibaca, tetapi penggunaannya terhad untuk menolak ke jauh Sebelum ini , jika saya telah menolak rekod itu ke jauh hari ini, saya tidak akan mengubah suainya walau betapa kucar-kacirnya lagi, rekod jauh itu dikongsi oleh semua orang Jika saya tidak mengubah suainya sesuka hati, saya akan menghormati ahli lain pasukan.

[Tutorial video berkaitan yang disyorkan: bahagian hadapan web]

Atas ialah kandungan terperinci Apakah yang dilakukan git-rebase dan git-merge? Apa bezanya?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!