分享一篇通俗易懂的可视化Git命令

前言

今天分享一篇不错的文章，描述的内容是Git Commands。展开描述了一些使用的案例，来创建一些最常见和最有用的命令的可视化例子！

本文使用的是默认的指令行为，不需要添加太多的配置，每个覆盖的命令有很多的可选参数，你可以动手来改变它们的行为。

一些指令

Merge

拥有多个分支是非常方便的，可以让新的变更相互分离，并确保你不会意外地将未经批准或损坏的变更推送到生产中。一旦变更被批准，我们就想把这些变更放到生产分支中去。

从一个分支到另一个分支的方法之一是执行 git 合并。Git 可以执行两种类型的合并：一种是快进，一种是不快进。这可能现在还不是很明白，那我们就来看看两者的区别吧!

Fast-forward (--ff)

快进（--ff）

当前分支与我们要合并的分支相比，没有额外的提交时，就会发生快进式合并。

Git 是个......懒惰的家伙，会先尝试执行最简单的选项：快进！这种类型的合并并不创建新的提交，而是合并当前分支上的提交。

这种类型的合并并不创建新的提交，而是将当前分支上的提交合并到当前分支上。

完美！我们现在已经将开发分支上的所有修改都放到了主分支上。现在，我们已经将开发分支上所做的所有改动都放到了主分支上。那么，这个 "不快进 "是怎么回事呢？

No-fast-foward (--no-ff)

如果你的当前分支与你要合并的分支相比，没有任何额外的提交，那是很好的，但不幸的是，这种情况很少！如果我们在当前分支上提交了改动，而我们要合并的分支却没有，那么git就会执行不快进式合并。如果我们在当前分支上提交了一些变化，而我们要合并的分支却没有，那么 git 就会执行不快进合并。

在进行无快进合并时，Git 会在当前分支上创建一个新的合并提交。该提交的父提交同时指向活动分支和我们要合并的分支。

没什么大不了的，一个完美的合并！主分支现在包含了我们在开发分支上的所有改动。

Merge Conflicts

合并冲突也是我们日常开发中不可避免的一个过程。

虽然Git很擅长决定如何合并分支和添加文件的修改，但它并不总是能自己做出决定。这可能发生在我们试图合并的两个分支在同一文件的同一行有修改，或者一个分支删除了另一个分支修改的文件，等等。

在这种情况下，Git会让你帮忙决定我们要保留这两个选项中的哪一个! 假设在两个分支中，我们都编辑了 README.md 中的第一行。

如果我们要把dev合并成master，这将最终导致合并冲突：你希望标题是Hello?还是Hey？

当尝试合并分支时，Git会告诉你冲突发生在哪里。我们可以手动删除我们不想保留的改动，保存改动，再次添加改动后的文件，然后提交这些改动:

这里图片帧数太大了，上传不了，可以复制链接:

虽然合并冲突往往很烦人，但它完全有道理。Git不应该只是假设我们想保留哪一个变化。

Rebasing

开发中，变基也是我们通常需要做的。

我们刚刚看到了如何通过执行 git merge 将一个分支的更改应用到另一个分支。另一种将一个分支的修改添加到另一个分支的方法是执行 git rebase。

git rebase 会复制当前分支的提交，并将这些复制后的提交放在指定分支之上。

很好，我们现在可以在开发分支上看到所有在主分支上做的修改了！我们可以在开发分支上看到所有在主分支上做的修改。

与合并相比，最大的不同是，Git不会试图找出哪些文件要保留，哪些文件不要保留。我们要重新归类的分支总是有我们想保留的最新改动！这样一来，就不会有任何合并冲突，而且还能保持良好的线性 Git 历史。这样一来，您不会遇到任何合并冲突，而且还能保持良好的线性 Git 历史。

这个例子显示了在主分支上的重归类。然而，在大型项目中，你通常不希望这样做。git重归会改变项目的历史，因为新的哈希会被创建在复制的提交上。

每当你在一个功能分支上工作，而主分支已经更新时，重命名是非常好的。你可以在你的分支上获得所有的更新，这将防止未来的合并冲突!

Resetting

可能发生的情况是，我们提交了一些我们后来不想要的改动。也许是一个WIP提交，或者是一个引入了bug的提交！在这种情况下，我们可以用一个新的方法来解决这个问题。在这种情况下,我们需要使用 git reset。

git reset 重置可以摆脱所有当前的阶段性文件，并让我们控制 HEAD 应该指向哪里。

