Apakah gabungan dalam git

Dalam git, merge bermaksud "merge". Perintah ini digunakan untuk menggabungkan dua atau lebih sejarah pembangunan bersama-sama; bergabung dari satu cabang ke cabang yang lain.

Persekitaran pengendalian tutorial ini: sistem Windows 7, versi Git 2.30.0, komputer Dell G3.

Analisis lengkap git-merge

Git-merge ialah arahan yang sering digunakan dalam Git Ramai orang berpendapat bahawa git merge adalah perkara yang sangat menyusahkan. anda akan menghadapi masalah kehilangan kod, yang akan membuatkan anda menghindar daripada git. Artikel ini menyediakan pengenalan yang lengkap dan terperinci kepada arahan git-merge berdasarkan Git 2.8.2, terutamanya mengenai masalah kehilangan kod yang disebabkan oleh penggabungan silang Saya memberikan cadangan saya sendiri pada akhir artikel, dengan harapan dapat membantu pengguna git . Kandungan yang diperkenalkan dalam artikel ini adalah berdasarkan Git 2.8.2

Perintah git-merge ialah operasi yang digunakan untuk menggabungkan dua atau lebih sejarah pembangunan bersama-sama Ia juga biasanya boleh ditulis sebagai: git merge .

parameter pilihan berkaitan 1.git-merge

1.1 Ringkasan

Dalam arahan git-merge, 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>...]</commit></msg></keyid></strategy-option></strategy>
• git merge <msg> HEAD <commit>...</commit></msg>
• git merge --abort

1.2 Pengenalan kepada git-merge

Arahan git-merge digunakan Gabungkan operasi daripada komit yang ditentukan ke 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:

1. digunakan dalam git-pull untuk menyepadukan perubahan dalam repositori kod lain (iaitu: git pull = git fetch git merge)
2. Untuk penggabungan dari satu cawangan ke cawangan lain

Anggapkan bahawa nod sejarah berikut wujud, dan cawangan semasa ialah "master":

Kemudian perintah git merge topic akan menggantikan semula nod (iaitu nod A B C cawangan topik) yang dipisahkan selepas nod biasa (nod E) pada cawangan induk cawangan induk, sehingga nod komit semasa (nod C) cawangan topik, dan 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.

Iaitu, nod H dalam rajah di bawah, nod C dan nod G ialah kedua-dua nod induk bagi nod H.

1.3git merge <msg> HEAD <commit>...</commit></msg>Arahan

Arahan ini wujud atas sebab sejarah dan tidak seharusnya digunakan dalam versi baharu, sebaliknya gunakan git merge -m <msg> <commit>....</commit></msg> Gantikan

1.4git merge --abortArahan

Arahan ini hanya digunakan apabila konflik terhasil selepas digabungkan. git merge --abortAkan 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)

Amaran: Menjalankan git-merge dengan 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 perintah git-stash untuk menyimpan sementara fail yang tidak komited ini, dan menggunakan git stash pop untuk memulihkan fail yang tidak komited ini selepas menyelesaikan konflik.

2. Parameter

Bahagian ini digunakan untuk memperkenalkan parameter yang digunakan dalam perintah git-merge

2.1--commit dan --no-commit

--commitParameter menyebabkan nod komit hasil gabungan dijana selepas digabungkan. Parameter ini boleh digantikan --no-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.

2.2--edit dan -e dan --no-edit

--edit dan -e 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
--no-edit boleh digunakan untuk menerima maklumat yang digabungkan secara automatik (ini biasanya tidak digalakkan).

Jika anda telah memberikan parameter -m semasa menggabungkan (diterangkan di bawah), ia masih berguna untuk menggunakan --edit (atau -e), yang akan mengedit lagi -m dalam editor Apa yang disertakan .

Versi lama nod mungkin tidak membenarkan pengguna mengedit maklumat log gabungan.

2.3--ffArahan

--ff merujuk kepada arahan ke hadapan pantas. Apabila menggabungkan menggunakan mod ke hadapan pantas, nod komit baharu tidak akan dibuat. Secara lalai, git-merge menggunakan mod ke hadapan pantas.
Untuk penjelasan terperinci tentang mod ke hadapan pantas, sila lihat artikel saya yang lain: bahagian "Perihal ke hadapan pantas" bagi model cawangan Git yang berjaya.

