Artikel ini membawakan anda pengetahuan yang berkaitan tentang Git, yang meringkaskan perkara utama kawalan versi Mari kita lihat panduan belajar kawalan versi Git. Bermanfaat.
Kajian yang disyorkan: "Tutorial Pembelajaran Git"
集中式 alat pengurusan kod sumber. Ia pernah menjadi alat pengurusan kod untuk kebanyakan perisian sumber terbuka (kod google), dan ia paling kerap digunakan oleh syarikat perisian domestik sejak beberapa tahun lalu分布式 Pada masa ini, hampir semua perusahaan domestik telah menyelesaikan penukaran daripada SVN kepada GIT 
分布式 sistem kawalan versi Digunakan untuk 敏捷高效mengendalikan sebarang projek, kecil atau besar.git目录
共享版本库 diperlukan untuk pembangunan berbilang orang dan satu 本地库 boleh dimulakan git help: manual bantuan arahan git
git init: Inisialisasi gudang (gudang peribadi)
HEAD: 指向当前分支的一个提交 description: 项目的描述信息 config: 项目的配置信息 info/: 里面有一个exclude文件，指定本项目要忽略的文件 objects/: Git对象库(commit/tree/blob/tag) refs/: 标识每个分支指向哪个提交 hooks/: 默认的hook脚本
Maklumat konfigurasi tetapan GIT
git config user.name "用户名" (untuk menjejak rekod pengubahsuaian) git config user.email "邮箱" (untuk komunikasi antara pembangun berbilang orang) git config -l : Lihat maklumat konfigurasi git config -e : Edit maklumat konfigurasi git status : Semak status fail
git status 文件名
git status
git add : akan berfungsi Simpan fail dalam kawasan penimbal ke kawasan penimbal
git add 文件名
git add . (perhatikan bahawa pada penghujungnya ialah titik.) git commit: Serahkan fail dalam zon penampan ke cawangan semasa
git commit -m ”注释” 文件名
git commit -m ”注释”
git log: Lihat log pengubahsuaian fail
git log 文件名
git log
git log ––pretty=oneline
git log –N (N ialah integer) git diff: Lihat perubahan terkini pada fail
git diff 文件名
git diff
git reflog: Lihat rekod rujukan cawangan (boleh melihat semua nombor versi)
git rm: Padam fail (operasi komit diperlukan selepas pemadaman untuk menyegerakkan ke pustaka Versi)
git reset: rollback versi (ia disyorkan untuk menambah parameter --hard, git menyokong penyesalan tanpa had)
git reset ––hard HEAD^
git reset ––hard HEAD^^
git reset ––hard HEAD~N（N是一个整数）
git reset ––hard 版本号（版本号用7位即可）
Git忽略提交规则 - .gitignore配置
# 表示此为注释,将被Git忽略*.a 表示忽略所有 .a 结尾的文件!lib.a 表示但lib.a除外/TODO 表示仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODO build/ 表示忽略 build/目录下的所有文件，过滤整个build文件夹； doc/*.txt 表示会忽略doc/notes.txt但不包括 doc/server/arch.txt bin/: 表示忽略当前路径下的bin文件夹，该文件夹下的所有内容都会被忽略，不忽略 bin 文件 /bin: 表示忽略根目录下的bin文件 /*.c: 表示忽略cat.c，不忽略 build/cat.c debug/*.obj: 表示忽略debug/io.obj，不忽略 debug/common/io.obj和tools/debug/io.obj **/foo: 表示忽略/foo,a/foo,a/b/foo等 a/**/b: 表示忽略a/b, a/x/b,a/x/y/b等!/bin/run.sh 表示不忽略bin目录下的run.sh文件*.log: 表示忽略所有 .log 文件 config.php: 表示忽略当前路径的 config.php 文件 /mtk/ 表示过滤整个文件夹*.zip 表示过滤所有.zip文件/mtk/do.c 表示过滤某个具体文件 被过滤掉的文件就不会出现在git仓库中（gitlab或github）了，当然本地库中还有，只是push的时候不会上传。 需要注意的是，gitignore还可以指定要将哪些文件添加到版本管理中，如下：!*.zip!/mtk/one.txt 唯一的区别就是规则开头多了一个感叹号，Git会将满足这类规则的文件添加到版本管理中。为什么要有两种规则呢？ 想象一个场景：假如我们只需要管理/mtk/目录中的one.txt文件，这个目录中的其他文件都不需要管理，那么.gitignore规则应写为：：/mtk/* !/mtk/one.txt 假设我们只有过滤规则，而没有添加规则，那么我们就需要把/mtk/目录下除了one.txt以外的所有文件都写出来！ 注意上面的/mtk/*不能写为/mtk/，否则父目录被前面的规则排除掉了，one.txt文件虽然加了!过滤规则，也不会生效！ ---------------------------------------------------------------------------------- 还有一些规则如下： fd1/* 说明：忽略目录 fd1 下的全部内容；注意，不管是根目录下的 /fd1/ 目录，还是某个子目录 /child/fd1/ 目录，都会被忽略； /fd1/* 说明：忽略根目录下的 /fd1/ 目录的全部内容； /* !.gitignore !/fw/ /fw/* !/fw/bin/ !/fw/sf/ 说明：忽略全部内容，但是不忽略 .gitignore 文件、根目录下的 /fw/bin/ 和 /fw/sf/ 目录；注意要先对bin/的父目录使用!规则，使其不被排除。
git init --bare : 仓库初始化(共享仓库)git clone：下载远程仓库到本地git pull：下载远程仓库的最新信息到本地仓库git push：将本地的仓库信息推送到远程仓库<<<<<<< HEAD 你本地的新增的代码======= 服务器上和你冲突的代码>>>>>>> e9609de28b65bf97539f94c6458cdebdf2711c9f
中心仓库：包含master和develop两个分支
分支分类
对于商业级项目，真正开发过程中都是基于develop分支进行的，develop分支是开发主线！
master分支中，只存放相对稳定的分支，例如：0.1版本, 0.2版本
在实际产品开发中，需要“规划版本”，例如：将100个功能规划到5个不同的版本上
发现bug，要基于“上一个最稳定的版本”进行修复，这是热补丁分支存在的意义！
理解清楚版本管理分支的特性，是迭代式开发的重要基础！
git branch : 查看所有分支
git branch 分支名称 : 创建分支
git checkout 分支名称 : 切换到指定分支git merge 分支名称 : 合并分支git branch -d 分支名称 : 删除指定分支提示:
- Kemas kini sebelum setiap penyerahan
- Serahkan kod yang disusun pada hari itu sebelum keluar kerja setiap hari
- Kemas kini kod dari hari sebelumnya perkara pertama di tempat kerja setiap hari
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
6.2 Salin kunci awam yang baru dijana
6.3 Tambahkan Kunci SSH yang dijana pada GitHub
6.4 Uji sama ada konfigurasi berjaya ssh -T git@github.comJika ia muncul kemudian: Hai ****! telah berjaya disahkan, tetapi GitHub tidak menyediakan akses shell yang terbukti
<.>
Atas ialah kandungan terperinci Ringkaskan dan susun panduan kajian kawalan versi Git. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
Bina pelayan git anda sendiri
Perbezaan antara git dan svn
git undo menyerahkan komit
Bagaimana untuk membatalkan ralat komit git
Bagaimana untuk membandingkan kandungan fail dua versi dalam git
Konsep m2m dalam Internet Perkara
Penjelasan terperinci tentang arahan linux dd
Bagaimana untuk mengubah suai elemen.gaya
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
