Rumah >alat pembangunan >git >Belum bermain dengan Git lagi? Susun sekarang!

Belum bermain dengan Git lagi? Susun sekarang!

藏色散人
藏色散人ke hadapan
2022-11-09 16:09:292032semak imbas

Artikel ini disediakan oleh lajur Git Tutorial untuk memperkenalkan kepada anda cara mengendalikan Git, yang sangat terperinci! Di bawah ini saya akan membawa anda belajar cara bermain dengan Git. Saya harap ia akan membantu rakan-rakan yang memerlukannya.

Belum bermain dengan Git lagi? Susun sekarang!

Kata Pengantar

Pada malam yang gelap dan berangin, teman wanita saya dengan wajah sedih tiba-tiba memberitahu saya bahawa dia tidak dapat memahami Git pengalaman yang lebih baik? Sudah terlambat untuk mengatakannya, tetapi dengan pantas untuk mengatakannya Tanpa berkata apa-apa, saya segera mula menulis dan menulis...

Dalam proses pengekodan biasa, kita masih perlu melakukan sesuatu. . Keupayaan untuk mengendalikan Git. Tetapi masih terdapat beberapa senario di mana saya tiba-tiba tidak dapat mengingati arahan Git yang harus digunakan untuk memenuhi keperluan saya dalam senario tertentu Pada masa ini, saya perlu membuka Google/Baidu dan mencari pelbagai, dan bukannya membuang masa untuk perkara ini lagi dan sekali lagi. Dalam kerja berulang, adalah lebih baik untuk mengkaji permainan arahan yang biasa kami gunakan. Di sini, artikel ini juga akan menyediakan satu siri kes untuk memperkenalkan senario aplikasi dan penggunaan umum sistem dan arahan Git yang biasa digunakan ini.

Sudah tentu, selain mengetahui cara menggunakan arahan Git, kita juga harus memahami bagaimana keseluruhan seni bina Git, supaya kita boleh mempunyai pemahaman yang lebih jelas tentang perintah yang kita kendalikan setiap hari anda lakukan.

Jika ada ungkapan yang tidak sesuai, terima kasih kerana membetulkan saya!

Pengenalan kepada sistem Git

Mulakan dengan gambar, dan kesimpulannya bergantung pada tekaan.

Git 体系图

Pemahaman kawasan Git

  • 远程仓库区: Ini adalah destinasi terakhir penyerahan kod kami, tiada apa yang perlu dikatakan.
  • 远端分支本地副本: Ini sebenarnya menyimpan salinan setempat bagi setiap cawangan gudang jauh Anda boleh membuka fail .git di bawah projek Git anda, iaitu terutamanya disimpan di sini. Ini adalah maklumat cawangan gudang jauh Secara amnya, apabila anda melaksanakan tolak, tarik atau ambil, ia akan dikemas kini di sini.
  • 本地分支: Ini adalah kawasan yang sering kami hadapi Selepas anda melaksanakan komitmen, anda pada dasarnya menyerahkan kepada kawasan ini Anda boleh menyemak direktori rujukan/heads di bawah direktori .git anda, yang mengandungi direktori kami maklumat kod cawangan tempatan.
  • 暂存区: Kawasan ini adalah kawasan di mana kita akan menyimpannya setiap kali kita melaksanakan git add Ia digunakan untuk membuat cache dengan gudang tempatan Ia juga merupakan kawasan yang penting dari segi asas reka bentuk kawasan Git, yang boleh membantu Git meningkatkan prestasi carian apabila melakukan perbezaan.
  • 工作区: Ini biasanya tempat kami menulis kod, seperti projek yang anda buka dalam vscode, tempat anda boleh mengedit kod.

simpan

Selain itu, terdapat satu kawasan khas iaitu kawasan simpanan git tempatan untuk apa? Secara umumnya, anda mungkin menggunakannya dalam senario tertentu Kadangkala kami menukar kod secara setempat, tetapi tiba-tiba seseorang datang untuk bertanya kepada anda tentang cawangan lain Pada masa yang sama, anda melaksanakan fungsi tertentu, yang separuh dilaksanakan Tidak mahu menyerahkannya ke repositori Git, maka anda boleh mempertimbangkan untuk menggunakan git stash save "临时存一下" Pada masa ini, ia akan menyimpannya ke kawasan storan ini untuk anda. Anda boleh pergi ke cawangan lain untuk menyelesaikan kerja dan kembali maka git stash pop akan baik-baik saja.

