Saya rasa realitinya begini:

1. Sekurang-kurangnya separuh daripada orang yang menggunakan git tidak tahu cara menggunakan rebase (walaupun untuk fungsi asas) (anggaran ini mungkin sangat konservatif)

2. Mungkin hanya separuh daripada separuh lagi yang benar-benar memahami bila hendak membuat semula dengan betul...

Gabung atau rebase bukan soal memilih satu atau yang lain Ia harus dipilih mengikut situasi tertentu Pada hakikatnya, "situasi khusus" ini benar-benar sukar untuk disenaraikan satu demi satu. fungsi dalam pasukan adalah agak mudah, dan mereka tidak sering berpeluang menemuinya, jadi di sini saya hanya akan merumuskan dua prinsip yang semua orang harus faham dan patuhi:

1. Apabila anda pergi dari jauh ke pull, sentiasa gunakan rebase (dengan satu pengecualian, dibincangkan kemudian)

2. Apabila anda melengkapkan ciri (dengan andaian anda membuka cawangan tempatan secara berasingan) dan merancang untuk menggabungkannya ke dalam cawangan batang, sentiasa gunakan gabung

Pembangun harus memahami bahawa strategi gabungan yang berbeza mungkin tidak menjejaskan hasil kod akhir, tetapi ia akan mempengaruhi cara git merekodkan sejarah penyerahan (walaupun banyak kali pemahaman ini hanya memberi manfaat kepada individu dan mempunyai sedikit kesan kepada diri mereka sendiri) ). Apabila orang lain menggunakan sejarah ini (seperti semasa semakan kod, atau semasa dua belah, dsb.), mereka akan berasa amat gembira atau sengsara kerana apa yang telah anda lakukan pada masa lalu.

Maksud kedua lebih mudah difahami Sembunyikan butiran khusus untuk membangunkan fungsi dalam cawangan tempatan, dan gabungkan hasil akhir ke dalam cawangan batang sebagai rekod lengkap.

Kuncinya ialah perkara pertama. Dalam kebanyakan kes, semua orang akan memilih pull lalai, iaitu fetch + merge, jadi kita akan melihat mesej gangguan seperti Gabungkan komit xxx ke dalam xxx sentiasa muncul pada batang. Jika semua orang melakukan ini untuk kemudahan, maka kita tidak akan mempunyai pokok sejarah yang bersih dan cantik sebaliknya, kita akan mempunyai sesuatu seperti ini:

Jika anda mengklonkan projek yang menggunakan git dengan betul, anda tidak akan pernah melihat master yang tidak kemas seperti gambar di atas. kenapa? Jawapannya ialah: git pull --rebase Perintah ini akan menggunakan rebase dan bukannya pull lalai untuk mengasaskan semula pepohon sejarah yang digabungkan, yang boleh mengelakkan rekod gabungan tambahan kerana ketidakupayaan untuk memajukan pantas.

Kini kebanyakan pelanggan git membenarkan tetapan kelakuan lalai git pull menjadi --rebase, jadi menguasai helah ini boleh menghasilkan rekod sejarah yang bersih dan cantik untuk kebanyakan operasi tarik harian, tetapi ini bukan pengakhiran yang sempurna. Terdapat pengecualian seperti ini:

1. Selepas anda menggunakan git merge untuk melengkapkan gabungan cawangan ciri ke cawangan batang (sudah tentu --no-ff)

2. Apabila anda menjalankan git fetch, anda mendapati bahawa batang jauh adalah beberapa komit di hadapan anda

3. Jika anda git pull --rebase pada masa ini, anda akan mendapati rekod cawangan ciri yang baru anda gabungkan telah hilang...

Ini kerana rebase akan mengabaikan rekod yang digabungkan, jadi arahan rebase akan mempunyai parameter khas yang dipanggil: --preserve-merges digunakan untuk membina semula rekod gabungan yang diabaikan. Jadi penyelesaian yang lebih baik daripada git pull --rebase ialah menggunakan git fetch + git rebase -p sebaliknya.

