Puluhan gambar animasi memberitahu anda cara Git berfungsi

git merge, git rebase, git reset, git revert, git fetch, git pull, git reflog... Adakah anda tahu apakah tugas yang dilakukan oleh arahan git ini? Jika anda masih kurang jelas, jangan lepaskan artikel ini. Dalam artikel ini, Lydia Hallie, seorang perunding perisian berusia 21 tahun yang biasa dengan JavaScript, TypeScript, GraphQL, Serverless, AWS, Docker dan Golang, secara intuitif memperkenalkan proses kerja arahan git yang biasa digunakan ini dalam bentuk animasi, memastikan anda tidak akan melupakan mereka.

Walaupun Git adalah alat yang sangat berkuasa, kebanyakan orang akan bersetuju dengan saya jika saya mengatakan bahawa Git adalah mimpi ngeri untuk digunakan. Saya mendapati ia sangat membantu apabila bekerja dengan Git untuk memvisualisasikannya dalam kepala saya: apabila saya melaksanakan arahan tertentu, bagaimanakah cawangan ini akan berinteraksi dan bagaimana ia akan mempengaruhi sejarah? Mengapakah rakan sekerja saya menangis apabila saya melakukan but semula keras pada induk, tolak paksa ke cawangan asal dan rimraf folder .git kami?

Saya fikir mencipta contoh visual beberapa arahan Git yang paling biasa digunakan dan berguna akan menjadi kes penggunaan yang sempurna! Banyak arahan yang saya akan terangkan di bawah mempunyai parameter pilihan - anda boleh menggunakan parameter ini untuk menukar tingkah laku arahan yang sepadan. Dan contoh saya hanya akan merangkumi kelakuan lalai arahan dan tidak akan menambah (atau menambah terlalu banyak) konfigurasi pilihan!

Gabung

Adalah mudah untuk mempunyai berbilang cawangan untuk mengasingkan perubahan baharu yang berbeza antara satu sama lain dan juga untuk memastikan anda tidak menolak perubahan yang tidak disengajakan atau kod pengeluaran yang dibenarkan secara tidak sengaja . Tetapi setelah perubahan ini diluluskan, kami perlu mengerahkannya ke cawangan pengeluaran kami!

Salah satu cara untuk menggabungkan perubahan dari satu cawangan ke cawangan lain adalah dengan melakukan gabungan git. Git boleh melakukan dua jenis cantuman: maju pantas dan tidak maju pantas. Anda mungkin tidak dapat membezakannya sekarang, tetapi mari kita lihat perbezaannya sebentar lagi.

Fast-forward (—ff)

Fast-forward merge boleh dilakukan apabila cawangan semasa tidak mempunyai komit tambahan berbanding cawangan yang kita ingin gabungkan. Git malas dan akan mencuba pilihan paling mudah dahulu: ke hadapan pantas! Gabungan jenis ini tidak mencipta komitmen baharu, sebaliknya menggabungkan komitmen pada cawangan yang kami gabungkan terus ke cawangan semasa.

Sempurna! Sekarang, semua perubahan yang kami buat pada cawangan dev digabungkan ke dalam cawangan induk. Jadi apakah maksud tidak maju pantas?

No-fast-foward (—no-ff)

Jika cawangan semasa anda tidak mempunyai sebarang komitmen berbanding cawangan yang anda ingin gabungkan, itu tidak mengapa realitinya jarang macam ni! Jika kita melakukan perubahan pada cawangan semasa yang tidak berada dalam cawangan yang ingin kita gabungkan, git akan melakukan gabungan tanpa ke hadapan pantas.

Apabila bergabung menggunakan no-fast-forward, Git akan mencipta komitmen penggabungan baharu pada cawangan yang sedang aktif. Komit induk bagi komit ini menghala ke cawangan aktif ini dan juga menunjukkan ke cawangan yang ingin kami gabungkan!

Tiada masalah besar, gabungan sempurna! Sekarang, semua perubahan yang kami buat pada cawangan dev digabungkan ke dalam cawangan induk. . Apabila dua cawangan yang kami ingin gabungkan mempunyai pengubahsuaian yang berbeza pada baris kod yang sama dalam fail yang sama, atau satu cawangan memadamkan fail dan cawangan lain mengubah suai fail, Git tidak tahu apa yang harus dipilih.

Dalam kes ini, Git akan bertanya kepada anda pilihan mana yang ingin anda simpan? Andaikan bahawa dalam kedua-dua cawangan, kami mengedit baris pertama README.md.

