Rumah > Soal Jawab > teks badan
git整合分支一般有两种方法——变基操作(git rebase)和合并操作(git merge),但是在你们实际的团队开发中,哪种方式用的最多,或者你们觉得那个好呢?
天蓬老师2017-05-02 09:46:25
Saya rasa realitinya begini:
Sekurang-kurangnya separuh daripada orang yang menggunakan git tidak tahu cara menggunakan rebase (walaupun untuk fungsi asas) (anggaran ini mungkin sangat konservatif)
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:
Apabila anda pergi dari jauh ke pull
, sentiasa gunakan rebase (dengan satu pengecualian, dibincangkan kemudian)
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:
Selepas anda menggunakan git merge
untuk melengkapkan gabungan cawangan ciri ke cawangan batang (sudah tentu --no-ff
)
Apabila anda menjalankan git fetch
, anda mendapati bahawa batang jauh adalah beberapa komit di hadapan anda
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:
Selepas melengkapkan cawangan ciri, jangan gabung, tetapi kembali ke cawangan utama git pull --rebase
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)
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——
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
git pull
sama sekali (saya sering menggunakan persekitaran CLI/ Switch antara GUI menggunakan git) git pull
git rebase -p
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-merges
Jawapan 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.
淡淡烟草味2017-05-02 09:46:25
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