Rumah >alat pembangunan >git >Analisis terperinci git-merge (tersusun dan dikongsi)
Artikel ini membawa anda pengetahuan yang berkaitan tentang Git, yang terutamanya memperkenalkan isu yang berkaitan dengan git-merge Perintah git-merge digunakan untuk menggabungkan daripada komit yang ditentukan kepada Operasi cawangan semasa , saya harap ia akan membantu semua orang.
Pembelajaran yang disyorkan: "Tutorial Git"
Dalam git-merge command , terdapat tiga parameter berikut:
git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] [--[no-]rerere-autoupdate] [-m <msg>] [<commit>...]
git merge <msg> HEAD <commit>...
git merge --abort
Arahan git-merge digunakan untuk menggabungkan daripada komit yang ditentukan kepada cawangan semasa.
Nota: Komit yang ditentukan di sini merujuk kepada bermula daripada nod komit sejarah ini sehingga pemisahan semasa.
Arahan git-merge mempunyai dua kegunaan berikut:
Kemudian perintah git merge topic
akan menggabungkan nod biasa pada cawangan induk (E Nodes) dipisahkan selepas ( iaitu, nod A B C cawangan topik) muncul semula pada cawangan induk sehingga nod komit semasa cawangan topik (nod C), dan terletak di bahagian atas cawangan induk. Dan buat nod baharu di sepanjang cawangan induk dan cawangan topik untuk merekodkan hasil cantuman Nod ini membawa maklumat pengguna yang menerangkan perubahan cantuman.
git merge <msg> HEAD <commit>...
PerintahArahan ini wujud atas sebab sejarah Ia tidak sepatutnya digunakan dalam versi baharu dan harus digantikan dengan git merge -m <msg> <commit>....
git merge --abort
Akan meninggalkan proses penggabungan dan cuba membina semula keadaan pra-gabungan. Walau bagaimanapun, jika terdapat fail yang tidak terikat apabila penggabungan bermula, git merge --abort
dalam beberapa kes, keadaan pragabungan tidak akan dapat dihasilkan semula. (Terutama apabila fail yang tidak terikat ini akan diubah suai semasa proses penggabungan) git merge --abort
Amaran: Menjalankan2. Parameter Bahagian ini digunakan untuk memperkenalkan parameter yang digunakan dalam perintahdengan sejumlah besar fail yang tidak terikat dengan mudah boleh menyebabkan anda menghadapi masalah, yang akan Menyukarkan anda untuk berundur daripada konflik. Oleh itu, adalah sangat tidak digalakkan untuk mempunyai fail yang tidak terikat apabila menggunakan
git-merge
Adalah disyorkan untuk menggunakan perintahgit-merge
untuk menyimpan sementara fail yang tidak komited ini, dan menggunakangit-stash
untuk memulihkan fail yang tidak komited ini selepas menyelesaikan konflik.git stash pop
git-merge
--commit
--no-commit
Parameter menyebabkan nod komit hasil gabungan dijana selepas digabungkan. Parameter ini boleh digantikan --commit
. Parameter --no-commit
menyebabkan cantuman tidak diserahkan secara automatik untuk mengelakkan cantuman daripada gagal, memberikan pengguna peluang untuk menyemak dan mengubah suai hasil cantuman sebelum penyerahan. --no-commit
--edit
dan -e
--no-edit
dan --edit
digunakan untuk memanggil editor untuk mengedit selanjutnya maklumat gabungan yang dijana secara automatik sebelum gabungan berjaya atau komited. Oleh itu, pengguna boleh mentafsir dan menilai dengan lebih lanjut hasil penggabungan itu. Parameter -e
boleh digunakan untuk menerima maklumat yang digabungkan secara automatik (ini biasanya tidak digalakkan). --no-edit
Jika anda telah memberikan parametersemasa menggabungkan (diterangkan di bawah), ia masih berguna untuk menggunakan
-m
(atau--edit
), yang akan diedit selanjutnya dalam editor-e
Kandungan yang terkandung.-m
Versi lama nod mungkin tidak membenarkan pengguna mengedit maklumat log gabungan.2.3
--ff
merujuk kepada arahan ke hadapan pantas. Apabila menggabungkan menggunakan mod ke hadapan pantas, nod komit baharu tidak akan dibuat. Secara lalai, --ff
menggunakan mod ke hadapan pantas. git-merge
Untuk mendapatkan penjelasan terperinci tentang mod ke hadapan pantas, sila lihat bahagian "Perihal ke hadapan pantas" artikel saya yang lain: Model Percabangan Git yang Berjaya.
--no-ff
menggabungkan teg. git merge
--ff-only
--log[=<n>]
dan --no-log
--log[=<n>]
akan mengandungi, sebagai tambahan kepada nama cawangan, maklumat log sehingga n nod komit digabungkan apabila penggabungan komit. --no-log
tidak menyenaraikan maklumat ini.
--stat
, -n
, --no-stat
--stat
akan memaparkan status perbezaan fail pada penghujung hasil gabungan. Status perbezaan fail juga boleh dikonfigurasikan dalam merge.stat dalam fail konfigurasi git.
Sebaliknya, parameter -n
, --no-stat
tidak akan memaparkan maklumat ini.
--squash
dan --no-squash
--squash
Apabila gabungan berlaku, dari nod cawangan lain selepas nod nenek moyang sepunya cawangan semasa dan cawangan lain, sepanjang jalan ke cawangan lain Nod atas akan dimampatkan bersama, dan pengguna boleh menyerahkannya selepas semakan untuk menjana nod baharu.
Nota 1: Parameter ini bercanggah dengan
--no-ff
Nota 2: Hasil penggunaan parameter ini adalah serupa dengan menyerahkan nod baharu pada arus cawangan. Parameter ini sangat berguna dalam beberapa kes, seperti semasa menggunakan Git Flow (tentang Git Flow, sila rujuk: Model cawangan Git yang berjaya Apabila cawangan fungsi membangunkan keperluan fungsian, pembangun boleh menyerahkan sejumlah besar secara tempatan). . Dan nod yang tidak bermakna, apabila ia perlu digabungkan ke dalam cawangan pembangunan, anda mungkin hanya perlu menggunakan nod baharu untuk mewakili kandungan pengubahsuaian senarai panjang nod ini Pada masa ini, perintah
--squash
akan digunakan . Di samping itu, jika berbilang penyerahan cawangan ciri tidak remeh tetapi bermakna, menggunakan perintah--no-ff
adalah lebih sesuai.--no-squash
melakukan sebaliknya.
-s <strategy>
dan --strategy=<strategy>
-s <strategy>
dan --strategy=<strategy>
digunakan untuk menentukan strategi gabungan. Secara lalai, jika parameter ini tidak ditentukan, git akan menggunakan strategi gabungan lalai mengikut syarat berikut:
-X <option>
dan --strategy-option=<option>
nyatakan parameter khusus strategi ini apabila -s <strategy>
(diterangkan di bawah).
--verify-signatures
, --no-verify-signatures
digunakan untuk mengesahkan sama ada nod yang digabungkan mempunyai tandatangan GPG dan mengabaikan nod tersebut tanpa pengesahan tandatangan GPG dalam gabungan.
(Petikan berikut diambil daripada artikel yang dicetak semula. Memandangkan saya tidak menemui pengarang asal, saya tidak dapat memberikan maklumat pengarang asal dan pautan artikel asal. Jika terdapat sebarang pelanggaran, sila maklumkan kepada saya melalui mesej peribadi atau komen , dan saya akan memadamkan petikan berikut.)
GPG ialah perisian penyulitan Anda boleh menggunakan kunci awam yang dijana oleh GPG untuk menyebarkan fail dan kod anda dengan selamat di Internet.
Kenapa awak kata selamat? Ambil repo yang dibangunkan oleh Google sebagai contoh Repo menggunakan pengesahan GPG Setiap teg pencapaian mempunyai pengesahan penyulitan GPG. Jika anda ingin membuat perubahan pada peristiwa penting v1.12.3, padamkan teg selepas pengubahsuaian. buat teg dengan nama yang sama untuk menunjuk ke titik pengubahsuaian anda. Walau bagaimanapun, apabila anda mengklon semula projek anda yang diubah suai, anda akan mendapati bahawa perubahan anda pada teg pencapaian ini tidak dikenali dan pengesahan gagal, menyebabkan pengubahsuaian anda tidak dilaksanakan seperti biasa di sini. Ini ialah peranan pengesahan GPG, yang memastikan pencapaian yang ditetapkan oleh pengarang projek (pemegang kunci persendirian) tidak boleh diubah suai oleh orang lain. Kemudian, boleh dikatakan kod penulis selamat disebarkan.
Mengapa ada keperluan sedemikian? Daripada pembangunan kepada keluaran kepada lelaran kemas kini projek yang kemudian, pasti akan terdapat beberapa versi dan versi pembangunan yang stabil (terdapat faktor ketidakstabilan). Sebagai pemula dan pemegang projek, mereka mempunyai hak untuk menentukan versi stabil yang mereka (mereka) kenali Versi stabil ini tidak akan membenarkan pembangun lain membuat perubahan. Ambil projek repo Google sebagai contoh Pemilik projek mentakrifkan titik A dalam proses pembangunan projek sebagai versi stabil v1.12.3 Kemudian selepas pengguna memuat turun versi v1.12.3, mereka pasti akan menggunakan projek dan produk yang dihasilkan oleh titik A. Walaupun pembangun lain boleh menentukan semula v1.12.3 secara tempatan dan menentukannya pada titik B yang diubah suai mereka, apabila versi yang diubah suai akhirnya digunakan oleh pengguna, akan ada masalah bahawa pengesahan tandatangan GPG gagal, iaitu, ini adalah The pengubahsuaian tidak akan berkuat kuasa.
—summary
, --no-summary
dan --stat
adalah serupa dengan --no-stat
dan akan dialih keluar dalam versi akan datang.
-q
dan --quiet
beroperasi secara senyap dan tidak memaparkan maklumat kemajuan gabungan.
-v
dan --verbose
memaparkan maklumat hasil cantuman terperinci.
--progress
dan --no-progress
bertukar sama ada untuk memaparkan maklumat kemajuan gabungan. Jika kedua-duanya tidak dinyatakan, mesej akan dipaparkan pada terminal yang disambungkan apabila ralat standard berlaku. Ambil perhatian bahawa tidak semua strategi gabungan menyokong pelaporan kemajuan.
-S[<keyid>]
dan --gpg-sign[=<keyid>]
Tandatangan GPG.
-m <msg>
Tetapkan maklumat komit yang digunakan semasa mencipta nod gabungan.
Jika parameter --log
ditentukan, log pendek nod komit akan dilampirkan pada mesej komit.
--[no-]rerere-autoupdate
rerere bermaksud menggunakan semula resolusi yang direkodkan, menggunakan semula penyelesaian yang direkodkan. Ia membolehkan anda meminta Git mengingati cara menyelesaikan konflik blok supaya pada kali berikutnya anda melihat konflik yang sama, Git boleh menyelesaikannya secara automatik untuk anda.
--abort
Tinggalkan proses pengendalian konflik gabungan semasa dan cuba bina semula keadaan pra-gabungan.
Apabila menggabungkan cawangan luar, anda harus memastikan cawangan anda sendiri bersih, jika tidak, akan berlaku konflik gabungan Ia akan menyebabkan banyak masalah.
Untuk mengelak daripada merekodkan fail yang tidak berkaitan semasa penggabungan komit, arahan git-pull dan git-merge akan berhenti jika terdapat sebarang fail yang tidak terikat didaftarkan dalam nod HEAD yang ditunjuk oleh indeks.
Biasanya pencantuman cawangan akan menghasilkan nod cantuman, tetapi terdapat pengecualian dalam beberapa kes khas. Sebagai contoh, apabila memanggil arahan git pull untuk mengemas kini kod jauh, jika cawangan tempatan tidak mempunyai sebarang komit, tidak perlu menjana nod gabungan. Dalam kes ini, nod gabungan tidak akan dijana dan HEAD menghala terus ke kod teratas yang dikemas kini Strategi gabungan ini ialah gabungan ke hadapan.
Selain mod cantum ke hadapan pantas yang disebutkan di atas, cawangan yang digabungkan akan diikat pada cawangan semasa melalui nod cantuman Nod cantum juga akan Mempunyai bahagian atas nod cawangan semasa sebelum bergabung dan nod atas cawangan lain, kedua-duanya sebagai nod induk.
Versi gabungan akan membuat perubahan dalam semua cawangan berkaitan konsisten, termasuk nod komit, nod HEAD dan penunjuk indeks, dan pepohon nod akan dikemas kini. Selagi fail dalam nod ini tidak bertindih, perubahan pada fail ini akan diubah suai dan dikemas kini dalam pepohon nod.
Jika perubahan ini tidak boleh digabungkan secara eksplisit, perkara berikut akan berlaku:
MERGE_HEAD
Penunjuk diletakkan di tempat lain Bahagian atas cawangan MERGE_HEAD
. Fail dalam pokok nod mengandungi hasil menjalankan program gabungan. Sebagai contoh, algoritma gabungan tiga hala boleh menyebabkan konflik. git merge --abort
Mengenai algoritma gabungan tiga hala:
Gabungan tiga hala Algoritma ialah cara untuk menyelesaikan konflik Apabila konflik berlaku, algoritma gabungan tiga hala akan memperoleh tiga nod: nod B konflik tempatan, nod C cawangan lain dan nenek moyang terdekat yang sama. nod A daripada nod B dan C. Algoritma gabungan tiga hala akan bergabung berdasarkan tiga nod ini. Proses khusus adalah untuk membandingkan nod B dan C dengan nod A. Jika fail dalam nod B dan C adalah sama dengan nod A, maka tidak akan berlaku konflik jika hanya satu daripada B atau C telah berubah berbanding dengan nod A, maka Fail akan menggunakan versi yang diubah; jika B dan C telah berubah berbanding dengan A, dan perubahannya tidak sama, maka anda perlu menggabungkannya secara manual jika B dan C telah berubah, dan perubahannya adalah sama , maka tidak akan ada konflik dan versi yang diubah akan diterima pakai secara automatik. Selepas penggabungan terakhir, nod D akan dihasilkan Nod D mempunyai dua nod induk, iaitu B dan C.
Apabila menggabungkan teg, Git sentiasa mencipta komit gabungan, walaupun mod maju pantas boleh digunakan. Templat maklumat penyerahan dipratetap kepada maklumat teg. Selain itu, jika teg ditandatangani, maklumat pengesanan tandatangan akan dilampirkan pada templat mesej komit.
Apabila konflik gabungan berlaku, bahagian itu akan diwakili oleh <<<<<<<
, =======
dan . Bahagian sebelum
=======
ialah keadaan pada cawangan semasa, dan bahagian selepas =======
ialah situasi pada cawangan sebelah lagi.
Selepas melihat konflik, anda boleh memilih dua kaedah berikut:
git merge --abort
digunakan dalam kes ini. git add
untuk menambahkannya pada indeks selepas menyelesaikan konflik, dan kemudian gunakan git commit
untuk menjana nod gabungan. git mergetool
Alat cantuman visual akan dipanggil untuk mengendalikan cantuman yang bercanggah. git diff
Perbezaan tiga hala (algoritma perbandingan tiga hala yang digunakan dalam gabungan tiga hala) akan dipaparkan. git log --merge -p <path>
akan memaparkan perbezaan antara versi HEAD
dan versi MERGE_HEAD
. git show :1:文件名
memaparkan versi nenek moyang yang sama, git show :2:文件名
memaparkan versi HEAD cawangan semasa dan git show :3:文件名
memaparkan versi MERGE_HEAD
cawangan lain. Git boleh menentukan strategi gabungan dengan menambah parameter -s. Sesetengah strategi cantuman malah mempunyai pilihan parameternya sendiri Gunakan -X<option>
untuk menetapkan pilihan parameter strategi cantuman ini. (Jangan lupa bahawa penggabungan boleh berlaku dalam kedua-dua arahan git merge dan git pull, jadi strategi gabungan ini juga digunakan untuk git pull).
Hanya gunakan algoritma cantum tiga hala untuk menggabungkan nod atas dua cawangan (seperti cawangan semasa dan cawangan lain yang anda tarik ke bawah). Strategi cantuman ini mengikut algoritma cantuman tiga hala, di mana nod HEAD bagi dua cawangan dan nod anak biasa melakukan cantuman tiga hala.
Sudah tentu, apa yang benar-benar mengganggu kami ialah kes gabungan silang silang. Apa yang dipanggil penggabungan silang merujuk kepada keadaan di mana terdapat berbilang nod nenek moyang yang sama Contohnya, apabila dua cabang digabungkan, kemungkinan besar terdapat dua nod nenek moyang yang sama Pada masa ini, penggabungan tidak dapat dilakukan mengikut kepada algoritma gabungan tiga hala (kerana nod nenek moyang biasa tidak unik). Beginilah cara strategi penyelesaian menangani masalah cantum silang Berikut ialah rujukan kepada "Kawalan Versi dengan Git":
Berikut ialah terjemahan mudah: Dalam kes cantuman silang, terdapat lebih daripada satu titik rujukan cantuman (nod nenek moyang biasa berfungsi seperti ini: pilih salah satu titik rujukan gabungan yang mungkin). dan berharap bahawa ini adalah titik gabungan yang terbaik. Ini sebenarnya tidak seteruk yang didengari. Biasanya pengguna mengubah suai bahagian kod yang berlainan, dalam hal ini banyak konflik gabungan sebenarnya berlebihan dan berulang. Apabila menggunakan azam untuk bergabung, konflik yang dijana lebih mudah dikendalikan, dan terdapat sangat sedikit kes di mana kod sebenarnya akan hilang. 4.2rekursifHanya cantumkan dua cabang menggunakan algoritma cantum tiga hala. Berbeza dengan penyelesaian, dalam kes cantuman silang, kaedah cantuman ini dipanggil secara rekursif Bermula dari nod yang berbeza dari dua cabang selepas nod nenek moyang yang sama, algoritma cantuman tiga hala dipanggil secara rekursif untuk bergabung. maka fail Gabungan tidak akan diteruskan lagi dan konflik akan dibuang terus fail lain tanpa konflik akan dilaksanakan sehingga nod atas. Selain itu, pendekatan ini dapat mengesan dan mengendalikan operasi yang melibatkan pengubahsuaian nama fail. Ini ialah tindakan gabungan lalai untuk git penggabungan dan penarikan kod.Dalam situasi cantum silang silang, di mana terdapat lebih daripada satu kemungkinan asas cantum. strategi penyelesaian berfungsi seperti ini: pilih salah satu pangkalan gabungan yang mungkin, dan harapkan yang terbaik Ini sebenarnya tidak seburuk yang didengari Dalam kes ini, Git mengesan bahawa ia menggabungkan semula beberapa perubahan yang sudah ada dan melangkau perubahan pendua, mengelakkan konflik Atau, jika ini adalah sedikit perubahan yang menyebabkan konflik, sekurang-kurangnya konflik itu harus mudah dikendalikan oleh pembangun
Strategi cantuman rekursif mempunyai parameter berikut:
Parameter mereka dan kami sesuai untuk menggabungkan konflik fail binari.
luangkan sedikit masa tambahan untuk mengelakkan kehilangan baris yang tidak penting (seperti kurungan fungsi). Jika pemisahan cawangan versi antara cawangan semasa dan cawangan lain adalah sangat besar, adalah disyorkan untuk menggunakan kaedah gabungan ini. git merge-recursive
diff-algorithm=[patience|minimal|histogram|myers]
untuk menggunakan algoritma perbandingan yang berbeza. git merge-recursive
ignore-space-change
, ignore-all-space
ignore-space-at-eol
no-renames
Matikan pengesanan nama semula.
subtree[=<path>]
Pilihan ini ialah bentuk lanjutan strategi cantum subpokok, yang akan meneka cara dua pokok nod bergerak semasa proses cantum. Perbezaannya ialah laluan yang ditentukan akan dialih keluar pada permulaan cantuman, supaya laluan lain boleh dipadankan apabila mencari subpohon. (Lihat di bawah untuk mendapatkan butiran tentang strategi cantuman subpokok)
Kaedah cantum ini digunakan untuk lebih daripada dua cabang, tetapi ia akan menolak untuk bergabung apabila konflik memerlukan penggabungan manual. Kaedah gabungan ini lebih sesuai untuk menggabungkan berbilang cawangan bersama-sama dan juga merupakan strategi gabungan lalai untuk gabungan berbilang cawangan.
Kaedah ini boleh menggabungkan sebarang bilangan dahan, tetapi hasil gabungan pepohon nod sentiasa merupakan bahagian bercanggah bagi cawangan semasa. Kaedah ini boleh menjadi sangat cekap apabila menggantikan versi lama. Sila ambil perhatian bahawa kaedah ini berbeza daripada parameter kami di bawah strategi rekursif.
subtree ialah versi diubah suai bagi strategi rekursif. Apabila menggabungkan pokok A dan pokok B, jika B ialah subpokok A, B mula-mula melaraskan untuk memadankan struktur pokok A dan bukannya membaca nod yang sama.
Apabila menggunakan strategi gabungan tiga hala (merujuk kepada strategi rekursif lalai), jika fail (atau baris kod) berubah dalam kedua-dua cawangan semasa dan sebaliknya cawangan, tetapi sedikit Kemudian ia berguling semula pada salah satu cabang, maka perubahan gulung semula ini akan ditunjukkan dalam hasil . Perkara ini mungkin mengelirukan sesetengah orang. Ini kerana semasa proses penggabungan, git hanya memfokuskan pada nod nenek moyang sepunya dan nod HEAD kedua-dua cawangan, dan bukannya semua nod kedua-dua cawangan. Oleh itu, algoritma cantuman akan menganggap bahagian yang digulung semula sebagai tidak berubah , supaya hasil yang digabungkan akan menjadi bahagian yang diubah dalam cawangan lain.
Saya sentiasa percaya bahawa Git ialah alat kawalan versi yang sangat baik, tetapi ramai orang dalam syarikat mendapati Git sukar digunakan. Sebahagian besar daripada sebab keadaan ini ialah inersia yang dibawa oleh penggunaan subversi sebelumnya mempunyai kesan terhadap penerimaan teknologi baharu, sebaliknya ramai orang hanya menggunakan Git melalui klien GUI; Untuk masa yang lama, kebanyakan orang berpendapat bahawa menggunakan GUI adalah cara yang lebih mudah untuk bermula. Sebenarnya, ini boleh dipersoalkan. Mengikut pengalaman peribadi saya, menggunakan GUI boleh mencipta inersia, dan operasi selalunya boleh diselesaikan dengan mengklik beberapa butang, membuatkan ramai orang berfikir bahawa mempelajari arahan Git adalah membuang masa dan tenaga. Tetapi sebenarnya, tanpa pemahaman yang jelas tentang arahan dan idea Git, menggunakan butang mudah itu sebenarnya akan menyebabkan banyak masalah: ramai orang tidak tahu apa yang akan berlaku selepas mengklik butang, dan GUI terlalu pintar untuk membiarkan butang yang sama Acara klik mungkin sepadan dengan arahan dengan parameter yang berbeza. Akhirnya, pengguna miskin yang benar-benar terluka kerana mereka tidak tahu apa masalahnya.
Berdasarkan teks penuh, berikut ialah ringkasan beberapa konvensyen yang diikuti oleh individu apabila menggunakan Git. Apa yang dipanggil perjanjian merujuk kepada tingkah laku yang tidak dipaksa dan sukarela. Kegagalan untuk mematuhi konvensyen ini tidak akan menyebabkan sebarang kecacatan, tetapi mematuhi konvensyen ini boleh mengurangkan kesukaran dan meningkatkan kecekapan apabila menggunakan Git.
Pembelajaran yang disyorkan: "Tutorial Pembelajaran Git"
Atas ialah kandungan terperinci Analisis terperinci git-merge (tersusun dan dikongsi). Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!