git使用以及常见git命令

Git 简单工作流理解

日常工作中，我们可能在 Git 使用上频繁交互的流程大致会是这样的（不同规范下会有一些区别，但是大差不大）：

1.来了一个新需求，我们会从 master checkout 一个新的 feature 分支出来进行开发。
2.开发完某个功能点，我们会执行 git add 将代码提交到暂存区。
3.执行 git commit 将代码提交到本地仓库
4.执行 git push 将代码提交到远端分支
5.当我们开发完所有需求之后，可能会设立一个专门的测试分支比如名叫 dev 的分支，那么我们就把代码合并到这个测试分支上，发布测试环境进行测试。
6.测试完毕之后，我们就需要合代码了，这个时候，我们可以发起一个 merge request，将我们的代码走 CR 流程合并到 master 分支。
7.在提交 MR 的过程中，我们一般需要先自己预先将 master 分支的代码合并到当前需要被合并的分支，提交并解决冲突。

以上流程大致概括了一般常规的 Git flow 流程，不同的公司可能会设计自己的规范，这里就不过多指示了。

命令概览

  • git stash
  • git clone
  • git init
  • git remote
  • git branch
  • git checkout
  • git add
  • git commit
  • git rm
  • git push
  • git pull
  • git fetch
  • git merge
  • git log
  • git reset
  • git reflog
  • git revert
  • git cherry-pick
  • git tag
  • git rebase

乍一看，眼花缭乱，当场决定放弃，还是用可视化工具吧。莫慌，且让笔者为你娓娓道来。

命令解析

一般来说，我们本地如果想要使用 Git 管理一些资源文件，首先我们需要有一个仓库才行。常用的方式莫过于，第一去 Gitlab / Github 先创建一个仓库，然后再拉到本地，那这个时候我们就可以用到我们的 clone 命令了。

git clone

最基础也是最常用的用法莫过于直接使用

  • git clone xxx.git

这样就能轻松把一个仓库代码拉到本地了，但仅仅知道这一点似乎还不太够。一般我们直接 clone 下来不带参数的话，它会默认停留在 master 分支，有的时候我们依旧需要一些其他诉求，比如怎么拉到本地之后自动切到指定分支呢？

  • git clone xxx.git -b branch1

有了仓库之后，我们总不能一直在 master 分支搞事吧，一般是不是都需要开个新分支改代码，再最后完事了再合到 master，那就需要用到下面介绍 git branch 命令了，不过呢，在讲到具体的分支操作之前呢，笔者还是要先补一下有关于本地仓库的初始化的流程。

git init

除了我们从远端建仓库，有的时候我们自己本地也是可以自己初始化一个 Git 仓库来操作的，这个时候我们就直接使用 git init 就能轻松为当前目录创建一个 git 仓库，也就能开始对当前目录的改动纳入版本管理库了。
不过本地 init 的仓库没法和远端进行交互，所以我们还是需要去 github/gitlab 创建一个远端仓库，然后关联一下，也就是 git remote 命令了。

git remote

用于和远程仓库进行关系绑定处理等等操作。

  • git remote add: 添加一个远程版本库关联
  • git remote rm: 删除某个远程版本库关联

比如我们本地有个初始化好的仓库，同时还有一个创建好的远程空仓库，那么我们就可以执行一下操作让他们关联起来：

  1. git remote add origin xxx.git先添加到本地仓库
  2. git push -u origin master：表示把当前仓库的 master 分支和远端仓库的 master 分支关联起来，后面我们执行 push 或者 pull 都可以非常方便的进行操作了。

git branch

在拿到一个项目之后，你首先还是应该看一下当前仓库现在有哪些分支，不要待会创建新分支发现名字重复之类的问题，那这个时候我们就可以使用 git branch 来查看一下相关的分支了。

  • git branch：查看本地所有分支信息
  • git branch -r：查看远程仓库所有分支
  • git branch -a：查看本地和远程仓库所有分支

一般来说如果分支太多的话，还是建议使用可视化工具来查看分支信息，比如 vscode 或者 source tree 等软件等等。

git checkout

如果我们想以当前分支为基准，创建一个新的分支并切换过去，可以使用如下命令。

  • 创建并切换到指定新分支：git checkout -b branch1