Tetapi saya masih tidak mengesyorkan menggunakan fungsi ini, kerana suatu hari anda memotongnya dan kemudian memotongnya semula, melupakan storan ini, dan menulis sesuatu yang lain, maka anda akan ditipu sahaja . Sudah tentu, fungsi ini masih sangat berguna, tetapi ia perlu digunakan dengan berhati-hati.

Pemahaman aliran kerja mudah Git

Dalam kerja harian, proses interaksi yang kerap kita gunakan Git akan menjadi lebih kurang seperti ini (akan terdapat beberapa perbezaan di bawah spesifikasi yang berbeza, tetapi perbezaannya besar Tidak besar):

  1. Apabila keperluan baharu datang, kami akan menyemak cawangan ciri baharu daripada induk untuk pembangunan.
  2. Selepas membangunkan titik fungsi tertentu, kami akan melaksanakan git add untuk menyerahkan kod ke kawasan pementasan.
  3. Laksanakangit commit Hantar kod ke repositori tempatan
  4. Laksanakangit push Hantar kod ke cawangan terpencil
  5. Selepas kami membangunkan semua keperluan, kami boleh menetapkan up Cawangan ujian khusus, seperti cawangan bernama dev, kemudian kami menggabungkan kod ke dalam cawangan ujian ini dan melepaskan persekitaran ujian untuk ujian.
  6. Selepas ujian, kami perlu menggabungkan kod Pada masa ini, kami boleh memulakan permintaan gabungan untuk menggabungkan kod kami ke dalam cawangan induk melalui proses CR.
  7. Dalam proses menyerahkan MR, secara amnya kami perlu menggabungkan kod cawangan induk ke dalam cawangan yang kini perlu digabungkan, menyerahkan dan menyelesaikan konflik.

Proses di atas secara kasarnya meringkaskan proses aliran Git umum Syarikat yang berbeza mungkin mereka spesifikasi mereka sendiri, jadi saya tidak akan memberikan terlalu banyak arahan di sini.

Gambaran Keseluruhan Perintah

  • git stash
  • git clone
  • git init
  • git remote
  • git branch
  • git checkout
  • git add
  • git commit
  • git rm
  • git push
  • git pull
  • git fetch
  • git merge
  • git log
  • git reset
  • git reflog
  • git revert
  • git cherry-pick
  • git tag
  • git rebase
Pada pandangan pertama, saya terpesona dan memutuskan untuk berputus asa dan menggunakan alat visualisasi sebaliknya. Jangan panik, biarkan penulis menerangkannya kepada anda.

Analisis Perintah

Secara umumnya, jika kita ingin menggunakan Git untuk menguruskan beberapa fail sumber secara setempat, kita perlu mempunyai gudang terlebih dahulu. Kaedah yang paling biasa digunakan ialah pergi ke Gitlab/Github untuk mencipta gudang, dan kemudian tariknya ke kawasan setempat Pada masa ini, kita boleh menggunakan arahan klon kami.

git stash (dimasukkan buat sementara waktu untuk pengenalan cepat)

Terdapat juga pengenalan awal untuk penggunaan arahan ini di atas, yang digunakan untuk menyimpan sementara perubahan kod yang tidak mahu Arahan biasa adalah seperti berikut:

  • : Simpan perubahan git stash save 'xxx'
  • : Lihat senarai semua komitmen dalam repositori git stash list
  • : Timbul dan gunakan komitmen terkini dalam penyerahan Kod repositorigit stash pop
  • : Padamkan rekod storan tertentugit stash drop stash@{n}
  • : Kosongkan semua maklumat simpanangit stash clear
Data akan disimpan dalam warehouse.git anda Dalam refs/stash di bawah fail.

klon git