Sekiranya kita ingin menggabungkan dev menjadi master, akan berlaku konflik gabungan: Adakah anda mahu tajuk itu Hello atau Hey!?

Apabila cuba menggabungkan cawangan ini, Git akan menunjukkan kepada anda tempat konflik berlaku. Kami boleh mengalih keluar secara manual perubahan yang kami tidak mahu simpan, menyimpan perubahan, menambah fail yang diubah suai sekali lagi dan melakukan perubahan.

Selesai! Walaupun konflik gabungan sering menjengkelkan, ia masuk akal: Git tidak perlu meneka perubahan yang ingin kami kekalkan.

Rebasing

Kami baru sahaja melihat bahawa anda boleh memohon perubahan dari satu cawangan ke cawangan lain dengan melaksanakan git merge. Satu lagi cara untuk menggabungkan perubahan dari satu cawangan ke yang lain adalah dengan melakukan git rebase.

git rebase akan menyalin komit cawangan semasa ke cawangan yang ditentukan.

Sempurna, kini kami mempunyai semua perubahan pada cawangan induk pada cawangan dev.

Terdapat satu perbezaan utama antara pengasingan semula dan penggabungan: Git tidak cuba menentukan fail yang hendak disimpan atau tidak. Cawangan yang kami asaskan semula sentiasa mengandungi perubahan terbaharu yang ingin kami simpan! Dengan cara ini kita tidak menghadapi sebarang konflik gabungan dan mengekalkan sejarah Git yang bagus dan linear.

Contoh di atas menunjukkan rebasing pada cawangan induk. Walau bagaimanapun, dalam projek yang lebih besar, anda biasanya tidak perlu melakukan ini. git rebase mengubah suai sejarah projek apabila mencipta cincang baharu untuk komit yang disalin.

Jika anda sedang membangunkan cawangan ciri dan cawangan induk telah dikemas kini, rebasing sangat berguna. Anda boleh mendapatkan semua kemas kini pada cawangan anda, yang menghalang konflik gabungan pada masa hadapan.

Interactive Rebase

Sebelum melaksanakan rebase untuk commit, kami boleh mengubah suainya! Kami boleh menggunakan asas semula interaktif untuk menyelesaikan tugas ini. Asas semula interaktif berguna apabila anda berada di cawangan yang sedang anda bangunkan dan ingin mengubah suai komitmen tertentu.

Pada komit yang kami rebaskan, kami boleh melakukan 6 tindakan berikut:

• kata semula: ubah suai maklumat komit;🜎 jika komitmen ini

• skuasy: gabungkan komit ke dalam komit sebelumnya; arahan yang ingin kami asaskan semula pada komit;

Hebat! Dengan cara ini kita mempunyai kawalan penuh ke atas komitmen kita. Jika anda ingin mengalih keluar komit, lepaskan sahaja.

Jika anda ingin menggabungkan berbilang komitmen bersama untuk mendapatkan sejarah komitmen yang jelas, itu tidak menjadi masalah!

Rebase interaktif memberi anda banyak kawalan semasa membuat asas semula, walaupun ke atas cawangan yang sedang aktif.

Menetapkan semula

Arahan ini digunakan apabila kita tidak mahu perubahan yang diserahkan sebelum ini. Mungkin ini adalah komit WIP atau mungkin ia adalah komit yang memperkenalkan pepijat, dalam hal ini anda perlu melakukan tetapan semula git. Tetapan semula

git membolehkan kami tidak lagi menggunakan fail pada desktop semasa dan membolehkan kami mengawal ke mana HEAD harus menunjuk.

Tetapan semula lembut

Tetapan semula lembut akan mengalihkan HEAD ke komit yang ditentukan (atau indeks komit berbanding HEAD) tanpa mengalih keluar perubahan yang ditambahkan selepas komit itu!

Katakan kami tidak mahu mengekalkan komit 9e78i, yang menambahkan fail style.css, dan kami juga tidak mahu mengekalkan komit 035cc, yang menambahkan fail index.js. Walau bagaimanapun, kami mahu mengekalkan fail style.css dan index.js yang baru ditambah! Ini adalah kes penggunaan yang sempurna untuk tetapan semula lembut.

Selepas menaip status git, anda akan melihat bahawa kami masih mempunyai akses kepada semua perubahan yang dibuat pada komitmen sebelumnya. Ini bagus, ini bermakna kita boleh membetulkan kandungan fail ini dan menyerahkannya semula kemudian!

