网站建设零基础好学吗,网站建设是不是都需要交费,电子商务网站建设的过程,怎么查询域名是否备案Git基础之基本工具
Author#xff1a;onceday date#xff1a;2023年3月5日
满满长路有人对你微笑过嘛…
windows安装可参考文章#xff1a;git简易配置_onceday_CSDN博客
參考文档#xff1a;
《progit2.pdf》#xff0c;Progit2 Github。《git-book.pdf》 文章目录…Git基础之基本工具
Authoronceday date2023年3月5日
满满长路有人对你微笑过嘛…
windows安装可参考文章git简易配置_onceday_CSDN博客
參考文档
《progit2.pdf》Progit2 Github。《git-book.pdf》 文章目录Git基础之基本工具1.选择修订版本1.1 引用日志1.2 提交区间2. 交互式提交3.储存文件3.1 清理工作目录4. 搜索内容5.修改提交5.1 修改历史提交信息6.重置文件6.1 压缩提交历史7.Rerere 重用记录的解决方案8. Git调试8.1 文件标注 blame8.2 二分查找9.打包1.选择修订版本
每个提交对象有一个完整的40字符的SHA-1散列值但是指定时并不需要填写完整的40个字符。
Git 十分智能你只需要提供 SHA-1 的前几个字符就可以获得对应的那次提交 当然你提供的 SHA-1 字符数量 不得少于 4 个并且没有歧义——也就是说 当前对象数据库中没有其它对象以这段 SHA-1 开头。
首先使用git log打印提交日志然后确定目标提交的SHA-1值
ubuntu-requests:$ git log
commit 1e62a3ec18e19f85ddae03b4cbbdf0b4c62834c0 (HEAD - main, origin/main, origin/HEAD)
Merge: c57f1f0c 7908ad3a
Author: Ian Stapleton Cordasco graffatcolmingovgmail.com
Date: Fri Oct 21 11:37:47 2022 -0500Merge pull request #6262 from winmorre/docs-update/#6260JSONDecodeError included in the documentation
......然后使用git show来展示
ubuntu-requests:$ git show 1e62a3
commit 1e62a3ec18e19f85ddae03b4cbbdf0b4c62834c0 (HEAD - main, origin/main, origin/HEAD)
Merge: c57f1f0c 7908ad3a
Author: Ian Stapleton Cordasco graffatcolmingovgmail.com
Date: Fri Oct 21 11:37:47 2022 -0500Merge pull request #6262 from winmorre/docs-update/#6260JSONDecodeError included in the documentation一般来说如Linux内核这样庞大的项目也仅需前12个字符就可以分辨因此并不用输入完整的SHA-1字符串。
使用git log --abbrev-commit --prettyonline可以打印简单而唯一的值。
对于分支的顶端提交直接使用git show branch_name即可查看顶端的提交信息。
通过git rev-parse branch_name可以看当前Git的分支所处的提交对象(提交对象)。
1.1 引用日志
可以使用git reflog来查看引用日志。 Git 会在后台保存一个引用日志reflog 引用日志记录了最近几个月你的 HEAD 和分支引用 所指向的历史。
ubuntu-requests:$ git reflog
1e62a3ec (HEAD - main, origin/main, origin/HEAD) HEAD{0}: clone: from gitee.com:onceday/requests.git然后可以使用{n}来引用reflog中输出的提交记录。
git show HEAD{5}也可以使用同样的语法来查看某个分支在一定时间前的位置例如查看master分支在昨天的时候指向了哪个提交
git show master{yesterday}也可以使用git log -g来查看类似git log输出格式的引用日志信息。
^可以用来查看上一个提交即祖先提交下面命令即查看HEAD的父提交
git show HEAD^ #cmd上可能需要使用HEAD^或者HEAD^对于合并的提交可以用指定数字来查看第二个父提交
git show HEAD^2另外一种方法是使用波浪号~同样指向第一父提交因此HEAD~和HEAD^是等价的区别是HEAD~2代表第一父提交的第一父提交即祖父提交。下面两种是等价的^和~也可嵌套使用
git show HEAD~~
git show HEAD~21.2 提交区间
使用双点语法可以让Git选择在一个分支中而不在另一个分支中的提交
git log master..experiment上面语法的含义就是指出在experiment分支中而不在master分支中的提交。
除了双点语法外还支持多点语法如^branch和--not branch指明不希望提交被包含其中的分支。
如下面的命令是等价的
git log refA..refB
git log ^refA refB
git log refB --not refA在此基础上就可以指定多点查询了
git log refA refB ^refC上面即查看被refA或refB包含但不被refC包含的提交。
还存在一个三点语法可以选择处被两个引用之一包含但又不被两者同时包含的提交。
git log --left-right master...experiment--left-right会显示出每个提交到底处于那一侧的分支。
2. 交互式提交
使用git add -i选项可以进入交互式暂存。具体详情请参考文档progit2。
3.储存文件
使用git stash可以暂存正在开发的文件从而能切换到新的分支上。
stash储存会清理工作目录的脏状态跟踪文件的修改和暂存的改动然后将未完成的修改保存到一个栈上然后可以在任何时候重新应用这些改动包括不同的分支。
使用下面命令即可
git stash可以将当前工作内容暂存。git stash list查看储存的内容。git stash apply应用最新储存的内容。git stash apply stash{2}指定应用目标存储可以使用名字代替。git stash drop {stash_name}移除指定的存储目标。git stash pop {stash_name}应用储存并且从栈上丢弃。
stash可以储存未跟踪文件
git stash -u该选项会存储任何未跟踪文件但不会包含明确忽略的文件。git stash -a包含所有文件包括明确忽略的文件。
使用git stash branch new branchname可以指定的分支名创建一个新分 支检出贮藏工作时所在的提交重新在那应用工作然后在应用成功后丢弃贮藏
3.1 清理工作目录
清理工作目录有一些常见的原因比如说为了移除由合并或外部工具生成的东西 或是为了运行一个干净的构建而移除之前构建的残留。 需要谨慎地使用这个命令因为它被设计为从工作目录中移除未被追踪的文件。 如果改变主意了也不 一定能找回来那些文件的内容。 一个更安全的选项是运行git stash --all来移除每一样东西并存放在栈 中。
常用命令如下
git clean去除冗余文件清理工作目录只会移除没有忽略的未跟踪文件。git clean -f -d移除工作目录中所有未追踪的文件和空的子目录。git clean --dry-run或git clean -n只是输出需要移除的文件但不会去真的移除文件。git clean -x移除那些明确被忽略的文件。git clean -i支持交互式操作。
4. 搜索内容
需要查看一个仓库代码的某个函数的变更历史就需要使用搜索工具。
如git grep会查找工作目录。它的速度非常快不仅仅可以可以搜索工作目录还可以搜索任意的 Git 树。
git log支持的某些搜索向可以查找某个内容对象是什么时候存在和引入的。
git log -S XXXX_MAX --oneline查看XXXX_MAX常量在哪个提交新增和删除的。git log -S -G reg --oneline支持正则表达式搜索。
使用git log -L :git_deflate_bound:zlib.c可以查看zlib.c文件中git_deflate_bound函数的每一次变更。
5.修改提交
修改最后一次提交的提交信息可以使用
git commit --amend上面这条命令会将最后一次的提交信息载入到编辑器中供你修改。 当保存并关闭编辑器后编辑器会将更新后的提交信息写入新提交中它会成为新的最后一次提交。
如果需要修改最后一次提交的实际内容可按以下步骤
首先修改预期内容。然后暂存修改文件。最终使用git commit --amend以新的改进暂存文件来提交旧友的最后一次提交。
修改提交会改变提交的SHA-1校验和因此推送后的提交就最好不要再修改了。
使用git commit --amend --no-edit可以跳过提交信息的编辑步骤。
5.1 修改历史提交信息
通过使用git rebase -i工具可以修改历史提交信息详情可参考progit2书籍。
如git rebase -i HEAD~3将想要修改的最近一次提交的父提交作为参数传递给git rebase -i命令其等价于下面形式:
git rebase -i HEAD~3..HEAD即将从HEAD~3到HEAD范围内的四个提交的信息进行改写注意最好不要对已推送到服务器的提交进行修改。
git rebase会从旧到新的顺序依次重演这四次提交过程因此便可以乘机修改每一次提交。
当修改了目标提交信息后需要依次输入git commit --amend和git rebase --continue前者用于更新本次提交信息后面用于自动应用剩下的提交。对于每一个需要修改的地方Git都会停止并且重复这个过程。
变基工具需要执行一个脚本下面是脚本中有用信息的描述
#
# Commands:
# p, pick commit use commit
# r, reword commit use commit, but edit the commit message
# e, edit commit use commit, but stop for amending
# s, squash commit use commit, but meld into previous commit
# f, fixup commit like squash, but discard this commits log message
# x, exec command run command (the rest of the line) using shell
# b, break stop here (continue rebase later with git rebase
--continue)
# d, drop commit remove commit
# l, label label label current HEAD with a name
# t, reset label reset HEAD to a label
# m, merge [-C commit | -c commit] label [# oneline]
# . create a merge commit using the original merge commits
# . message (or the oneline, if no original merge commit was
# . specified). Use -c commit to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out6.重置文件
这里介绍一下reset和checkout的区别首先是三个存储区域
HEAD上一次提交的快照下一次提交的父节点。Index预期的下一次提交的快照。Working Directory沙盒。
HEAD是当前分支引用的指针它总是指向该分支的最后一次提交这表示HEAD将是下一次提交的父节点。
Index是预期的下一次提交即Git的暂存区。使用git ls-files -s即可查看暂存区文件信息。
工作目录是当前HEAD指向内容和Index内容以及其他内容的融合体是一个沙盒在这里可以随意修改内容。 对于一个干净的工作区首先在工作目录修改文件内容然后使用git add暂存工作目录的修改文件最后使用git commit提交暂存区的内容到git存储库中此时HEAD的也会移向最新的提交。
对于切换分支或者克隆当check out一个分支时会修改HEAD指向新的分支引用将索引填充为该次提交的快照然后将索引的内容复制到工作目录中。
对于reset操作首先移动HEAD的指向reset将当前分支的HEAD指针移到目标提交上。。
对于git reset --soft做完上面一步后便停下了并不会改变索引和工作目录。
此时如果更新索引的内容然后再git commit其效果和git commit --amend的效果类似。
对于git reset --mixed会在--soft基础上进一步更改Index的内容即撤销后续的提交取消暂存所有的东西但此时工作目录中还存在内容。
对于git reset --hard会在--mixed基础上进一步的修改工作目录中的内容一旦覆盖那些未提交过的内容那么将无法找回这些数据因此该命令相当有危险性。
可以给reset指定文件路径这样会跳过移动HEAD分支的步骤直接让索引(暂存区)的内容看起来像HEAD分支。
git reset file.txt
git reset --mixed HEAD file.txt也可以从指定提交中拉取数据git reset eeaabb file.txt。下面展示了reset和checkout命令对树的影响 6.1 压缩提交历史
对于下面的提交历史V2版本的文件只完成了部分工作想把这个部分去掉可以如下操作。 先运行git reset --soft HEAD~2这个时候HEAD指针移到eb43bf8上然后索引区的内容保持不变(即38eb946提交的内容)然后再git commit这个时候就会把file-a.txt v3和file-b.txt v1都提交上去如下 这样就跳过了原来9e5e6a4提交了且工作目录和索引区的内容保持不变在提交历史中V2的内容无法直接查询到了。
7.Rerere 重用记录的解决方案
这是一个隐藏功能能让Git记住解决一个块冲突的方法这样在下一次看到相同冲突时Git可以自动的解决它。
详情可以参阅progit2。
8. Git调试
8.1 文件标注 blame
能显示任何文件中每行最后一次修改的提交记录。 所以如果在代码中看到一个有 bug 的方法可以使用git blame标注这个文件查看哪一次提交引入了这行。
git blame -L 69,82 Makefile上述命令确定Makefile中每一行分别来自哪个提交和提交者使用-L选项将标注的输出限制为该文件的第69行到第82行。
8.2 二分查找
bisect 命令会对你的提交历史进行二分查找来帮助尽快找到是哪一个提交引入了问题。
一般步骤如下
git bisect start启动二分查找。测试代码确定当前代码是否正常。git bisect bad/good告诉Git当前所在提交是否有问题。测试代码…git bisect bad/good告诉Git当前所在提交是否有问题。…
依次迭代上面步骤后就可以最终定位问题所在了。
在确定问题之后需要使用git bisect reset重置HEAD指针到最开始的位置。
9.打包
git bundle命令会将git push命令所传输的所有内容打包成一个二进制文件然后可以通过物理手段传给其他人并解包到其他仓库中。
ubuntu-cc:$ git bundle create repo.bundle HEAD master
Enumerating objects: 31, done.
Counting objects: 100% (31/31), done.
Compressing objects: 100% (27/27), done.
Total 31 (delta 6), reused 12 (delta 2), pack-reused 0repo.bundle中包含所有重建该仓库master分支所需的数据。
HEAD添加了一个分支应用这样在别处clone时可以直接从这个二进制文件中克隆出一个目录。
使用git clone repo.bundle repo即可在他处重建该仓库。
可以只打包指定区间的提交内容git bundle create commits.bundle master ^9a466c5
对于这样只打包了部分内容的包需要先检查这个文件是否是一个合法的Git包是否拥有共同的祖先来导入。如下
git bundle verify ../commits.bundle如果缺失必要的提交信息那么就无法进行导入。
使用git bundle list-heads ../commits.bundle可以列出这些包里可以导入的分支。
还可以使用git fetch和git pull从包里导入提交。
git fetch ../commits.bundle master:other-master可以只打包指定区间的提交内容git bundle create commits.bundle master ^9a466c5
对于这样只打包了部分内容的包需要先检查这个文件是否是一个合法的Git包是否拥有共同的祖先来导入。如下
git bundle verify ../commits.bundle