Kaedah yang paling asas dan biasa digunakan ialah menggunakan terus

  • git clone xxx.git
supaya anda boleh dengan mudah Kod gudang telah ditarik secara tempatan, tetapi hanya mengetahui ini nampaknya tidak mencukupi. Secara amnya, jika kita mengklonkannya secara terus tanpa parameter, ia akan kekal dalam cawangan induk secara lalai Kadangkala kita masih memerlukan beberapa keperluan lain, seperti bagaimana untuk beralih secara automatik ke cawangan yang ditentukan selepas menariknya ke kawasan setempat?

  • git clone xxx.git -b branch1
Selepas kita mempunyai gudang, kita tidak boleh selalu melakukan sesuatu di cawangan induk Secara amnya, adakah kita perlu membuka cawangan baru ke tukar kod? Apabila semuanya selesai dan kemudian digabungkan ke induk, anda perlu menggunakan perintah cawangan git yang diperkenalkan di bawah Walau bagaimanapun, sebelum bercakap tentang operasi cawangan tertentu, pengarang masih perlu membuat proses pemulaan tempatan gudang.

git init

Selain membina gudang dari jauh, kadangkala kita juga boleh memulakan gudang Git secara setempat untuk operasi Pada masa ini, kita boleh menggunakan git init secara langsung untuk direktori semasa, dan anda boleh mula memasukkan perubahan pada direktori semasa ke dalam pustaka pengurusan versi.

Walau bagaimanapun, repositori init tempatan tidak boleh berinteraksi dengan repositori jauh, jadi kita masih perlu pergi ke github/gitlab untuk mencipta repositori jauh dan kemudian mengaitkannya, iaitu perintah

. git remote

git remote

digunakan untuk melaksanakan pemprosesan mengikat perhubungan dan operasi lain dengan gudang jauh.

  • : Tambah perkaitan repositori jauh git remote add
  • : Padamkan perkaitan repositori jauh git remote rm
Sebagai contoh, kami mempunyai satu perkaitan setempat The gudang yang dimulakan juga mempunyai gudang kosong terpencil yang dicipta, maka kita boleh melakukan operasi berikut untuk mengaitkannya:

  1. git remote add origin xxx.gitTambahkan ke gudang tempatan dahulu
  2. git push -u origin master: Maksudnya mengaitkan cawangan induk gudang semasa dengan cawangan induk gudang terpencil Nanti kita boleh perform tolak atau tarik Mudah untuk beroperasi.

cawangan git

Selepas mendapat projek, anda perlu melihat dahulu cawangan di gudang semasa Jangan buat cawangan baru kemudian dan mencari masalah seperti nama pendua . , maka pada masa ini kita boleh menggunakan git branch untuk melihat cawangan yang berkaitan.

  • git branch: Lihat semua maklumat cawangan tempatan
  • git branch -r: Lihat semua cawangan repositori jauh
  • git branch -a: Lihat semua cawangan tempatan dan repositori jauh

Secara umumnya, jika terdapat terlalu banyak cawangan, adalah disyorkan untuk menggunakan alatan visual untuk melihat maklumat cawangan, seperti vscode atau pokok sumber dan perisian lain.

Sudah tentu IDEA juga ada.

git checkout

Jika kita ingin mencipta cawangan baharu berdasarkan cawangan semasa dan beralih kepadanya, kita boleh menggunakan arahan berikut.

  • Buat dan tukar ke cawangan baharu yang ditentukan: git checkout -b branch1

git add

Selepas kami menukar kod dalam cawangan, kami mahu Serahkannya, maka langkah pertama yang perlu anda lakukan ialah melaksanakan git add

  • git add [file1] [file2]: tambah satu atau lebih fail ke kawasan pementasan

Secara umumnya , apabila kita biasanya menggunakannya, yang paling biasa digunakan hendaklah:

  • git add .: Tambahkan semua perubahan fail dalam direktori semasa ke kawasan storan sementara
  • git add -A : Tambah semua perubahan fail dalam gudang semasa ke kawasan storan sementara