Tetapan semula keras

Kadang-kadang kita tidak mahu mengekalkan perubahan yang diperkenalkan oleh komitmen tertentu. Tidak seperti tetapan semula lembut, kita tidak sepatutnya perlu mengaksesnya lagi. Git hanya perlu menetapkan semula keadaan keseluruhan terus kepada keadaan sebelum komit tertentu: ini termasuk perubahan yang anda buat dalam direktori kerja dan pada fail pementasan.

Git membuang perubahan yang diperkenalkan oleh 9e78i dan 035cc dan menetapkan semula keadaan kepada keadaan ec5be.

Membalikkan

Cara lain untuk membuat asal perubahan adalah dengan melakukan git revert. Dengan melakukan operasi berbalik pada komit tertentu, kami membuat komit baharu yang mengandungi perubahan yang dibalikkan.

Katakan ec5be menambah fail index.js. Tetapi kemudian kami mendapati bahawa kami tidak lagi memerlukan perubahan yang diperkenalkan oleh komitmen ini. Kemudian pulihkan penyerahan ec5be!

Sempurna! Commit 9e78i mengembalikan perubahan yang diperkenalkan oleh commit ec5be . git revert berguna apabila membuat asal komit tertentu tanpa mengubah suai sejarah cawangan. . Apabila memilih komit ceri, kami mencipta komit baharu pada cawangan aktif yang mengandungi perubahan yang diperkenalkan oleh komit yang dipilih.

Katakan komit 76d12 pada cawangan dev menambah perubahan pada fail index.js, dan kami mahu menyepadukannya ke dalam cawangan induk. Kami tidak mahu seluruh cawangan dev, hanya komitmen ini!

Kini cawangan induk mengandungi perubahan yang diperkenalkan oleh 76d12.

Mengambil

Jika anda mempunyai cawangan Git terpencil, seperti cawangan di GitHub, anda boleh menggunakan perolehan semula apabila cawangan jauh mengandungi komit yang tidak dimiliki oleh cawangan semasa. Seperti apabila cawangan lain digabungkan atau rakan sekerja anda melakukan pembetulan pantas.

Dengan melaksanakan git fetch pada cawangan terpencil ini, kita boleh mendapatkan perubahan ini secara setempat. Ini tidak menjejaskan cawangan tempatan anda dalam apa jua cara: ambil hanya memuat turun data baharu.

Sekarang kita boleh lihat semua pengubahsuaian sejak tolakan terakhir. Data baharu kini adalah setempat, dan kami boleh memutuskan perkara yang perlu dilakukan dengannya.

Pulling

Walaupun git fetch boleh digunakan untuk mendapatkan maklumat jauh cawangan, kita juga boleh melakukan git pull. git pull sebenarnya dua arahan digabungkan menjadi satu: git fetch dan git merge. Apabila kami menarik perubahan daripada sumber, kami mula-mula mendapatkan semula semua data seperti git fetch, dan kemudian perubahan terkini digabungkan secara automatik ke dalam cawangan tempatan.

Bagus, kami kini sangat selaras dengan cawangan terpencil dan mempunyai semua pengubahsuaian terkini juga!

Reflog

Semua orang buat kesilapan, tetapi silap tidak mengapa! Kadangkala anda mungkin berasa seperti anda telah merosakkan repo git anda sepenuhnya, membuatkan anda mahu memadamkannya sepenuhnya.

git reflog ialah arahan yang sangat berguna yang boleh memaparkan log semua tindakan yang telah dilakukan. Ini termasuk gabungan, set semula, kembalikan, pada asasnya sebarang perubahan yang anda buat pada cawangan anda.

Jika anda membuat kesilapan, anda boleh melakukannya semula dengan mudah dengan menetapkan semula HEAD berdasarkan maklumat yang diberikan oleh reflog!

Katakan kita sebenarnya tidak perlu menggabungkan cawangan asal. Apabila kita melaksanakan perintah git reflog, kita dapat melihat bahawa status repo ini berada di HEAD@{1} sebelum gabungan. Kemudian kami melakukan tetapan semula git dan ubah hala HEAD ke lokasi HEAD@{1}.

Kita dapat lihat bahawa tindakan terbaru telah ditolak ke reflog.

Atas ialah kandungan terperinci Puluhan gambar animasi memberitahu anda cara Git berfungsi. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!