git add

我们在某个分支更改了代码之后，想要把它提交一下，那么你第一步要做的就是，执行 git add

  • git add [file1] [file2]: 添加一个或多个文件到暂存区

一般我们平时在使用的时候，用的比较多的应该还是：

  • git add .：把当前目录下得所有文件改动都添加到暂存区
  • git add -A：把当前仓库内所有文件改动都添加到暂存区

git commit

文件添加到暂存区之后，我们就可以执行下一步操作了。

  • git commit [file1] ... -m [message]：将暂存区的内容提交到本地 git 版本仓库中

  • -m 表示的是当前提交的信息

  • -a 对于已经被纳入 git 管理的文件（该文件你之前提交过 commit），那么这个命令就相当于帮你执行了上述 git add -A，你就不用再 add 一下了；对于未被 git 管理过的（也就是新增的文件），那么还是需要你先执行一下 git add -A，才能正确被 commit 到本地 git 库。

通常情况下，我们用的比较多得应该是 git commit -m 'feat: do something'，设置当前提交的信息。当然，如果你没有强诉求需要 git add 和 git commit 一定要分开，那你大可选择 git commit -am，方便又快捷。

git rm

这个其实也挺有用的，比如我们项目中有个文件叫 .env，这个文件是一个私有的，不能被提交到远程的，但是我们不小心提交到了本地仓库中，这个时候我们把这个文件添加到 .gitignore 文件中，表示需要被 git 忽略提交，但是由于我们已经提交到本地仓库了，所以如果不先从 git 仓库删除是没用的。
如果直接右键删除，那么这个文件的记录还是会被保存到远端仓库，别人还是能看得到你这个信息，所以我们需要先从 git 仓库中删掉这个文件才行。

  • git rm .env：执行完这个命令就表示 .env 文件从 git 仓库中删除了，配合 .gitignore 就能保证以后所有的 .env 文件变更都不用担心被提交到远程仓库。

  • git rm -r dist：如果我们要删除的是一个目录，那么加上 -r 参数就好了。

git push

接下来我们想要把刚创建好得分支推送到远端，一般来说我们可能会需要用到 git push，但我们这是个新分支，根本没和远端仓库建立任何联系，那么我们就需要加点参数，让他们关联上：

推送分支并建立关联关系：git push --set-upstream origin branch1

完事之后我们可以再去远程仓库看一眼就会发现我们创建的新分支已经推上去了。接下来可能会有小伙伴要问了，那如果远端仓库已经有了这个分支名咋整？
这里就分两种：

  1. 一种就是你本地的代码和远端代码没有冲突的情况下，并且你本地有新增提交，那么你可以仍然执行上述命令，这样就会直接将当前本地分支合远程分支关联上，同时把你的改动提交上去。
  2. 另一种就是本地分支和远端分支存在冲突，这个时候你执行上述命令就会出现提示冲突，那么接下来就需要你先把远端当前分支的代码拉下来，解决一下冲突了，就需要用到 git pull 命令了。

git pull

通常情况下，如果当前分支已经和远端分支建立了联系，那么我们想要合并一下远端分支，只需要执行 git pull 就好了，不用带其他参数，但如果和上面提到的 git push 时产生了冲突，还没有建立联系的时候，我们就需要指定需要拉取哪个分支的代码下来进行合并了。

  • 拉取指定远端分支合并到本地当前分支：git pull origin branch1

这里的 origin 是我们对远端仓库的命名，想改也是可以的，不过一般都是用的 origin。
回到上面提到的冲突问题，我们可以直接使用 git pull 然后指定合并当前本地分支想要建立联系的远程分支，然后本地解决一下冲突，然后提交一下改动，再执行 git push --set-upstream origin branch1 命令就大功告成了。

git fetch

了解完上面描述的 git pull，命令之后，其实这个命令也很好理解了，特定时候，可能我们只是想把远端仓库对应分支的变更拉到本地而已，并不想自动合并到我的工作区（你当前正在进行代码变更的工作区），等晚些时候我写完了某部分的代码之后再考虑合并，那么你就可以先使用 git fetch。
fetch 完毕之后，我提交了自己当前工作去的变更到本地仓库，然后想合并一下远端分支的更改，这个时候执行一下 git merge origin/[当前分支名]（默认一般是用 origin 表示远端的分支前缀）即可。

