🔥🔥 欢迎来到小林的博客!!
🛰️博客主页:✈️林 子
🛰️社区 :✈️ 进步学堂
🛰️欢迎关注:👍点赞🙌收藏✍️留言
创建仓库
命令:git init
使用后会在当前目录创建一个.git文件。
仓库配置
仓库创建完之和,我们还需要配置name和email信息。
当前仓库配置命令:
git config user.name "your name"
引号处填你的git用户名
git config user.email"your email"
引号处填你的git邮箱
执行结果:
我们就会发现user.name和user.email配置成我们自己的了。
那么我们想修改怎么办呢?
我们可以用git config --unset user.name/email
来重置配置。
这样我们的user.name 和 user.email就被重置了。
但是如果我们想要当前机器上所有的仓库都配置,而不是仅仅只配置一个。那么我们可以用全局配置命令。
全局配置命令:
git config --global user.name ”your name“
git config --global user.email”your email“
而全局配置是无法用局部配置删除的。例如:
全局变量删除:
git config --global --unset user.name
git config --global --unset user.email
文件提交
git文件提交是先将工作区的内容添加进暂存区,随后从暂存区上传至本地仓库。
工作区:就是你当前仓库下非.git/文件夹的区域。
暂存区:git add后,文件暂存的区域。
本地仓库:git commit 后,将暂存区域的文件提交到本地仓库。
命令:
git add 文件名/.
文件名是添加单个文件至暂存区,.是添加当前目录所有文件至暂存区。
git commit -m "提交描述"
提交描述要描述文件提交的一些细节。
我们touch一个文件ReadMe,并在里面写上hello git。
这样我们的文件就提交成功了,如果有提交到远程仓库,那么可以用git push命令,具体操作可以看我之前写的博客 git提交三把斧
版本回退
什么是版本回退呢?
就比如你写了一个文档,第一次提交为v1版本,第二次提交为v2版本。当我们提交到v20个版本的时候,突然想回到第10个版本。这就是版本回退,而git里面有一个objects对象来存储每次修改后的版本。
版本回退的命令:
git reset [--soft | --mixed | hard] [head]
--soft
选项只会回退版本库,而不会回退暂存区和工作区。
--mixed
则会回退版本库和暂存区,不回退工作区,如果选项不填,该选项为默认选项。
--hard
工作区,暂存区,版本库统统回退。如果此时你工作区写了新的数据还没来得及提交,那么该选项会让你的v10版本后写的代码统统消失!所以该选项请慎用。
我们用v20来描述当前版本,v10来描述回退版本。
工作区 | 暂存区 | 版本库 | 回退选项 |
---|---|---|---|
v20 | v20 | v10 | –soft |
v20 | v10 | v10 | –mixed(默认) |
v10 | v10 | v10 | –hard(慎用) |
接下来我们用–hard选项来演示一下版本回退。
我们先往ReadMe里面添加一行hello world,然后提交,更新至版本v2
然后我们再创建2个文件 file1 和 file2,再次提交,更新至版本v3
现在我们的目录下是有三个文件的,分别是file1,file2 和 ReadMe。
然后我们用命令 git log --pretty=oneline
来查看之前的提交信息。
前面那一串是用哈希计算出的一串16进制数字,它对应的是每一个回退的版本,回退版本存储在objects文件夹中。
而我们要回退哪个版本,就输入哪个版本即可。
我们输入 git reset --hard 182eaf20b1263fa1a548ca946af9eb53f514f805
回退到v1版本。
然后我们就发现,我们的目录只剩下一个文件,并且该文件的内容是hello git。说明我们的版本成功回退到了v1版本。 用–hard选项只是为了直观的演示回退效果,实际运用中用hard的话,你的工作区内容就会被覆盖掉。那么你之后写的代码也就没有了。
如果这时候右想回退回去呢? 我们用 git reflog
来查看一下历史输入的指令。
然后输入 git reset --hard 93c817a
回退回去即可。
注意! reflog只显示最近几条的提交记录,也就是说有可能会被覆盖掉。那么到时候就无法回退了。
小问题:为什么回退版本会这么快?
这是有一个HEAD指针指向master,而master则是存储的对象id(就是上面回退时所用的一串16进制数字)。
我们查看一下master里面的内容,就能看见它实际只是存储了一个对象id,这个对象id对应着objects里面存储的版本对象。
撤销修改
当我们写着写着发现自己写的代码太垃圾了,想撤销掉修改怎么办?
我们分三种情况来讨论:
第一种情况:写的代码还没有上传至暂存区,只在工作区中。
这种情况我们可以直接对文件修改,删除文件代码,但是这种方法不推荐。一是删除效率很慢,二是如果删错了可能会让代码产生bug。
第二种方法则是用命令: git checkout -- 文件名
来对问进行回退。
我们先给ReadMe随便加上一行数据,然后用命令对它进行回退。
回退成功!
第二种情况:写的代码已经上传到了暂存区,但还没提交到版本库。
第二种情况就是文件在工作区和暂存区,但是还没有提交到版本库。那么我们可以使用上面说过的reset选项来回退到当前版本,你没听错,reset是可以回到当前版本。我们用 reset --mixed可以把暂存区和版本库都回到当前版本,这时候就转换成了第一种情况,我们在用checkout – 来回退文件版本。
接下来我们演示一下:
我们先在ReadMe文件下面新增一行,然后把它添加进暂存区。
然用 git reset HEAD
回退到当前版本, HEAD指当前版本。
然后我们发现它提示我们暂存区没有可以提交的文件,这时候我们就可以当作第一种情况来处理,回退ReadMe文件。
输入 git checkout -- ReadMe
回退
回退成功!
第三种情况: 写的代码上传到了暂存区,并且还提交到了版本库。
第三种情况就是我们的代码已经提交到版本库了。也就是当前版本下是包含了xxxx code代码的,那么上一个版本肯定就是没有包含xxxx code代码的。那么我们只需要回退到上一个版本即可。
该情况回退有一个前提! 那就是该仓库还没有push至远程仓库!
演示:
先添加一行xxxx code,然后添加至暂存区,上传至版本库。
然后用 git reset --hard HEAD^
回退,HEAD表示上一个版本,HEAD^表示上上个版本,以此类推。
回退成功!
文件删除
当我们的文件已经上传到了版本库种,如何删除它呢?
我们可以使用 git rm 文件名
来删除,之和在git commit -m
来提交变动即可。
分支管理
分支就类似于支线任务,主支则是master。分支就是master的分身,分支做的事情最终都可以合并到master种。
打个比方:master的任务是练习葵花宝典,而练习葵花宝典需要五天。如果此时master想在五天内同时练习葵花宝典和辟邪剑法。那么它可以开一个分支,让分支去练辟邪剑法,自己练葵花宝典。五天后让分支合并过来,那么此时的master就既会葵花宝典,也会辟邪剑法。
创建分支
我们可以用git branch name
来创建分支 。
也可以用 git branch
来查看分支。
切换分支
我们可以用git checkout 分支名
来切换分支。
合并分支
我们要知道.git/HEAD 指针指向的就是一个分支,也就是说,HEAD指向哪个分支,那么你上传就会上传到哪个分支。
我们切换到到dev分支。
随后我们修改ReadMe里的内容并上传到版本库。
这时候我们在dev分支内查看ReadMe的内容。然后在切换到master分支查看内容,我们会发现master还停留在之前的版本。
而我们再对照一下 .git/refs/heads目录下dev和master的内容。
我们可以发现它们记录的提交版本是不一样的,简单来说就是master分支停留在之前的版本。这时候我们就可以合并分支。
合并分支命令:git merge 分支
我们合并分支后就会发现ReadMe更新了。
我们再来看看heads目录下两者的最新提交版本信息。
可以发现它们的提交版本是一样的。所以所我们的分支合并是非常快的,因为它只需要修改 ./git/refs/heads/master
中的提交版本即可。
删除分支
删除分支命令: git branch -d 删除的分支名
不过删除分支要注意的一点是,不能在当前分支下删除当前分支,只能在其他分支下删除你要删除的分支。
所以我们切换到master分支后,即可删除分支。
然后我们就成功删除了dev分支。
有时候 git branch -d 删除的分支名
可能会不成功,此时我们用 git branch -D 删除的分支名
即可进行强制删除。
合并冲突
当我们的分支和master同时修改了该文件时,那么此时合并就会发生冲突。
此时我们的ReadMe内容是这样的:
首先我们创建一个分支dev1,然后把ReadMe的最后一行修改为bbbb code。
然后add -> commit -m 更新
然后我们切换回master分支,把ReadMe修改为cccc code。
然后master也 add -> commit -m 提交
然后我们合并分支
然后就提示我们在ReadMe内有一个冲突,并让我们修复冲突后重新提交结果。
那么我们打开ReadMe文件修复一下冲突。
我们就发现 了一些奇怪的东西, HEAD -> ====区间是当前master的内容, 剩下的是dev1的内容。意思就是让你选择其中一个分支的内容,我们选择bbbb code,那么就把其他的删除掉。
然后保存退出,并且重新提交一次。
此时我们的冲突就修复成功了。
我们再来看看dev1和master的最近一次提交。
我们会发现不一样,因为master后面解决合并冲突时又重新提交了一次。我们可以输入git log --graph --abbrev-commit
来查看提交日志。
此时我们就能清除的看到,master的最新提交为什么和dev1的不一样。
而以上的合并模式是fast forward模式,我们也可以使用非fast forward来合并文章来源:https://www.toymoban.com/news/detail-625514.html
命令:git merge --no--ff -m “描述” 合并的分支
文章来源地址https://www.toymoban.com/news/detail-625514.html
到了这里,关于Git用法指南(建议收藏)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!