Bagi pengarang, arahan git add -A adalah yang paling banyak digunakan, kerana dalam kebanyakan kes, Kita semua harus menambah semua perubahan pada kawasan pementasan Jika tidak, kemungkinan besar terlupa.

git commit

Selepas fail ditambah ke kawasan pementasan, kita boleh melakukan langkah seterusnya.

  • git commit [file1] ... -m [message]: Serahkan kandungan kawasan pementasan ke repositori versi git tempatan
    • -m mewakili maklumat yang diserahkan pada masa ini
    • -a untuk Untuk fail yang telah disertakan dalam pengurusan git (anda telah menyerahkan fail sebelum ini), maka arahan ini adalah sama dengan membantu anda melaksanakan git add -A di atas, dan anda tidak perlu menambahnya lagi untuk fail yang belum diuruskan oleh git (iaitu, Fail yang baru ditambah), maka anda masih perlu melaksanakan git add -A sebelum ia boleh dikomit ke perpustakaan git tempatan dengan betul.

Biasanya, kita harus menggunakan git commit -m 'feat: do something' lebih kerap untuk menetapkan maklumat yang diserahkan pada masa ini. Sudah tentu, jika anda tidak mempunyai permintaan kukuh yang git add dan git commit mesti dipisahkan, maka anda boleh memilih git commit -am, yang mudah dan pantas.

git rm

Ini sebenarnya agak berguna Sebagai contoh, terdapat fail bernama .env dalam projek kami dan tidak boleh diserahkan kepada alat kawalan jauh, tetapi kami telah Serahkan secara tidak sengaja ke gudang tempatan, kali ini kami menambah fail ini ke fail .gitignore, menunjukkan bahawa penyerahan perlu diabaikan oleh git, tetapi kerana kami telah menyerahkannya ke gudang tempatan, tidak ada gunanya jika kami tidak memadamkannya daripada gudang git dahulu.

Jika anda klik kanan untuk memadamkannya, rekod fail ini masih akan disimpan ke repositori jauh dan orang lain masih boleh melihat maklumat anda, jadi kami perlu memadamkan fail ini daripada repositori git dahulu.

  • git rm .env: Selepas melaksanakan arahan ini, ini bermakna fail .env telah dipadamkan daripada repositori git Bekerjasama dengan .gitignore, anda boleh memastikan bahawa semua fail .env akan datang perubahan tidak perlu risau untuk dihantar ke gudang jauh.

  • git rm -r dist: Jika kita mahu memadamkan direktori, cuma tambah parameter -r.

git push

Seterusnya kita mahu menolak cawangan yang baru dibuat ke hujung jauh Secara umumnya, kita mungkin perlu menggunakan git push, tetapi kita Ini adalah a cawangan baharu dan tidak mempunyai sambungan sama sekali dengan gudang jauh, jadi kami perlu menambah beberapa parameter untuk menyambungkannya:

  • Tolak cawangan dan wujudkan persatuan: git push --set-upstream origin branch1

Setelah selesai, kita boleh pergi ke gudang terpencil dan lihat dan kita akan dapati cawangan baru yang kita buat telah ditolak ke atas. Seterusnya, mungkin ada rakan-rakan yang ingin bertanya, bagaimana jika gudang terpencil itu sudah mempunyai nama cawangan ini?

Terdapat dua jenis di sini:

  1. Salah satunya ialah jika tiada konflik antara kod tempatan anda dan kod jauh, dan anda mempunyai penyerahan baharu secara setempat, anda masih boleh melaksanakan arahan di atas, yang akan menggabungkan secara langsung cawangan tempatan semasa dengan cawangan jauh Sambungkannya dan serahkan perubahan anda pada masa yang sama.
  2. Lainnya ialah terdapat konflik antara cawangan tempatan dan cawangan jauh Pada masa ini, apabila anda melaksanakan arahan di atas, gesaan konflik akan muncul cawangan jauh semasa dahulu dan selesaikan jika terdapat konflik, anda perlu menggunakan arahan git pull.

git pull

