常用系列就是记录自己编程常用的东西,此文为常用系列第 2 篇,用于记录自己日常常用的 Git 命令,以便需要时查找。Git 尽管提供了 GUI 界面进行操作,但是我觉得 Git 的 GUI 软件有很多,但是掌握最常用的命令还是一个合格的程序员应该做的,毕竟命令到哪里都一样,但 GUI 软件万一哪一天用不了了呢🐶,而且命令行模式可以执行 Git 的所有命令。
Git 最基本的操作#
文件从本地到仓库流程:以下记录一下用哪些命令可以将一个文件从自己的本地推送到远端的仓库,我把这称为基本操作
安装 Git#
如果想要在 Mac 电脑安装 Git,只需要输入查询 git 版本的命令就会提示你安装(如果你之前没装过的话)
配置用户信息#
安装完 git 之后对 git 的环境进行配置,这些配置在每台计算机只需要配置一次,当然配置完以后也可以修改,git 最常用的配置就是对用户名和邮箱地址的设置,
--global
代表对系统上所有仓库都生效。
Config 有三个作用域:当不明确设置是默认为 local
- local:只对某个仓库有效
- system:对系统所有登录的用户有效
显示 config 的配置#
获取 Git 仓库#
通常获取仓库有两种方式:
- 将本地目录转换为 Git 仓库
- 从别的地方复制一个仓库到你的本地
在已存在目录中初始化仓库#
这个命令会在当前目录下创建一个.git
的目录,目录中包括初始化仓库的所有文件
克隆仓库#
这个命令会从远端 GitHub 的 libgit2 仓库拉取所有东西到你当前目录
记录文件状态#
文件的状态有 2 种:已被跟踪、未被跟踪,跟踪的意思是现在 git 可以记录这个文件发生的所有变化(被修改、被删除、重命名)
查询文件状态#
跟踪新文件#
使用该命令之后,文件就会被放入 git 的暂存区,暂存区里面的文件都是即将要推送到远端仓库的候选者。
对比区别#
对比已暂存的文件与未暂存文件之间的区别
通常我们修改文件过多时就会容易忘记某个文件修改过的内容,这个时候就需要查看我们做过哪些修改就可以使用
diff
命令
如果你想对比暂存区里的文件与上次提交时文件的区别,就可以使用以下命令
也可以对比两次不同 commit 之间的区别
给文件和文件夹重命名#
git mv 是 Git 中用来重命名或移动文件或文件夹的命令
提交更新#
如果你的暂存区里面已经包括你本次想要提交的文件,就可以通过
commit
命令对文件的修改进行提交
推送文件到远端#
添加远端仓库#
如果你不是从远端仓库克隆 clone 的文件,而是自己在本地自己创建的 git 仓库,就需要在向远端仓库推送之前加上你要推送的仓库
推送#
这个命令代表着将 master 分支的代码推送到远端的 origin 服务器
到此一个文件从创建到最终同步到远端仓库的这个过程就圆满完成。
下面就记录一下在使用 git 的过程中遇到一些情况该使用哪些命令。
提交操作#
修改上一次(最近一次) Commit#
- 修改上次 commit 填的信息
- 基于上次的 commit 再次添加修改或者添加文件
以上的情况都可以使用以下这个命令
查询#
这里的记录是使用 git 场景下各种需要查的情况
查提交历史#
整个项目历史提交记录#
输出的内容依次是:
- 每个提交的 SHA-1 校验和
- 提交人的名字
- 邮箱地址
- 提交时间
- 提交说明
文件的历史提交记录#
查看单个文件每次的提交记录
每一行的提交记录#
能显示任何文件中每行最后一次修改的提交记录
查找 BUG#
很多时候,当前分支出现问题了,但不清楚哪里出现了问题,就可以使用
git bisect
命令查找哪一次代码提交引入了错误
这个命令使用的原理是二分查找的原理:
通过二分【代码是没问题的提交 ~ 当前有问题的分支】这个范围找到可能有问题的那一次提交
git bisect start
命令启动查错,它的格式如下:
终点是最近的提交,起点是更久以前的提交。它们之间的这段历史,就是差错的范围
当不清楚哪个起点提交时没问题的时候可以选择最开始的分支
执行上面的命令以后,当前的代码就会切换到这段范围当中中间的那一次提交
然后你就可以对当前代码进行测试,如果是没有问题就执行以下命令对本次提交进行标识
如果没问题就意味着错误是在代码历史的后半段引入的。执行上面的命令,Git 就自动切换到后半段的中点
然后再进行测试,如果是有问题的就标识这个提交是有问题的
到这里不是就结束了哦,有问题只是这次有问题,但我们需要找到第一次有问题的提交
接下来,不断重复这个过程,直到成功找到出问题的那一次提交为止。这时,Git 会给出如下的提示。
然后就可以去分析这次都提交了哪些文件,从而分析错误是什么原因引起的
注意:代码缺陷需要自己去判断的,git 是没办法帮你分析出哪里有问题
然后,使用git bisect reset
命令,退出查错,回到最近一次的代码提交。
查找内容#
由于 git 与 Linux 命令一样,同样可以与
grep
搭配使用
撤销#
我们在操作 Git 的时候难免会出现出错的时候,修改错误的办法一般不是重新修改就是回退到没问题的时候
文件的撤销#
工作区的操作#
- 将文件尚未加入暂存区的修改全部撤销
- 将工作区相对于暂存区的修改撤销,如果暂存区没有对应的文件则回退到 HEAD 指向的版本
暂存区区的操作#
- 将暂存区的文件修改撤销掉(unstage),重新放回工作区
版本的撤销#
常用于提交版本之后,远端发生冲突无法 merge 分支,用
git resrt
回退版本处理完冲突后再进行推送
堆栈操作#
平时开发的时候会经常出现一个需求开发到一定程度,本地代码已经修改很多了,但是突然有一个临时的 BUG 需要紧急处理,这个时候已经修改过的代码就可以通过放进 git 的堆栈中进行保存,等 BUG 处理完之后再恢复现场继续需求的开发
分支操作#
分支基本操作#
merge#
用于合并两个分支
rebase#
也用于分支合并
合并分支的操作与 merge 基本一样,
如果 git rebase 遇到冲突:
- 第一步手动解决冲突,然后把新修改的文件加入暂存区
git add .
- 之后并不需要
git commit
,而是直接运行git rebase --continue
至于git merge
与 git rebase
有什么区别呢?
git merge
合并完之后会显示出来合并之前的分支,而git rebase
合并之后看起来并不会有之前合并的分支记录- 分支合并的顺序也不一样
详细可以看一下这个博客 git merge 和 git rebase 小结
cherry-pick#
合并指定提交到当前分支
如果 cherry-pick
过程中发送冲突,则在手动处理完冲突之后使用--continue
命令让过程继续
- 解决代码冲突后,将修改的文件重新加入暂存区
git add .
- 使用下面的命令,让 Cherry pick 过程继续执行。