Soft reset

soft reset 将 HEAD 移动到指定的提交（或与 HEAD 相比的提交索引），而不会删除之后提交中引入的变化！这就是soft reset。

假设我们不想保留添加了style.css文件的提交9e78i，也不想保留添加了index.js文件的提交035cc。然而，我们确实想保留新添加的style.css和index.js文件。这是一个完美的软复位案例。

当输入 git status 时，你会发现我们仍然可以访问之前提交的所有更改。这很好，因为这意味着我们可以修正这些文件的内容，并在以后再次提交！这也是我们的一个优势。

Hard reset

有时，我们不想保留某些提交所带来的变化。与软重置不同，我们不需要再访问它们。Git 应该简单地将它的状态重置回指定提交时的状态：这甚至包括了工作目录和暂存文件中的变化！而不是像软重置一样，我们不应该再去访问它们。

Git 抛弃了在 9e78i 和 035cc 上引入的改动，并将其状态重置为提交 ec5be 时的状态。

Reverting

另一种撤销修改的方法是执行 git revert。通过还原某个提交，我们创建了一个新的提交，其中包含了被还原的更改！这就是我们的方法。

比方说，ec5be增加了一个index.js文件。后来，我们其实意识到我们不想要这个提交引入的这个变化了! 让我们恢复ec5be的提交。

完美 提交 9e78i 还原了 ec5be 提交引入的修改。执行 git revert 非常有用，可以在不修改分支历史的情况下撤销某个提交。

Cherry-picking

• 当某个分支包含了我们需要在活动分支上进行修改的提交时，我们可以使用 cherry-pick 命令！

• 通过 cherry-pick 命令，我们可以在活动分支上创建一个包含 cherry-pick 提交的修改的新提交。

• 通过cherry-pick命令，我们在活动分支上创建了一个新的提交，该提交包含了cherry-pick提交所引入的变更。

假设在开发分支上的提交76d12对index.js文件进行了修改，而我们希望把它放在主分支上。我们不需要整个分支，我们只需要这一个提交。

这样子操作过后，主干分支现在包含了76d12引入的变化!

Fetching

如果我们有一个远程 Git 分支，比如 Github 上的一个分支，可能会发生远程分支的提交内容是当前分支没有的！可能是另一个分支合并了，你的同事推送了快速修复，等等。也许另一个分支被合并了，你的同事推送了一个快速修复，等等。

我们可以通过在远程分支上执行 git fetch 来获取这些变化！这不会影响你的本地分支：fetch 只是下载新数据。它不会以任何方式影响你的本地分支：获取只是下载新数据。

现在，我们可以看到自上次推送以来所做的所有更改！我们可以决定如何处理新的数据。我们可以决定我们想对新数据做什么，现在我们已经在本地拥有了它。

Pulling

虽然git fetch对于获取分支的远程信息非常有用，但我们也可以执行git pull。

git pull实际上是两个命令合一：

• 一个是git fetch。
• 一个是git merge。

当我们从原点拉取变更时，我们首先要像git fetch那样获取所有数据，之后将最新的变更自动合并到本地分支中。

太棒了，我们现在与远程分支完全同步了，并且有了所有最新的变化。

Reflog

每个人都会犯错，这完全没问题！有时候，你可能会觉得自己把git repo搞砸了，以至于想把它完全删除。有时候，你可能会觉得自己把git repo搞砸了，以至于你想把它完全删掉:

git reflog 是一个非常有用的命令，它可以显示所有已经进行的操作的日志！这包括合并、重置、还原：基本上所有对分支的修改。这包括合并、重置、还原：基本上是对你的分支进行的任何修改。

如果你犯了错误，你可以根据reflog给我们的信息重新设置head，轻松重做!

• 假设我们其实并不想合并原生分支，那么当我们执行git reflog命令时，会发现合并前的repo状态是在HEAD@{1}。

• 当我们执行 git reflog 命令时，我们看到合并前 repo 的状态是在 HEAD@{1}。

• 让我们执行 git 重置，把 HEAD 指向 HEAD@{1} 的位置吧!

我们可以看到，最新的行动已经被推到了重新登录！

结束语

Git在团队开发中还是很重要的，本篇文章分享了部分Git命令，还是挺容易懂的，推荐阅读。

我是TianTian，我们下一期见！！！

来个【分享、点赞、在看】三连支持一下吧

   “分享、点赞、在看” 支持一波