2.4--no-ffArahan

Buat nod cantum baharu walaupun mod maju pantas tersedia. Ini ialah gelagat lalai apabila git merge menggabungkan teg.

2.5--ff-onlyArahan

Melainkan nod HEAD semasa telah dikemas kini (kemas kini menghala ke nod terkini) atau boleh digabungkan menggunakan mod ke hadapan pantas, jika tidak, gabungan akan ditolak dan mengembalikan status kegagalan.

2.5 --log[=<n>]</n> dan --no-log

--log[=<n>]</n> akan mengandungi maklumat log sehingga n nod komit digabungkan sebagai tambahan kepada nama cawangan apabila menggabungkan komit.
--no-log tidak menyenaraikan maklumat ini.

2.6 Parameter perintah --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.

2.7--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.

2.8 -s <strategy></strategy> dan --strategy=<strategy></strategy>

-s <strategy></strategy> dan --strategy=<strategy></strategy> digunakan untuk menentukan strategi gabungan. Secara lalai, jika parameter ini tidak ditentukan, git akan menggunakan strategi gabungan lalai mengikut syarat berikut:

1. Apabila nod gabungan hanya mengandungi nod induk tunggal (seperti apabila menggunakan ke hadapan pantas mod), strategi rekursif akan digunakan (diperkenalkan di bawah).
2. Apabila nod yang digabungkan mengandungi berbilang nod induk (seperti apabila menggunakan mod tidak maju-cepat), strategi sotong (diterangkan di bawah) digunakan.

2.9 -X <option></option> dan --strategy-option=<option></option>

nyatakan parameter khusus strategi ini apabila -s <strategy></strategy> (diterangkan di bawah).

2.10 --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 ke artikel asal. Jika terdapat sebarang pelanggaran, sila maklumkan kepada saya melalui peribadi mesej 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.

2.11 —summary, --no-summary

dan --stat adalah serupa dengan --no-stat dan akan dialih keluar dalam versi akan datang.

2.12 -q dan --quiet

beroperasi secara senyap dan tidak memaparkan maklumat kemajuan gabungan.

2.13 -v dan --verbose

memaparkan maklumat hasil cantuman terperinci.

2.14 --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.

2.15-S[<keyid>]</keyid> dan --gpg-sign[=<keyid>]</keyid>

Tandatangan GPG.

2.16-m <msg></msg>

Tetapkan maklumat komit yang digunakan semasa mencipta nod gabungan.
Jika parameter --log ditentukan, log pendek nod komit akan dilampirkan pada mesej komit.

2.17--[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 apabila anda melihat konflik yang sama, Git boleh menyelesaikannya secara automatik untuk anda.

2.18--abort

Tinggalkan proses pengendalian konflik gabungan semasa dan cuba bina semula keadaan pra-gabungan.

3. Konsep lain tentang penggabungan

3.1 Pengesanan sebelum penggabungan

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 ditunjukkan oleh indeks.

3.2fast-forward merge

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.

3.3 Butiran penggabungan

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 yang digabungkan akan membuat perubahan dalam semua cawangan yang berkaitan dengan 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:

1. Nod yang ditunjuk oleh penuding HEAD kekal tidak berubah
2. MERGE_HEADPenunjuk diletakkan di atas cawangan lain
3. Laluan bersih telah digabungkan dalam fail indeks dan pokok nod Kemas kini
4. pada masa yang sama Untuk laluan konflik, fail indeks merekodkan tiga versi: versi 1 merekodkan nod nenek moyang yang sama bagi kedua-duanya, versi 2 merekodkan bahagian atas cawangan semasa, iaitu, HEAD, dan rekod versi 3 MERGE_HEAD . Fail dalam pokok nod mengandungi hasil menjalankan program gabungan. Sebagai contoh, algoritma gabungan tiga hala boleh menyebabkan konflik.
5. Tiada perubahan lain. Khususnya, pengubahsuaian tempatan yang anda buat sebelum ini akan kekal utuh.
   Jika anda mencuba gabungan yang mengakibatkan konflik yang sangat kompleks dan ingin memulakan semula, anda boleh menggunakan 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.

3.4 Menggabungkan tag

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.

3.5 Bagaimana konflik diwakili

Apabila konflik gabungan berlaku, bahagian itu akan diwakili oleh , <code>======= dan . Bahagian sebelum ======= ialah keadaan pada cawangan semasa, dan bahagian selepas ======= ialah situasi pada cawangan sebelah lagi.

3.6 Cara menyelesaikan konflik

Selepas melihat konflik, anda boleh memilih dua kaedah berikut:

• Memutuskan untuk tidak bergabung. Pada masa ini, satu-satunya perkara yang perlu dilakukan ialah menetapkan semula indeks kepada nod HEAD. git merge --abort digunakan dalam kes ini.
• Selesaikan konflik. Git akan menandakan konflik, gunakan git add untuk menambahkannya pada indeks selepas menyelesaikan konflik, dan kemudian gunakan git commit untuk menjana nod gabungan.
  Anda boleh menggunakan alatan berikut untuk menyelesaikan konflik:
• Gunakan alat cantum. git mergetoolAlat cantuman visual akan dipanggil untuk mengendalikan cantuman yang bercanggah.
• Lihat perbezaannya. git diffPerbezaan tiga hala (algoritma perbandingan tiga hala yang digunakan dalam gabungan tiga hala) akan dipaparkan.
• Lihat perbezaan untuk setiap cawangan. git log --merge -p <path></path> akan memaparkan perbezaan antara versi HEAD dan versi MERGE_HEAD.
• Lihat versi pra-gabungan. 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.

4. Strategi gabungan

Git boleh menentukan strategi gabungan dengan menambah parameter -s. Sesetengah strategi cantuman malah mempunyai pilihan parameternya sendiri Gunakan -X<option></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).