git merge

合并指定分支代码到当前分支。一般来说，我们用的比较多的场景可能是，远端仓库 master 分支有变更了，同时这个时候我们准备提 MR 了，那么就需要先合一下 master 的代码，有冲突就解决下冲突，那这个时候我们可以做以下操作：

  1. 切到 master 分支，git pull 拉一下最新代码
  2. 切回开发分支，执行 git merge master 合并一下 master 代码

同理，上面介绍的 git merge origin/xxx 也是一样的用法。

git log
顾名思义，就是日志的意思，执行这个命令之后，我们能看到当前分支的提交记录信息，比如 commitId 和提交的时间描述等等，大概长下面这样：

点击查看代码 
commit e55c4d273141edff401cbc6642fe21e14681c258 (HEAD -> branch1, origin/branch1)
Author: 陌小路 <44311619+STDSuperman@users.noreply.github.com>
Date:   Mon Aug 1 23:16:11 2022 +0800

    Initial commit

这个时候可能有读者会问了，这个都用来干啥的，简单的用法呢就是看看有谁提交了啥，还有更重要的用法呢就是进行代码版本的回滚，或者其他有意思的操作，且听笔者为你微微道来。

git reset

  • git reset [--soft | --mixed | --hard] [HEAD]

关于 HEAD：

  • HEAD 表示当前版本
  • HEAD^ 上一个版本
  • HEAD^^ 上上一个版本
  • HEAD^^^ 上上上一个版本

参数解析
以下解析均基于后接参数为 HEAD^，也就是git reset HEAD^。

  • --soft: 重置你最新一次提交版本，不会修改你的暂存区和工作区。
  • --mixed: 默认参数，用于重置暂存区的文件与上一次的提交(commit)保持一致，工作区文件内容保持不变。
  • --hard: 重置所有提交到上一个版本，并且修改你的工作区，会彻底回到上一个提交版本，在代码中看不到当前提交的代码，也就是你的工作区改动也被干掉了。

说了半天似乎不是很好理解，我们举个栗子理解下：

比如：

  1. 我改动了我的 README 文件，在我们的工作区就产生了一次改动，但是这个时候还没有提交到暂存区，在 vscode 里会显示为工作区修改的标记
  2. 接着我们执行 git add，这个时候你查看暂存区，会发现这次改动被提交进去了，同时被 vscode 标记为已被提交至暂存区
  3. 然后再执行 git commit，这个时候就完成了一次提交

接下来我们想撤回这次提交，以上三种参数所体现的表现会是这样的：

  • --soft：我们对 README 的更改状态现在变成已被提交至暂存区，也就是上面 2 的步骤。
  • --mixed： 我们对 README 的更改变成还未被提交至暂存区，也就是上面 1 的步骤。
  • --hard：我们对 README 的所有更改全没了，git log 中也找不到我们对 README 刚刚那次修改的痕迹。

默认情况下我们不加参数，就是 --mixed，也就是重置暂存区的文件到上一次提交的版本，文件内容不动。一般会在什么时候用到呢？
场景一
当你某个改动提交到本地仓库之后，也就是 commit 之后，这个时候你想撤回来，再改点其他的，那么就可以直接使用 git reset HEAD^。这个时候你会惊奇的发现，你上一版的代码改动，全部变成了未被提交到暂存区的状态，这个时候你再改改代码，然后再提交到暂存区，然后一起再 commit 就可满足你的需求了。
除了这种基础用法，我们还可以配合其他命令操作一下。
场景二
某一天你老板跟你说，昨天新加的功能不要了，给我切回之前的版本看看效果，那么这个时候，你可能就需要将工作区的代码回滚到上一个 commit 版本了，操作也十分简单：

  • git log 查看上一个 commit 记录，并复制 commitId
  • git reset --hard commitId 直接回滚。
posted @ 2022-09-21 17:16  yunChuans  阅读(122)  评论(0)  编辑  收藏  举报