Sudah tentu, ini hanya untuk keadaan istimewa yang disebutkan di atas dengan peningkatan git, tidak pasti masalah ini tidak akan wujud lagi satu hari nanti. Saya biasanya tidak menghadapi situasi ini, kerana saya selalu melakukan ini:

1. Selepas melengkapkan cawangan ciri, jangan gabung, tetapi kembali ke cawangan utama git pull --rebase

2. Jika batang dikemas kini, letakkan semula kandungan yang dikemas kini ke cawangan fungsi untuk pra-semak untuk melihat sama ada fungsi saya masih OK selepas menambah perubahan terbaru yang dibuat oleh orang lain (mungkin terdapat konflik dalam proses ini, Jangan' t salahkan saya kerana tidak mengingatkan anda)

3. Setelah semuanya siap, git fetch periksa batang sekali lagi untuk melihat sama ada terdapat sebarang perubahan (kerana seseorang mungkin telah menolak perubahan baru semasa langkah kedua), jika terdapat sebarang perubahan, ulangi langkah kedua, jika tidak——

4. Gabungkan cawangan fungsi ke batang dan tolaknya, dan panggilnya sehari.

Saya boleh mengelakkan kemalangan yang disebutkan di atas dengan melakukan ini Nampaknya agak rumit, tetapi sebenarnya ia tidak sukar apabila anda sudah biasa dengannya git rebase -p

tidak boleh digunakan bersama dengan
1. Satu arahan terbahagi kepada dua, yang rasanya "hilang" pula (walaupun anda boleh menulis skrip, sebaiknya jangan lakukannya kerana ia kadangkala akan memudaratkan anda selepas anda. biasakan diri)

   git pull

tidak boleh digunakan dengan
2. , jadi anda mesti menentukan cawangan sasaran untuk rebase, yang agak menjengkelkan, terutamanya apabila ramai pelanggan GUI tidak menyokong

   sama sekali (saya sering menggunakan persekitaran CLI/ Switch antara GUI menggunakan git) git pullgit rebase -p

3. akan musnah.

   ORIG_HEAD

untuk menyemak semua perubahan yang disebabkan oleh gabungan terkini, dsb. ORIG_HEAD akan menyebabkan ia kehilangan lokasi yang sepatutnya dituju, dan anda perlu mencari cincang yang betul untuk menggantikannya dahulu, yang mungkin agak menjengkelkan. git log -p -reverse ORIG_HEAD --preserve-mergesJawapan di atas akhirnya menggambarkan satu perkara Kerumitan realiti akan sentiasa melebihi imaginasi anda apabila anda seorang pemula Jika anda benar-benar ingin menggunakan git dengan baik, anda mesti memahami prinsip kerja git berdasarkan kerja harian. , anda boleh membaca e-book laman web rasmi (versi Cina Selepas membaca dengan teliti bahagian dalaman git di dalamnya, anda akan tahu arahan yang hendak digunakan).

Mata tambahan: Jika pasukan anda tidak mengambil berat tentang banyak rekod komit campur tangan yang tidak penting pada cawangan batang, maka anda sentiasa boleh menggunakan rebase, supaya sekurang-kurangnya tidak akan terdapat banyak garpu, dan ia boleh bersih jika dikendalikan dengan betul (tetapi ia adalah verbose) sejarah cawangan batang.

Tidak wajib, tetapi semua ujian dikehendaki berwarna hijau selepas menolak

(Kami tidak mempunyai cawangan yang sangat panjang, kebanyakannya digabungkan dalam masa 2-3 hari, jarang melebihi seminggu)

Biasanya semua orang memilih berdasarkan kesukaran cantuman Jika tiada perbezaan, rebase akan diutamakan... sebab nampak lebih bagus