Biasanya, jika cawangan semasa telah mewujudkan sambungan dengan cawangan jauh, maka jika kita ingin menggabungkan cawangan jauh, kita hanya perlu melaksanakan git pull Okay, tidak perlu membawa parameter lain, tetapi jika terdapat percanggahan dengan git push yang disebutkan di atas dan sambungan belum diwujudkan, kita perlu menentukan cabang kod yang perlu ditarik ke bawah untuk digabungkan.

  • Tarik cawangan jauh yang ditentukan dan gabungkannya ke dalam cawangan semasa tempatan: git pull origin branch1

Asal di sini ialah nama kami untuk gudang jauh Anda boleh menukarnya jika anda mahu, tetapi asal biasanya digunakan.

Kembali kepada isu konflik yang disebutkan di atas, kita boleh terus menggunakan git pull dan kemudian menentukan cawangan jauh yang kita ingin gabungkan dengan cawangan tempatan semasa, kemudian menyelesaikan konflik secara setempat, kemudian menyerahkan perubahan, dan kemudian laksanakan git push --set-upstream origin branch1 Perintah telah selesai.

git fetch

Setelah memahami perintah git pull yang diterangkan di atas, arahan ini sebenarnya mudah untuk difahami pada masa tertentu, mungkin kita hanya mahu menukar cawangan gudang jauh yang sepadan Ia hanya ditarik secara tempatan, dan saya tidak mahu menggabungkannya secara automatik ke dalam ruang kerja saya (ruang kerja di mana anda sedang membuat perubahan kod, saya akan mempertimbangkan untuk menggabungkannya kemudian selepas saya selesai menulis bahagian tertentu kod, maka anda boleh). guna dulu git fetch.

Selepas pengambilan selesai, saya menyerahkan perubahan yang sedang saya kerjakan ke gudang tempatan, dan kemudian ingin menggabungkan perubahan pada cawangan terpencil Pada masa ini, laksanakan git merge origin/[当前分支名] (lalainya ialah untuk menggunakan asal untuk mewakili yang jauh) awalan cawangan).

git merge

Gabung kod cawangan yang ditentukan ke cawangan semasa. Secara umumnya, senario yang lebih kami gunakan mungkin cawangan induk gudang terpencil telah berubah, dan pada masa ini kami akan menyerahkan MR, jadi kami perlu menggabungkan kod induk terlebih dahulu, dan menyelesaikan konflik jika terdapat konflik. Pada masa ini kita boleh melakukan perkara berikut:

  1. Tukar ke cawangan induk, git tarik kod terkini
  2. Tukar kembali ke cawangan pembangunan, laksanakan git merge master untuk bergabung kod induk

Begitu juga, git merge origin/xxx yang diperkenalkan di atas juga digunakan dengan cara yang sama.

git log

Seperti namanya, ia bermaksud log Selepas melaksanakan arahan ini, kita boleh melihat maklumat rekod penyerahan cawangan semasa, seperti commitId dan perihalan masa penyerahan, dsb. , yang kira-kira selama Seperti ini:

commit e55c4d273141edff401cbc6642fe21e14681c258 (HEAD -> branch1, origin/branch1)
Author: 陌小路 <44311619+STDSuperman@users.noreply.github.com>
Date:   Mon Aug 1 23:16:11 2022 +0800

    Initial commit复制代码

Pada masa ini, sesetengah pembaca mungkin bertanya, untuk apa ini digunakan? cara yang lebih penting untuk menggunakannya adalah dengan menjalankan Jika anda ingin melancarkan versi kod atau melakukan operasi lain yang menarik, izinkan saya memberitahu anda serba sedikit mengenainya.

set semula git

  • set semula git [--lembut | --bercampur | --keras] [HEAD]

Tentang HEAD:

  • HEAD mewakili versi semasa
  • HEAD^ Versi sebelumnya
  • HEAD^^ Versi sebelumnya
  • HEAD^^^ Versi sebelumnya
  • HEAD~n tarik balik n versi, ini juga lebih mudah

Analisis parameter

