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.
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!
Mulakan dengan gambar, dan kesimpulannya bergantung pada tekaan.
远程仓库区: 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. 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.
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):
git add untuk menyerahkan kod ke kawasan pementasan. git commit Hantar kod ke repositori tempatangit push Hantar kod ke cawangan terpencilProses 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.
git stashgit clonegit initgit remotegit branchgit checkoutgit addgit commitgit rmgit pushgit pullgit fetchgit mergegit loggit resetgit refloggit revertgit cherry-pickgit taggit rebasegit stash save 'xxx'
git stash list
git stash pop
git stash drop stash@{n}
git stash clear
git clone xxx.gitgit clone xxx.git -b branch1. git remote
git remote add
git remote rm
git remote add origin xxx.gitTambahkan ke gudang tempatan dahulu 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. 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.
Jika kita ingin mencipta cawangan baharu berdasarkan cawangan semasa dan beralih kepadanya, kita boleh menggunakan arahan berikut.
git checkout -b branch1
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.
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 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.
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.
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:
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:
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.
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.
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).
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:
Begitu juga, git merge origin/xxx yang diperkenalkan di atas juga digunakan dengan cara yang sama.
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.
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:
git add
git commit
--soft：我们对 README 的更改状态现在变成已被提交至暂存区，也就是上面 2 的步骤。--mixed： 我们对 README 的更改变成还未被提交至暂存区，也就是上面 1 的步骤。--hard：我们对 README 的所有更改全没了，git log 中也找不到我们对 README 刚刚那次修改的痕迹。默认情况下我们不加参数，就是 --mixed，也就是重置暂存区的文件到上一次提交的版本，文件内容不动。一般会在什么时候用到呢？
可能大部分情况下，比如 vscode 其实大家更习惯于使用可视化的撤销能力，但是呢，这里我们其实也可以稍微了解下这其中的奥秘，其实也很简单：
git reset
git reset HEAD
其实一二都是一样，如果 reset 后面不跟东西就是默认 HEAD。
当你某个改动提交到本地仓库之后，也就是 commit 之后，这个时候你想撤回来，再改点其他的，那么就可以直接使用 git reset HEAD^。这个时候你会惊奇的发现，你上一版的代码改动，全部变成了未被提交到暂存区的状态，这个时候你再改改代码，然后再提交到暂存区，然后一起再 commit 就可满足你的需求了。
除了这种基础用法，我们还可以配合其他命令操作一下。
某一天你老板跟你说，昨天新加的功能不要了，给我切回之前的版本看看效果，那么这个时候，你可能就需要将工作区的代码回滚到上一个 commit 版本了，操作也十分简单：
git log 查看上一个 commit 记录，并复制 commitIdgit 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复制代码
git log 找到有你这个代码的那个 commitId（也就是 36577ea21d79350845f104eee8ae3e740f19e038）git reset --hard commitId
这个时候你想把复制好的代码写回去，该怎么办呢，你可能会再 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 log 看不到我之前 commitId 了，那么就回到 reset 之前的状态吧！
当然了，如果是针对 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 的按钮选项，让你进行更安全的回滚操作。
其实对于我们工作中大部分场景下应该用不到这个功能，但是呢有的时候这个命令又能挽救你于水火之间，那就是当某个倒霉蛋忘记切分支，然后在 master 分支上改了代码，并且提交到了本地仓库中，这个时候使用git cherry-pick简直就是神器了。
git cherry-pick：将执行分支的指定提交合并到当前分支。一听介绍就来精神了，雀氏有点东西，比如我在 master 分支提交了某个需求的代码，同时还没提交到远程分支，那么你就可以先 git log 查看一下当前的提交，找到 master 分支正常提交之后的所有 commitId，然后复制出来，然后再切到你建好的开发分支，接着执行 git cherry-pick master commitId1 commitId2 commitId4。
完事之后记得清理一下作案现场，把你的 master 分支代码恢复到正常的提交上去。
顾名思义，也就是打标签的意思。一般可能会在你发布了某个版本，需要给当前版本打个标签，你可以翻阅 vite 的官方 git 仓库，查看它的 tag 信息，它这里就标注了各个版本发布时候的 tag 标签。
它有两种标签形式，一种是轻量标签，另一种是附注标签。
git tag v1.0.0
它有点像是对某个提交的引用，从表现上来看，它又有点像基于当前分支提交给你创建了一个不可变的分支，它是支持你直接 checkout 到这个分支上去，但是它和普通分支还是有着本质的区别的，如果你切换到了这个 tag "分支"，你去修改代码同时产生了一次提交，亦或者是 reset 版本，这对于该 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.2git push origin :refs/tags/v1.0.1
这块其实涉及的玩法会相对来说复杂一点，可能还是需要拿来和 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!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