4.1resolve

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 Sila rujuk "Kawalan Versi dengan Git" di sini:

Dalam situasi cantum silang silang, di mana terdapat lebih daripada satu kemungkinan asas cantum, strategi penyelesaian berfungsi seperti ini: pilih salah satu asas cantum yang mungkin, dan harapkan yang terbaik Ini sebenarnya tidak seburuk itu . Seperti yang didengari bahawa pengguna telah mengusahakan bahagian yang berlainan dalam kes itu, Git mengesan bahawa ia menggabungkan semula beberapa perubahan yang sudah ada dan melangkau perubahan pendua, Atau, jika ini adalah sedikit perubahan yang menyebabkan konflik, sekurang-kurangnya konflik sepatutnya mudah untuk pembangun mengendalikan nod nenek moyang), strategi penyelesaian berfungsi seperti ini: pilih salah satu titik rujukan penggabungan yang mungkin dan harap ini adalah hasil terbaik penggabungan itu. 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.2rekursif

Hanya 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.

Strategi gabungan rekursif mempunyai parameter berikut:

4.2.1 milik kami

Parameter ini akan memaksa versi cawangan semasa digunakan secara automatik apabila konflik berlaku. Kaedah gabungan ini tidak akan menyebabkan sebarang masalah, malah git tidak akan menyemak kandungan konflik yang terkandung dalam versi cawangan lain Kaedah ini akan membuang sebarang kandungan konflik dalam cawangan lain.

4.2.2 milik mereka

Ia betul-betul bertentangan dengan kita.

Parameter mereka dan kami sesuai untuk menggabungkan konflik fail binari.

4.2.2 kesabaran

Dengan parameter ini,

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.

4.2.3git merge-recursive

memberitahu diff-algorithm=[patience|minimal|histogram|myers] untuk menggunakan algoritma perbandingan yang berbeza.

4.2.4 git merge-recursive,

,

ignore-space-changeignore-all-spaceLayani konflik ruang putih mengikut parameter yang ditentukan. ignore-space-at-eol

Jika versi pihak satu lagi hanya menambah perubahan pada ruang, maka versi kami sendiri akan digunakan apabila menggabungkan konflik

Jika versi kami mengandungi ruang, tetapi versi pihak lain mengandungi besar bilangan perubahan , maka versi pihak yang satu lagi akan digunakan apabila menggabungkan konflik
• Gunakan prosedur pemprosesan biasa
• 4.2.5

Matikan pengesanan nama semula . no-renames

4.2.6

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) subtree[=<path>]</path>

4.3octopus

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.

4.4ours

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.

4.5subtree

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.

4.5 Ringkasan

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. Pembelajaran yang disyorkan: "Tutorial Git

"

Atas ialah kandungan terperinci Apakah gabungan dalam git. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!