Analisis berikut adalah berdasarkan parameter HEAD^ berikut, iaitu git reset HEAD^.

  • --soft: Tetapkan semula versi terbaharu anda yang diserahkan tanpa mengubah suai kawasan pementasan dan ruang kerja anda.
  • --mixed: Parameter lalai, digunakan untuk menetapkan semula fail dalam kawasan pementasan agar konsisten dengan komit terakhir (komit) dan kandungan fail ruang kerja kekal tidak berubah.
  • --hard: Tetapkan semula semua penyerahan kepada versi sebelumnya dan ubah suai ruang kerja anda Ia akan kembali sepenuhnya kepada versi penyerahan sebelumnya Anda tidak dapat melihat kod yang diserahkan pada masa ini, iaitu perubahan Ruang Kerja anda juga telah dibunuh.

Nampaknya ia tidak begitu mudah untuk difahami setelah bercakap lama-lama Mari kita gunakan contoh untuk memahami:

Contohnya:

    Saya menukar fail README saya, Terdapat perubahan dalam ruang kerja kami, tetapi ia belum diserahkan ke kawasan pementasan pada masa ini Dalam vscode, ia akan dipaparkan sebagai tanda pengubahsuaian ruang kerja
  1. dan. maka kami laksanakan
  2. Pada masa ini anda boleh melihat Dalam kawasan pementasan, anda akan mendapati bahawa perubahan ini telah diserahkan dan ditandakan oleh vscode sebagai telah diserahkan ke kawasan pementasan git add
  3. dan kemudian laksanakan
  4. . Pada masa ini, penyerahan telah selesai git commit
Seterusnya kami ingin menarik balik penyerahan ini Prestasi yang ditunjukkan oleh tiga parameter di atas adalah seperti ini:

  • --soft:我们对 README 的更改状态现在变成已被提交至暂存区,也就是上面 2 的步骤。
  • --mixed: 我们对 README 的更改变成还未被提交至暂存区,也就是上面 1 的步骤。
  • --hard:我们对 README 的所有更改全没了,git log 中也找不到我们对 README 刚刚那次修改的痕迹。

默认情况下我们不加参数,就是 --mixed,也就是重置暂存区的文件到上一次提交的版本,文件内容不动。一般会在什么时候用到呢?

场景一(撤销 git add)

可能大部分情况下,比如 vscode 其实大家更习惯于使用可视化的撤销能力,但是呢,这里我们其实也可以稍微了解下这其中的奥秘,其实也很简单:

  • 方式一:git reset
  • 方式二:git reset HEAD

其实一二都是一样,如果 reset 后面不跟东西就是默认 HEAD。

场景二 (撤销 git commit)

当你某个改动提交到本地仓库之后,也就是 commit 之后,这个时候你想撤回来,再改点其他的,那么就可以直接使用 git reset HEAD^。这个时候你会惊奇的发现,你上一版的代码改动,全部变成了未被提交到暂存区的状态,这个时候你再改改代码,然后再提交到暂存区,然后一起再 commit 就可满足你的需求了。

除了这种基础用法,我们还可以配合其他命令操作一下。

场景三

某一天你老板跟你说,昨天新加的功能不要了,给我切回之前的版本看看效果,那么这个时候,你可能就需要将工作区的代码回滚到上一个 commit 版本了,操作也十分简单:

  • git log 查看上一个 commit 记录,并复制 commitId
  • git reset --hard commitId 直接回滚。

场景四

如果某一个你开发需求正开心呢,突然发现,自己以前改的某个东西怎么不见了,你想起来好像是某次合并,没注意被其他提交冲掉了,你心一想,完了,写了那么多,怎么办?很简单,回到有这份代码的那个版本就好了(前提你提交过到本地仓库)。

假设我们有这么两个提交记录,我们需要下面那个 365 开头 commitId 的代码:

commit e62b559633387ab3a5324ead416f09bf347d8e4a (HEAD -> master)
Author: xiaohang.lin <xiaohang.lin@alibaba-inc.com>
Date:   Sun Aug 14 18:08:56 2022 +0800

    merge

