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"

1.1 Ringkasan

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

1.2git Pengenalan kepada -merge

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:

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

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.

1.3git merge <msg> HEAD <commit>...Perintah

Arahan ini wujud atas sebab sejarah Ia tidak sepatutnya digunakan dalam versi baharu dan harus digantikan dengan git merge -m <msg> <commit>....

1.4Perintahgit merge --abort

Perintah ini hanya digunakan apabila konflik berlaku selepas penggabungan.

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: Menjalankan

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

2. Parameter

Bahagian ini digunakan untuk memperkenalkan parameter yang digunakan dalam perintah

git-merge

2.1

dan --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

2.2

dan --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 parameter

semasa menggabungkan (diterangkan di bawah), ia masih berguna untuk menggunakan -m (atau --edit), yang akan diedit selanjutnya dalam editor -eKandungan yang terkandung. -m

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

2.3

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

2.4

Arahan--no-ff

Buat nod cantum baharu walaupun mod maju pantas tersedia. Ini ialah gelagat lalai apabila

menggabungkan teg. git merge

2.5

Arahan--ff-only

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

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> 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:

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> dan --strategy-option=<option>

nyatakan parameter khusus strategi ini apabila -s <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 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.

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>] dan --gpg-sign[=<keyid>]

Tandatangan GPG.

2.16-m <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 pada kali berikutnya 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 ditunjuk 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 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:

1. Nod yang ditunjuk oleh penuding HEAD kekal tidak berubah
2. MERGE_HEADPenunjuk diletakkan di tempat lain Bahagian atas cawangan
3. Laluan bersih yang digabungkan dikemas kini secara serentak dalam fail indeks dan pepohon nod
4. Untuk laluan bercanggah, fail indeks merekodkan tiga versi: Versi 1 merekodkan nenek moyang yang sama bagi dua Nod, versi 2 merekodkan bahagian atas cawangan semasa, iaitu HEAD, dan versi 3 merekodkan 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 <<<<<<<, ======= 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> 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> 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 Berikut ialah rujukan kepada "Kawalan Versi dengan Git":

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

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.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 cantuman 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. git merge-recursive

4.2.3

diff-algorithm=[patience|minimal|histogram|myers]

memberitahu

untuk menggunakan algoritma perbandingan yang berbeza. git merge-recursive

4.2.4

, ignore-space-change, ignore-all-spaceignore-space-at-eol

Layani konflik ruang putih mengikut parameter yang ditentukan.

• Jika versi pihak lain hanya menambah perubahan dalam ruang, maka versi kami sendiri akan digunakan apabila konflik digabungkan
• Jika versi kami mengandungi ruang, tetapi versi pihak lain mengandungi jumlah yang besar daripada perubahan, maka konflik akan berlaku Gunakan versi pihak lain apabila menggabungkan
• Amalkan pemprosesan biasa

4.2.5 no-renames

Matikan pengesanan nama semula.

4.2.6subtree[=<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)

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.

5. Beberapa pendapat peribadi tentang penggunaan Git

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.

1. Serahkan lebih banyak dan kurangkan tolak. Apabila berbilang orang bekerjasama, tolakan akan kerap menyebabkan konflik gabungan, menjejaskan kecekapan. Oleh itu, cuba gunakan arahan komit sebanyak mungkin dan kurangkan penggunaan gabungan, yang akan menjimatkan banyak masa.
2. Gunakan Git Flow (Git Flow), lihat artikel saya yang lain untuk mendapatkan butiran: Model percabangan Git yang berjaya
3. Gunakan cawangan, pastikan cawangan utama bersih. Ini adalah sesuatu yang saya sangat mengesyorkan Hantar pada cawangan, kemudian beralih ke cawangan utama untuk mengemas kini (git pull —rebase), kemudian gabungkan cawangan dan tolak. Proses sedemikian akan mengelakkan percantuman silang (tidak akan ada berbilang nod nenek moyang yang sama). Sebenarnya, sebab mengapa ramai orang merasa terharu dengan operasi gabungan git ialah masalah cantum silang yang disebabkan oleh pelbagai sebab, yang menyebabkan beberapa kod hilang semasa proses cantuman. Menjaga kebersihan cawangan induk boleh mengelakkan cantuman silang.
4. Lumpuhkan mod maju pantas. Gunakan parameter rebase apabila menarik kod (premisnya adalah untuk memastikan cawangan utama bersih), dan gunakan parameter -no-ff untuk melumpuhkan mod ke hadapan pantas apabila bergabung Ini bukan sahaja dapat memastikan kejelasan nod, tetapi juga mengelakkan percantuman silang.

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!