赞
踩
作者简介:大家好,我是smart哥,前中兴通讯、美团架构师,现某互联网公司CTO
联系qq:184480602,加我进群,大家一起学习,一起进步,一起对抗互联网寒冬
学习必须往深处挖,挖的越深,基础越扎实!
阶段1、深入多线程
阶段2、深入多线程设计模式
阶段3、深入juc源码解析
码哥源码部分
码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】
码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】
码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作?】
码哥讲源码【谁再说Spring不支持多线程事务,你给我抽他!】
打脸系列【020-3小时讲解MESI协议和volatile之间的关系,那些将x86下的验证结果当作最终结果的水货们请闭嘴】
新建一个目录,并使用git init
命令初始化Repository:
- mkdir mygit
- git init
git init
命令会在mygit目录中创建一个.git
目录。
Git的版控很单纯,全都是靠.git目录在做事。如果这个目录不想被版控,或者只想给客户不含版控记录的内容,只要把.git目录移除,Git就对这个目录失去控制权了。
创建一个内容为"hell, git"的文件,并命名为welcome.html:
echo "hello, git" > welcome.html
使用git status
命令查看状态:
这个welcome.html文件当前的状态是Untracked files
,即这个文件尚未被加到Git版控系统中,还未正式被Git“追踪”,只是刚刚加入这个目录而已。
使用git add
命令,把welcome.html文件交给Git,让Git开始追踪它:
git add welcome.html
再次使用git status命令查看当前的状态:
从以上信息可以看出,文件状态已从Untracked
变成new file
。这表示该文件已经被安置到暂存区(Staging Area)。
设想一下下面这样一种情境:
- echo "hello world" > abc.txt
- git add abc.txt
- echo "hw" > abc.txt
完成编辑后,可能想要进行Commit,把刚刚改动的内容保存下来。这是新手很容易犯的错误之一,以为执行Commit命令就能把所有的异动都保存下来,事实上这样的想法是不正确的。执行git status命令,看一下当前的状态:
可以发现,abc.txt文件变成了两个,步骤(2)的确把abc.txt文件加入暂存区了,但在步骤(3)中又编辑了该文件。对Git来说,编辑的内容并没有“再次被加入暂存区,所以此时暂存区中的数据还是步骤(2)中加进来的那个文件。
如果确定这个改动是你想要的,那就再次使用git add abc.txt
命令,把abc.txt文件加入暂存区。
Git 1.x:
参数 | 新增文件 | 改动文件 | 删除文件 |
---|---|---|---|
--all | 是 | 是 | 是 |
. | 是 | 是 | 否 |
Git 2.x:
参数 | 新增文件 | 改动文件 | 删除文件 |
---|---|---|---|
--all | 是 | 是 | 是 |
. | 是 | 是 | 是 |
也就是说,在Git 2.x之后,这两个参数在功能上就没什么区别了。
如果仅是通过git add
命令把异动加到暂存区,还不算是完成整个流程。如果想让暂存区的内容永久保存下来,就要使用git commit
命令。
git commit -m "init commit"
在后面加上-m "init commit"
是要说明“这次的Commit做了什么事”,只要使用简单、清楚的文本说明即可,中英文都可以,重点是要说清楚,能让自己和别人很快明白就行。
在执行git commit
命令时,如果没有在后面加上信息参数,默认会弹出一个黑色的画面,也就是编辑器——Vim。让我们输入提交信息:
另外,如果没有内容,也可以Commit,只要加上--allow-empty
参数。
git commit --allow-empty -m "empty commit"
在Git中,针对工作目录、暂存区以及存储库3个主要区域,可以通过不同的Git命令,把文件移往不同的区域,如图所示:
如果觉得先add再commit有点烦琐,可以在Commit时多加一个-a
参数,缩短这个流程:
- echo "ccc" > c.txt
- git commit -a -m "quick commit test."
这样即使没有先add,也可以完成Commit。但要注意的是,这个-a
参数 只对已经存在于Repository区域的文件有效,对新加入(也就是Untracked files)的文件是无效的。
git log
越新的信息会显示在越上面。从上面这段信息中大致可以看出以下内容:
在使用git log
命令时,如果加上额外参数,可以看到不一样的输出格式。例如,加上--oneline
和–-graph
参数:
git log --oneline --graph
输出的结果就会更为精简,可以一次性看到更多的Commit。
想要找某个人或某些人的Commit:
- # 使用 --author参数
- git log --oneline --author="ActonZhang"
-
- # 使用 | 表示或者,注意使用时需要加上\进行转义
- git log --oneline --author="ActonZhang\|Tom"
想要找Commit信息中是否包含有某些关键字:
- # 使用 --grep 参数
- git log --oneline --grep="second"
想要找Commit文件中的内容:
- # 使用 -S 参数
- git log -S "hw"
想要找某一段时间内的Commit:
- # 使用 --since --until --after 参数
- # 查询今天上午9点到下午11点之间的Commit
- git log --oneline --since="9am" --until="11pm"
-
- # 查询2017年1月之后,每天上午9点到下午11点之间的Commit
- git log --oneline --since="9am" --until="11pm" --after="2017-01"
在Git中,无论是删除文件还是变更文件名,对Git来说都是一种“改动”。
可以使用系统命令rm或资源管理器之类的工具来删除文件。例如:
rm -rf welcome.html
删除后查看状态:
可以看到welcome.html文件当前的状态是deleted。如果确定这是你想做的,就可以把这次的“改动”加到暂存区,然后Commit即可:
- git add welcome.html
- git commit -m "delete welcome."
如果“把删除文件加到暂存区”让你觉得不好理解,就把“删除文件”也当作一种“改动”就行了。
可以先执行rm命令删除,然后再执行git add命令加入暂存区的两段式动作,也可以直接使用git rm
命令来完成:
git rm abc.txt
这时候查看状态会发现,“它就直接在暂存区了,不需要再add一次,可以少做一个步骤:
随后直接Commit即可:
git commit -m "delete abc.txt"
不论是执行rm
命令,还是执行git rm
命令,都会真的把这个文件从工作目录中删除。如果不是真的想把这个文件删除,只是不想让这个文件再被Git控制了,可以加上-- cached
参数:
git rm b.txt --cached
查看状态,b.txt的状态从原本已经在Git目录中的tracked变成Untracked了:
随后直接Commit即可:
git commit -m "untrack b.txt"
与删除文件一样,变更文件名也是一种“改动”,所以在操作上也是差不多的:
mv a.txt aa.txt
查看状态,会看到两个状态的改变,虽然只是更改文件名,但对Git来说会被认为是两个动作,一个是删除a.txt文件,另一个是新增aa.txt文件(变成Untracked状态)。
- git add aa.txt
- git commit -m "rename a.txt to aa.txt"
- git rm a.txt
- git commit -m "delete a.txt"
git mv aa.txt aaa.txt
git commit -m "rename aa.txt to aaa.txt"
Git是根据文件的“内容”来计算SHA-1的值,所以文件的名称不重要,重要的是文件的内容。当更改文件名时,Git并不会为此做出一个新的Blob对象,而只是指向原来的那个Blob对象。但因为文件名变了,所以Git会为此做出一个新的Tree对象。
要改动Commit记录,有以下几种方式。
git rebase
命令来改动历史记录git reset
命令删除,整理后再重新Commit--amend
参数改动最后一次的Commit这里采用第四种方式,先提交一个空Commit记录:
git commit --allow-empty -m "WTF"
要改动最后一次的Commit信息,只需直接在Commit命令后面加上--amend
参数即可:
git commit --amend --allow-empty -m "heiheihei..."
虽然只是修改记录的信息,其他什么都没有改,但对Git来说,因为Commit的内容改变了,所以Git会重新计算并产生一个新的Commit对象,这其实是一次全新的Commit(只是看起来不像新的)。例如,上面这个例子中,改动前的Commit对象的SHA-1值在改完信息之后变了。虽然Commit的时间与文件的内容看起来并没有被改动,但它仍是一次全新的Commit。
可以采用下面这两种方式来完成:
--amend
参数进行Commit此处采用第二种方式,假设有一个Untracked的b.txt文件,想把它加入到最近一次的Commit中:
- # 先加入暂存区
- git add b.txt
-
- # 加入到最近一次Commit,--no-edit参数表示不需要编辑Commit信息
- git commit --amend --no-edit
像这样改动历史记录的操作,尽量不要应用在已经Push出去的Commit上。
- # 新建目录
- mkdir images
-
- # 查看状态
- git status
发现Git的状态依旧没有变化,因为Git在计算、产生对象时,是根据“文件的内容”进行计算的,所以只是新增一个目录的话,Git是无法处理它的。
如果想要新增目录,只要在空目录中随便放一个文件就行了。如果当前还没有文件可以放,或者不知道该放什么文件,通常可以放一个名为“.keep”或“.gitkeep”的空文件,让Git能“感应”到这个目录的存在:
- touch images/.keep
- git status
可以发现,Git已经感知到这个目录的存在了(其实是感应到里面那个.keep文件的存在),接下来按照一般的流程进行add和commit即可。
- git add .
- git commit -m "add dir"
如果不想把文件放在Git中,只需在项目目录中放一个.gitignore
文件,并且设置想要忽略的规则即可。如果这个文件不存在,就手动新增它:
touch .gitignore
然后编辑这个文件的内容:
- # 忽略所有后缀是.yml的文件
- *.yml
只要.gitignore文件存在,即使这个文件没有被Commit或Push上Git服务器,也会有效果。但通常建议将这个文件Commit进项目并且push上Git服务器,以便让一起开发项目的所有人可以共享相同的文件。
在新增文件时,只要符合.gitignore文件中的规定,这个文件就会被忽视。
- touch secret.yml
- git status
secret.yml这个文件虽然确实存在这个目录中,但Git已经“感应”不到它了,即它被Git无视了。
虽然.gitignore文件列出了一些忽略的规则,但其实这些忽略的规则也是可以被忽略的。只需在执行git add
命令时加上-f
参数:
git add -f 文件名称
如果想清除那些已经被忽略的文件,可以使用git clean
命令并配合-X
参数:
- git clean -fX
git log
可以查看整个项目的Commit记录,但如果只想查看单一文件的记录,可在git log
后面接上那个文件名:
git log b.txt
这样就能看到这个文件Commit的历史记录。如果想查看这个文件每次的Commit做了什么改动,可以再给它加上一个-p
参数:
git log -p b.txt
可使用git blame
命令找出来:
- git blame user.sql
这样就可以很清楚地看出来哪一行代码是谁在什么时候写的,而最前面看起来像乱码的文本,正是每次Commit的识别代码,表示这一行代码是在哪一次的Commit中加进来的。
如果文件太大,也可以加上-L
参数,只显示指定行数的内容:
- git blame -L 10,15 user.sql
先删除user.sql文件:
rm -rf user.sql
查看状态:
- git status
查看文件列表:
ls -al
如果要把user.sql挽救回来,可以使用git checkout
命令:
- git checkout user.sql
-
- # 如果要恢复多个文件,可以使用.
- git checkout .
查看状态:
查看文件列表:
这个技巧不仅可以将删除的文件挽救回来,当改动某个文件后反悔了,也可以用它把文件恢复到上一次Commit的状态。
不是所有情况下都能恢复被删除的文件的。因为整个Git的记录都是放在根目录下的.git目录中,如果这个目录被删除了,也就意味着历史记录也被删除了,那么删除的文件也就不能恢复了。
当使用git checkout
命令时,Git会切换到指定的分支,但如果后面接的是文件名或路径,Git则不会切换分支,而是把文件从.git目录中复制一份到当前的工作目录。
更精准地说,这个命令会把暂存区(Staging Area)中的内容或文件拿来覆盖工作目录中(Working Directory)的内容或文件。因此,在上面执行git checkout user.sql
或git checkout .
命令时,会把user.sql文件或者当前目录下的所有文件恢复到上一次Commit的状态。
如果在执行这个命令时多加了一个参数:
- git checkout HEAD~2 user.sql
那么距离现在两个版本以上的那个user.sql文件就会被用来覆盖当前工作目录中的user.sql文件,但要注意,这同时也会更新暂存区的状态。
git checkout HEAD~2 .
这个命令的意思就是“用距离现在两个版本以上的文件来覆盖当前工作目录中的文件,同时更新暂存区中的状态”。
先查看当前的Git记录:
git log --oneline
如果想拆掉最后一次的Commit,可以采用“相对”或“绝对”的做法。
“相对”的做法是这样的:
- git reset 7d66c8c^
- # 最后的那个“^”符号代表的是“前一次”,所以7d66c8c^是指7d66c8c这个Commit的前一次;
- # 如果是7d66c8c^^,则是往前两次……以此类推。
- # 不过如果要倒退5次,通常不会写作7d66c8c^^^^^,而是写成7d66c8c~5”
因为刚好HEAD与master当前都是指向7d66c8c这个Commit,而且7d66c8c不太好记,所以上面这行通常会改写成:
- git reset master^
- # 或
- git reset HEAD^
以这个例子来说,这两个命令会得到一样的结果。
"绝对"的方式如下:
如果很清楚要把当前的状态退回到哪个Commit,可以直接指明:
git reset dbca90c
它就会切换到dbca90c这个Commit的状态,因为dbca90c刚好就是7d66c8c的前一次Commit。以这个例子来说,也会达到与“拆掉最后一次的Commit”一样的效果。
git reset
命令可以搭配参数使用。常用参数有3个,分别是--mixed
、--soft
以及--hard
。搭配不同的参数,执行结果会有些微差别:
--mixed
是默认的参数,如果没有另外加参数,git reset
命令将使用--mixed
模式。该模式会把暂存区的文件删除,但不会影响工作目录的文件。也就是说,Commit拆出来的文件会留在工作目录,但不会留在暂存区。模式 | 工作目录 | 暂存区 |
---|---|---|
mixed | 不变 | 被删除 |
soft | 不变 | 不变 |
hard | 被删除 | 被删除 |
如果上面的说明让你不容易想象到底发生了什么事,那么只要记住这些不同的模式,就能决定“Commit拆出来的那些文件何去何从:
模式 | Commit拆出来的文件 |
---|---|
mixed | 放回工作目录 |
soft | 放回暂存区 |
hard | 直接删除 |
Reset通常翻译为“重新设置”,但在Git中,将Reset解释为“前往”或“变成”更为贴切,即go to或become的意思。当执行以下命令时:
git reset HEAD~2
该命令可能会被解读成“请帮我拆掉最后两次的Commit”,但其实用“拆”这个动词只是为了便于理解而已,事实上并没有真的把Commit“拆掉”(放心,所有的Commit都还在)。
准确地说,上面这个命令应该解读成“我要前往两个Commit之前的状态”或“我要变成两个Commit之前的状态”,而随着使用不同的参数模式,原本的这些文件就会移去不同的区域。
因为实际上git reset命令也并不是真的删除或重新设置Commit,只是“前往”到指定的Commit。那些看起来好像不见的东西只是暂时看不到了,但随时都可以再救回来。
查看Commit记录:
git log --oneline
首先要树立一个观念,不管用什么模式进行Reset,Commit就是Commit,并不会因为Reset就马上消失。假设先用默认模式的git reset
命令倒退一步:
git reset HEAD~1
这时Commit看起来就会少一个,同时拆出来的文件会被放置在工作目录中:
如果想要退回刚刚Reset的这个步骤,只要Reset回一开始那个Commit的SHA-1 7d66c8c
即可:
git reset 7d66c8c --hard
刚刚看起来拆掉的Commit就又回来了。这里使用了--hard
参数,可以强迫放弃Reset之后改动的文件。
如果一开始没有记录Commit的SHA-1值也没关系,可以利用Git中的Reflog命令保留一些记录。再次借用上一个例子,但这次改用--hard
模式进行Reset:
git reset HEAD~1 --hard
查看状态:
查看文件列表:
查看Commit记录:
可以发现,不仅Commit不见了,文件也消失了。
接着可以使用Reflog
命令来看一下记录:
- git reflog
当HEAD移动时(如切换分支或者Reset都会造成HEAD移动),Git就会在Reflog中留下一条记录。
所以如果想要取消这次的Reset,就可以“Reset到它Reset前的那个Commit”(很像绕口令)
。在这个例子中就是7d66c8c,所以只要这样:
git reset 7d66c8c --hard
就可以把刚刚hard reset的东西再次救回来了。
git log命令如果加上-g参数,也可以进行Reflog。
HEAD是一个指标,指向某一个分支,通常可以把它当作“当前所在分支”来看待。在.git目录中有一个名为HEAD的文件,其中记录的就是HEAD的内容。来看一下它到底长什么样:
cat .git/HEAD
从这个文件可以看出,HEAD当前正指向master分支。如果有兴趣再深入看一下refs/heads/master的内容就会发现,其实所谓的master分支也不过就是一个40个字节的文件罢了:
cat .git/refs/heads/master
假设当前项目包括3个分支,而当前正在master分支上:
- $ git branch
- cat
- dog
- * master
接下来试着切换到cat分支:
- $ git checkout cat
- Switched to branch 'cat'
这时看一下刚刚那个HEAD文件的内容:
- $ cat .git/HEAD
- ref: refs/heads/cat
HEAD的内容变成refs/heads/cat了。再试着切换到dog分支:
- $ git checkout dog
- Switched to branch 'cat'
再确认一下HEAD的内容:
- $ cat .git/HEAD
- ref: refs/heads/dog
它又改成指向dog分支了。也就是说,HEAD通常会指向当前所在的分支。不过HEAD也不一定总是指向某个分支,当HEAD没有指向某个分支时便会造成detached HEAD的状态。
在切换分支的同时,HEAD的内容会改变,当HEAD的内容改变的时候,Reflog也会留下记录。
假设index.html文件如下:
- <!DOCTYPE html>
- <html>
- <head>
- <meta charset="utf-8">
- <title>首页</title>
- </head>
- <body>
- <div class="container">
- <h1 id="heading">头版消息</h1>
- <div>内文 内文 内文 内文</div>
- <div id="footer">没有版权,随意使用</div>
- </div>
- </body>
- </html>
我们修改一下:
- <!DOCTYPE html>
- <html>
- <head>
- <meta charset="utf-8">
- <title>首页1</title>
- </head>
- <body>
- <div class="container">
- <h1 id="heading">头版消息1</h1>
- <div>内文 内文 内文 内文1</div>
- <div id="footer">没有版权,随意使用1</div>
- </div>
- </body>
- </html>
如果因为某些原因不想Commit footer区域,在Git中也可以先Commit其他的部分:
git add -p index.html
当使用git add
命令时,如果加上-p
参数,Git就会询问是否要把这个区域(hunk)加到暂存区:
- y - 暂存此区块
- n - 不暂存此区块
- q - 退出;不暂存包括此块在内的剩余的区块
- a - 暂存此块与此文件后面所有的区块
- d - 不暂存此块与此文件后面所有的区块
- g - 选择并跳转至一个区块
- / - 搜索与给定正则表达示匹配的区块
- j - 暂不决定,转至下一个未决定的区块
- J - 暂不决定,转至一个区块
- k - 暂不决定,转至上一个未决定的区块
- K - 暂不决定,转至上一个区块
- s - 将当前的区块分割成多个较小的区块
- e - 手动编辑当前的区块
- ? - 输出帮助
选择e,就会出现编辑器,显示以下内容:
在这里就可以编辑想要加到暂存区的区域。因为不想把footer区域加进去,所以就把那1行删掉,存档并离开即可“把部分内容加到暂存区”。看一下当前的状态:
可以看出,index.html文件有部分在暂存区,同时也有一份包括那1行的版本在工作目录。这样就可以先Commit部分内容了。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。