commit 36577ea21d79350845f104eee8ae3e740f19e038 (origin/master, origin/HEAD)
Author: 陌小路 <44311619+STDSuperman@users.noreply.github.com>
Date:   Sun Aug 14 15:57:34 2022 +0800

    Update README.md复制代码
  1. 抢救第一步 git log 找到有你这个代码的那个 commitId(也就是 36577ea21d79350845f104eee8ae3e740f19e038)
  2. 抢救第二步 git reset --hard commitId
  3. 第三步:Ctrl + c 你的目标代码

这个时候你想把复制好的代码写回去,该怎么办呢,你可能会再 git log 看一下我们 reset 之前的 commitId,你会发现,完了,之前的 commitId 都没了,只有这个 365 了。

commit 36577ea21d79350845f104eee8ae3e740f19e038 (origin/master, origin/HEAD)
Author: 陌小路 <44311619+STDSuperman@users.noreply.github.com>
Date:   Sun Aug 14 15:57:34 2022 +0800

    Update README.md复制代码

不要慌,请记住一句话,只要你不删你本地的 .git 仓库,你都能找回以前所有的提交。

git log 看不到的话,我们就可以祭出我们的绝招了:git reflog

36577ea (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: reset: moving to 36577ea21d79350845f104eee8ae3e740f19e038
e62b559 HEAD@{1}: reset: moving to e62b559633387ab3a5324ead416f09bf347d8e4a复制代码

这里我们可以看到两行记录,一个是我们执行 reset 到 365 的记录,另一条不知道是啥,不重要,我们想回到我们刚刚 reset 之前的状态也很简单,直接复制它上一次的变动也就是这个 e62b559,然后执行 git reset --hard e62b559,然后你会惊奇的发现,你之前的代码又回来了。

接下来把你以前版本的代码,再 Ctrl + v 放进来就完成了。

git reflog

介绍:用来查看你的所有操作记录。

既然 git log 看不到我之前 commitId 了,那么就回到 reset 之前的状态吧!

git revert

当然了,如果是针对 master 的操作,为了安全起见,一般还是建议使用 revert 命令,他也能实现和 reset 一样的效果,只不过区别来说,reset 是向后的,而 revert 是向前的,怎么理解呢?简单来说,把这个过程当做一次时光穿梭,reset 表示你犯了一个错,他会带你回到没有犯错之前,而 revert 会给你一个弥补方案,采用这个方案之后让你得到的结果和没犯错之前一样。

举个栗子: 假设你改了 README 的描述,新增了一行文字,提交上去了,过一会你觉得这个写了有问题,想要撤销一下,但是又不想之前那个提交消失在当前历史当中,那么你就可以选择使用 git revert [commitId],那么它就会产生一次新的提交,提交的内容就是帮你删掉你上面新增的内容,相当于是一个互补的操作。

PS D:\Code\other\git-practice> git revert 3b18a20ad39eea5264b52f0878efcb4f836931ce
On branch branch2
Your branch is ahead of 'origin/branch2' by 1 commit.
  (use "git push" to publish your local commits)

这个时候,它会提示你可以把新的改动 push 上去了。

其实你如果在 gitlab 进行 mr 之后,想要回滚这个 mr,一般它会给你一个 revert 的按钮选项,让你进行更安全的回滚操作。

git cherry-pick

其实对于我们工作中大部分场景下应该用不到这个功能,但是呢有的时候这个命令又能挽救你于水火之间,那就是当某个倒霉蛋忘记切分支,然后在 master 分支上改了代码,并且提交到了本地仓库中,这个时候使用git cherry-pick简直就是神器了。

  • git cherry-pick:将执行分支的指定提交合并到当前分支。

一听介绍就来精神了,雀氏有点东西,比如我在 master 分支提交了某个需求的代码,同时还没提交到远程分支,那么你就可以先 git log 查看一下当前的提交,找到 master 分支正常提交之后的所有 commitId,然后复制出来,然后再切到你建好的开发分支,接着执行 git cherry-pick master commitId1 commitId2 commitId4

完事之后记得清理一下作案现场,把你的 master 分支代码恢复到正常的提交上去。

git tag

顾名思义,也就是打标签的意思。一般可能会在你发布了某个版本,需要给当前版本打个标签,你可以翻阅 vite 的官方 git 仓库,查看它的 tag 信息,它这里就标注了各个版本发布时候的 tag 标签。

它有两种标签形式,一种是轻量标签,另一种是附注标签。

轻量标签

  • 创建方式:git tag v1.0.0

它有点像是对某个提交的引用,从表现上来看,它又有点像基于当前分支提交给你创建了一个不可变的分支,它是支持你直接 checkout 到这个分支上去,但是它和普通分支还是有着本质的区别的,如果你切换到了这个 tag "分支",你去修改代码同时产生了一次提交,亦或者是 reset 版本,这对于该 tag 本身不会有任何影响,而是为你生成了一个独立的提交,但是却在你的分支历史中是找不到的,你只能通过 commitId 来切换到本次提交,看图:

tag commitId

那如果你从其他分支通过 commitId 切换到这个改动上,它会提示你以下内容:

Note: switching to 'be276009'.

changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

大致意思就是你可以选择丢弃或者保留当前更改,如果需要保留的话直接使用下面的 git switch 命令创建一个新分支即可。

附注标签

  • 创建方式:git tag -a v1.0.1 -m "发布正式版 1.0.1"

引用官方文档的描述:

而附注标签是存储在 Git 数据库中的一个完整对象, 它们是可以被校验的,其中包含打标签者的名字、电子邮件地址、日期时间, 此外还有一个标签信息,并且可以使用 GNU Privacy Guard (GPG)签名并验证。

从概念上看,轻量标签更像是一个临时的标签,而附注标签更加正式一点,能够保留更多的信息。它创建的方式和轻量标签区别主要是 -a 和 -m 参数,如果你的 -m 参数不传,那么编辑器会让你手动填写。

对比标签信息

打完标签之后,我们可以使用 git show 命令来看看这两种标签最终体现的信息有哪些。

轻量标签
commit dcbd335be87f51eaa0cc1852400e64e9f46e84d8 (HEAD -> test-branch1, tag: v1.0.2, tag: v1.0.1)
Author: STDSuperman <2750556766@qq.com>
Date:   Tue Aug 16 22:54:36 2022 +0800

    xx

diff --git a/README.md b/README.md
index 715766a..b4cdea6 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,3 @@-# git-practice\ No newline at end of file
+# git-practice
+
+test tag
附注标签
tag v1.0.1
Tagger: STDSuperman <2750556766@qq.com>
Date:   Tue Aug 16 22:58:27 2022 +0800

发布正式版 1.0.0

commit dcbd335be87f51eaa0cc1852400e64e9f46e84d8 (HEAD -> test-branch1, tag: v1.0.1)
Author: STDSuperman <2750556766@qq.com>
Date:   Tue Aug 16 22:54:36 2022 +0800

    xx

diff --git a/README.md b/README.md
index 715766a..b4cdea6 100644
--- a/README.md
+++ b/README.md

从信息丰富度上来说,附注标签能保留的信息会更多。

推送标签

  • git push origin tagName
$> git push origin v1.0.1Enumerating objects: 6, done.
Counting objects: 100% (6/6), done.
Delta compression using up to 12 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 448 bytes | 448.00 KiB/s, done.
Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:STDSuperman/git-practice.git
 * [new tag]         v1.0.1 -> v1.0.1

当然,附注标签和轻量标签都是可以被推送到远端的。

其他命令

  • 查看标签:git tag
  • 筛选标签:git tag -l v1.0.1
  • 删除标签:git tag -d v1.0.1
  • 删除远程标签:git push origin --delete v1.0.2
    • 另一种删除远程方式(表示将“:”前面空值替换到远程,也不失为一种方式):git push origin :refs/tags/v1.0.1

git rebase

这块其实涉及的玩法会相对来说复杂一点,可能还是需要拿来和 merge 做一下对比才更加有意义,东西有点多,先搁置一下。

WIP...

Atas ialah kandungan terperinci Belum bermain dengan Git lagi? Susun sekarang!. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Artikel ini dikembalikan pada:juejin.im. Jika ada pelanggaran, sila hubungi admin@php.cn Padam