git rebase ialah penulisan semula sejarah komit. Apabila sejarah komit yang ingin anda tulis semula belum diserahkan kepada repo jauh, iaitu sebelum ia dikongsi dengan orang lain, sejarah komit adalah peribadi kepada anda, jadi anda boleh menulis semula mengikut kehendak anda. .
Apabila ia diserahkan kepada alat kawalan jauh, jika anda menulis semula sejarah, ia pasti akan berbeza daripada sejarah orang lain. git push, git akan membandingkan sejarah komit Jika ia tidak konsisten, tindakan komit akan ditolak sejarah committer, oleh itu Lengkapkan penyerahan kod. Walaupun kod telah diserahkan, ini boleh menyebabkan kehilangan kerja orang lain, jadi gunakan parameter -f dengan berhati-hati. -f
Masalah yang dihadapi oleh poster asal adalah disebabkan oleh penulisan semula sejarah komitmen awam. Untuk menyelesaikan masalah ini, kita perlu menyeragamkan proses penyerahan.
Beri saya contoh proses yang betul:
Andaikan terdapat dua pembangun dalam pasukan poster: Tom dan Jerry Mereka bersama-sama menggunakan repo jauh dan mengklonkannya ke mesin mereka sendiri, diandaikan hanya terdapat satu cabang:
. master
Pada masa ini, repo mesin tom mempunyai dua cabang
, masterorigin/master
Mesin Jerry juga mempunyai dua cawangan
, masterorigin/master
Kedua-duanya ditunjukkan dalam gambar di bawah
Tom dan Jerry masing-masing membangunkan ciri baharu mereka sendiri, dan komitmen baharu sentiasa diserahkan kepada sejarah komitmen peribadi masing-masing, jadi petunjuk utama mereka terus bergerak ke hadapan, menunjuk kepada komitmen yang berbeza. Dan kerana tiada seorang pun daripada mereka mempunyai
dan git fetch, git push mereka kekal tidak berubah. origin/master
Repo Jerry adalah seperti berikut
Repo Tom adalah seperti berikut. Ambil perhatian bahawa
dan T1 dalam gambar di atas adalah dua komitmen yang berbeza J1
Pada masa ini, Tom mula-mula menyerahkan komitmennya ke repo jauh, kemudian penuding
tempatannya akan maju dan konsisten dengan penuding origin/master, seperti berikut master
Repo jauh adalah seperti berikut
Sekarang Jerry juga mahu menyerahkan komitnya ke repo jauh, jalankan git push, dan ia gagal tanpa sebarang kejutan, jadi dia git fetch melakukannya dan meletakkan repo jauh, yang telah diserahkan oleh Tom sebelum T1 Ia telah ditarik ke repo tempatannya, seperti berikut
Sejarah komit telah bercabang-cabang Jika anda ingin memasukkan kandungan yang sebelum ini diserahkan oleh Tom ke dalam kerja anda sendiri, salah satu caranya ialah dengan git merge, yang secara automatik akan menjana komitmen yang merangkumi penyerahan Tom dan komit Jerry menggabungkan dua komit bercabang kembali bersama. Walau bagaimanapun, komitmen yang dijana secara automatik ini akan mempunyai dua ibu bapa Apabila menyemak kod, ia mesti dibandingkan dua kali, yang sangat menyusahkan.
Untuk memastikan kelinearan sejarah komit, jerry memutuskan untuk menggunakan kaedah lain, iaitu git rebase. Komit Jerry J1 belum diserahkan kepada repo jauh pada masa ini, yang merupakan komitmen yang sepenuhnya peribadi kepadanya, jadi tiada masalah menggunakan git rebase untuk menulis semula sejarah J1 Selepas menulis semula, ia akan menjadi seperti berikut
Perhatikan bahawa J1 telah ditulis semula selepas T1 dan menjadi J1`
Selepas
git push, repo tempatan
Dan repo jauh
Sangat santai, garis lurus, tiada apa-f
Jadi, jika anda ingin memastikan pokok itu kemas tanpa menggunakan -f, kaedahnya ialah: sebelum git push, dahulu git fetch, kemudian git rebase.
git fetch origin master
git rebase origin/master
git push
Dengan cara ini, rebase akan digunakan secara automatik apabila mengemas kini kod (pull) dan bukannya menjana komit gabungan, melainkan terdapat situasi lain, seperti konflik yang disebabkan oleh penggabungan tiga pihak yang memerlukan campur tangan. Selalunya ia sangat pintar asalkan tabiat dalam pasukan itu baik, maka bentuk pokok yang sangat bersih dan cantik dapat dikekalkan.
Sebenarnya, terdapat banyak cara untuk menjadikan struktur pokok lebih cantik dan jelas, tetapi ia bergantung pada jenis Model Git yang digunakan oleh pasukan, dan anda hanya boleh menetapkan ubat yang betul. Tidak ada cara untuk merumuskannya di sini.
Selain itu, orang di atas betul, gunakannya dengan berhati-hati push -f!
Ini sepatutnya menjadi masalah aliran kerja git Pasukan kami telah menggunakan rebase untuk memastikan kebersihan maklumat komit, tetapi kami tidak akan menggunakan operasi seperti push -f.
Mengenai aliran kerja git, anda boleh membaca artikel berikut dan mencari artikel yang sesuai dengan pasukan anda. Tetapi perkara yang paling penting ialah memastikan semua orang dalam pasukan terbiasa dengan git.
Bina petunjuk sejarah Git yang bersih
Model percabangan Git yang berjaya yang diedarkan secara meluas
Aliran kerja Github
Jika anda menggunakan github untuk kerja berpasukan, gunakan permintaan tarik dengan baik, ia boleh menyelesaikan push -fmasalah bodoh ini!
Semua orang harus menyandarkan semula pengubahsuaian mereka kepada kod pelayan terkini sebelum menyerahkan tiada masalah jika anda mengikut peraturan ini. Jika anda memerlukan tolakan paksa, ini bermakna anda melakukannya secara sebaliknya.
Adalah disyorkan untuk merujuk kepada bab mengenai rebase dalam Pro Git http://git-scm.com/book/zh/Git-%E5%88%86%E6%94%AF-%E5%88% 86%E6% 94%AF%E7%9A%84%E8%A1%8D%E5%90%88
Risiko penjanaan semula
Nah, terbitan yang indah itu tidak sempurna untuk menggunakannya, anda mesti mematuhi satu peraturan:
Setelah objek komit dalam cawangan diterbitkan ke gudang awam, jangan sekali-kali meletakkan semula cawangan itu.
Jika anda mengikuti peraturan emas ini, tiada apa yang boleh menjadi salah. Jika tidak, orang ramai akan membenci anda, dan rakan serta keluarga anda akan mentertawakan anda dan menolak anda.
Setahu saya. Jika anda perlu menggunakan push -f selepas rebase, ini mesti bermakna operasi rebase tidak sesuai. Melainkan anda berhasrat untuk mengubah suai sejarah komit.
Jawapan di atas semuanya betul secara peribadi, melainkan anda seorang sahaja yang bekerja di cawangan tertentu, tidak akan ada masalah tidak kira bagaimana anda membuat rebase, tetapi jika anda berada dalam master. atau kembangkanApabila anda membina semula cawangan jenis ini, dianggarkan semua orang dalam pasukan mahu mengalahkan anda hingga mati, terutamanya rakan sepasukan yang tidak biasa dengan git.
Hanya ada satu situasi di mana push -f ditolak selepas rebase, iaitu subjek mengalami gangguan obsesif-kompulsif seperti saya, dan takut akan perkara yang menyakitkan seperti masa mati komputer dan sistem ranap (sejarah tragis darah dan tears), dan selepas melengkapkan komit ciri, tolaknya dengan cepat ke Alat kawalan jauh hanya milik cawangan anda Untuk mendapatkan ciri baharu pembangunan, anda membina semula pada cawangan anda sendiri setiap hari dan melakukan operasi tolak berulang kali Secara peribadi, saya rasa tidak ada masalah lagi, anda hanya menjejaskan diri sendiri (dan anda tahu ia betul).
Secara peribadi, saya fikir adalah tidak munasabah untuk menggunakan rebase apabila anda bekerja sebagai satu pasukan di cawangan tertentu. Dan mudah tersilap. Gunakan dengan berhati-hati tekan --kuat
Git rebase biasanya digunakan apabila membangunkan secara bersendirian untuk memastikan rekod penyerahan bersih. Setelah dimuat naik ke github, anda tidak sepatutnya menggunakan git rebase, jika tidak anda akan dimarahi hingga mati.
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
git rebaseialah penulisan semula sejarah komit. Apabila sejarah komit yang ingin anda tulis semula belum diserahkan kepada repo jauh, iaitu sebelum ia dikongsi dengan orang lain, sejarah komit adalah peribadi kepada anda, jadi anda boleh menulis semula mengikut kehendak anda. .Apabila ia diserahkan kepada alat kawalan jauh, jika anda menulis semula sejarah, ia pasti akan berbeza daripada sejarah orang lain.
git push, git akan membandingkan sejarah komit Jika ia tidak konsisten, tindakan komit akan ditolak sejarah committer, oleh itu Lengkapkan penyerahan kod. Walaupun kod telah diserahkan, ini boleh menyebabkan kehilangan kerja orang lain, jadi gunakan parameter-fdengan berhati-hati.-fMasalah yang dihadapi oleh poster asal adalah disebabkan oleh penulisan semula sejarah komitmen awam. Untuk menyelesaikan masalah ini, kita perlu menyeragamkan proses penyerahan.
Beri saya contoh proses yang betul:
Andaikan terdapat dua pembangun dalam pasukan poster: Tom dan Jerry Mereka bersama-sama menggunakan repo jauh dan mengklonkannya ke mesin mereka sendiri, diandaikan hanya terdapat satu cabang:.
Pada masa ini, repo mesin tom mempunyai dua cabangmaster
Kedua-duanya ditunjukkan dalam gambar di bawah,
masterorigin/masterMesin Jerry juga mempunyai dua cawangan,
masterorigin/master
Tom dan Jerry masing-masing membangunkan ciri baharu mereka sendiri, dan komitmen baharu sentiasa diserahkan kepada sejarah komitmen peribadi masing-masing, jadi petunjuk utama mereka terus bergerak ke hadapan, menunjuk kepada komitmen yang berbeza. Dan kerana tiada seorang pun daripada mereka mempunyaidan
Repo Jerry adalah seperti berikutgit fetch,git pushmereka kekal tidak berubah.origin/master
Repo Tom adalah seperti berikut. Ambil perhatian bahawadan
T1dalam gambar di atas adalah dua komitmen yang berbezaJ1
Pada masa ini, Tom mula-mula menyerahkan komitmennya ke repo jauh, kemudian penudingtempatannya akan maju dan konsisten dengan penuding
origin/master, seperti berikutmaster
Repo jauh adalah seperti berikutSekarang Jerry juga mahu menyerahkan komitnya ke repo jauh, jalankan
git push, dan ia gagal tanpa sebarang kejutan, jadi diagit fetchmelakukannya dan meletakkan repo jauh, yang telah diserahkan oleh Tom sebelumT1Ia telah ditarik ke repo tempatannya, seperti berikutSejarah komit telah bercabang-cabang Jika anda ingin memasukkan kandungan yang sebelum ini diserahkan oleh Tom ke dalam kerja anda sendiri, salah satu caranya ialah dengan
git merge, yang secara automatik akan menjana komitmen yang merangkumi penyerahan Tom dan komit Jerry menggabungkan dua komit bercabang kembali bersama. Walau bagaimanapun, komitmen yang dijana secara automatik ini akan mempunyai dua ibu bapa Apabila menyemak kod, ia mesti dibandingkan dua kali, yang sangat menyusahkan.Untuk memastikan kelinearan sejarah komit, jerry memutuskan untuk menggunakan kaedah lain, iaitu
git rebase. Komit JerryJ1belum diserahkan kepada repo jauh pada masa ini, yang merupakan komitmen yang sepenuhnya peribadi kepadanya, jadi tiada masalah menggunakangit rebaseuntuk menulis semula sejarahJ1Selepas menulis semula, ia akan menjadi seperti berikutPerhatikan bahawa
SelepasJ1telah ditulis semula selepasT1dan menjadiJ1`git push, repo tempatanDan repo jauh
Sangat santai, garis lurus, tiada apa
-fJadi, jika anda ingin memastikan pokok itu kemas tanpa menggunakan
-f, kaedahnya ialah: sebelumgit push, dahulugit fetch, kemudiangit rebase.Bacaan yang sangat disyorkan
Melainkan anda seorang sahaja yang menggunakannya, sesiapa yang menggunakan
push --forceharus mati.Pengikatan (penjejakan) cawangan tempatan dan cawangan terpencil, serta strategi pangkalan semula:
Dengan cara ini, rebase akan digunakan secara automatik apabila mengemas kini kod (
pull) dan bukannya menjana komit gabungan, melainkan terdapat situasi lain, seperti konflik yang disebabkan oleh penggabungan tiga pihak yang memerlukan campur tangan. Selalunya ia sangat pintar asalkan tabiat dalam pasukan itu baik, maka bentuk pokok yang sangat bersih dan cantik dapat dikekalkan.Sebenarnya, terdapat banyak cara untuk menjadikan struktur pokok lebih cantik dan jelas, tetapi ia bergantung pada jenis Model Git yang digunakan oleh pasukan, dan anda hanya boleh menetapkan ubat yang betul. Tidak ada cara untuk merumuskannya di sini.
Selain itu, orang di atas betul, gunakannya dengan berhati-hati
push -f!Ini sepatutnya menjadi masalah aliran kerja git Pasukan kami telah menggunakan rebase untuk memastikan kebersihan maklumat komit, tetapi kami tidak akan menggunakan operasi seperti
push -f.Mengenai aliran kerja git, anda boleh membaca artikel berikut dan mencari artikel yang sesuai dengan pasukan anda. Tetapi perkara yang paling penting ialah memastikan semua orang dalam pasukan terbiasa dengan git.
Jika anda menggunakan github untuk kerja berpasukan, gunakan permintaan tarik dengan baik, ia boleh menyelesaikan
push -fmasalah bodoh ini!Semua orang harus menyandarkan semula pengubahsuaian mereka kepada kod pelayan terkini sebelum menyerahkan tiada masalah jika anda mengikut peraturan ini. Jika anda memerlukan tolakan paksa, ini bermakna anda melakukannya secara sebaliknya.
Adalah disyorkan untuk merujuk kepada bab mengenai rebase dalam Pro Git http://git-scm.com/book/zh/Git-%E5%88%86%E6%94%AF-%E5%88% 86%E6% 94%AF%E7%9A%84%E8%A1%8D%E5%90%88
Setahu saya. Jika anda perlu menggunakan
push -fselepas rebase, ini mesti bermakna operasi rebase tidak sesuai. Melainkan anda berhasrat untuk mengubah suai sejarah komit.Tidak perlu menolak -f Jika cawangan ketinggalan, gunakan pull --rebase
Jawapan di atas semuanya betul secara peribadi, melainkan anda seorang sahaja yang bekerja di cawangan tertentu, tidak akan ada masalah tidak kira bagaimana anda membuat rebase, tetapi jika anda berada dalam master. atau kembangkanApabila anda membina semula cawangan jenis ini, dianggarkan semua orang dalam pasukan mahu mengalahkan anda hingga mati, terutamanya rakan sepasukan yang tidak biasa dengan git.
Hanya ada satu situasi di mana push -f ditolak selepas rebase, iaitu subjek mengalami gangguan obsesif-kompulsif seperti saya, dan takut akan perkara yang menyakitkan seperti masa mati komputer dan sistem ranap (sejarah tragis darah dan tears), dan selepas melengkapkan komit ciri, tolaknya dengan cepat ke Alat kawalan jauh hanya milik cawangan anda Untuk mendapatkan ciri baharu pembangunan, anda membina semula pada cawangan anda sendiri setiap hari dan melakukan operasi tolak berulang kali Secara peribadi, saya rasa tidak ada masalah lagi, anda hanya menjejaskan diri sendiri (dan anda tahu ia betul).
Secara peribadi, saya fikir adalah tidak munasabah untuk menggunakan rebase apabila anda bekerja sebagai satu pasukan di cawangan tertentu. Dan mudah tersilap. Gunakan dengan berhati-hati tekan --kuat
Git rebase biasanya digunakan apabila membangunkan secara bersendirian untuk memastikan rekod penyerahan bersih. Setelah dimuat naik ke github, anda tidak sepatutnya menggunakan git rebase, jika tidak anda akan dimarahi hingga mati.