可视化 Git

丹吉特·吉特

丹吉特·吉特

是的，Git 有时会很复杂，但这并不意味着除非您是 Git 专家，否则就无法理解它。大家可能在开发阶段的某个阶段都使用过 Git，并且熟悉它的基础知识。今天，我将向大家展示这款工具的独特之处，以及我们遇到问题时该如何应对。

宝贝，把东西形象化

下面的表示是我们的视觉工作空间。

这是我们的存储库，其中包含多个提交和分支。首先，我们在顶部有一个初始提交（树的根），之后我们有 3 个提交（添加贡献者、改进和重构），它们的父级是相同的。如你所见，我们也有 3 个分支，分别是master、feature1和feature2。我们还有HEAD，我们稍后会讨论
它。为了使其更容易理解，我将向你展示在执行相应的 git 命令时视觉表示如何变化。通过这样做，我们将注意到命令和 git 行为之间的关系。

HEAD 和 HEAD~ 等是什么？

我们会不时地在可视化图表中移动HEAD ，但这个神奇的特殊词究竟是什么呢？让我解释一下， HEAD只不过是 Git 工作流程中的一个指针，它只是标记了你所在的位置。就是这样。只需将HEAD视为指向地图上你所在位置的箭头即可。现在，为了标记其他位置，我们可能需要一个参考点，对吧？例如，如果我需要向某人解释提交重构的位置，我只需说“转到 HEAD 上方 2 个提交”，你就能找到它。因此，HEAD~1相当于说“HEAD 上方的提交”，类似地，HEAD~2相当于说“HEAD 上方 2 个步骤的提交”。顺便说一下，HEAD~与HEAD~1相同，所以这里没有什么花哨的东西，我们程序员很懒，你知道的。

为了证明我们的观点，让我们执行git checkout feature2。

HEAD移动到了feature2 的位置，嗯，这很简单。现在回到 master 分支，我们继续。

什么是--soft和--hard

这些是刚开始学习 git 时最容易被误解的概念。我简单举个例子，让它更容易理解。想象一下，你正在搭建一座纸牌塔，就像你小时候那样，有一只凶猛的猫在附近徘徊。突然，你妈妈叫你去吃饭，你不得不去。如果你带着你的纸牌塔，这是一个软选择。你不想让你的猫破坏你的进度，所以你把塔（你的更改）带走了。相反，如果你决定保持原样，那只凶猛的猫肯定会把它拆掉，这是一个硬选择。这个硬选择会无限期地丢弃你所做的所有更改，所以要谨慎使用。

总之：

• git reset --soft HEAD~- 后退一次提交并保留您的更改
• git reset --hard HEAD~- 后退一个提交并放弃所有更改

1-修改提交？

有时您可能会提交正在进行的工作并立即意识到您忘记在提交中添加一些内容。

• git add- 添加您忘记添加的丢失/修改的文件
• git commit --amend --no-edit- 修改前一次提交（--no-edit如果要修改提交消息，请删除）

这会将你的提交替换为一个全新的提交。现在让我们看看可视化图表中发生了哪些变化。哦，看看这个，只有修改了提交的哈希值。这意味着我们更改了此提交的内容。

2 – 提交给 master 而不是新分支？

我们当时漫不经心地工作，完成了工作，结果提交到了 master 分支，而不是其他分支。啊，真是个愚蠢的错误。你可以在下面的图表中看到我们的错误。我向你保证，这个问题很容易修复。

• git branch feature3- 在您当前职位上创建一个新分支
• git reset HEAD~ --hard- 将 master 恢复到之前的提交
• git checkout feature3- 切换到你的新分支

让我们看一下图表。好的，看起来我们现在有了一个名为feature3的分支，并且我们成功地将主分支恢复到了它原来的位置。HEAD指向了feature3分支，这正是我们根据上面最后一个操作所期望的。

3 – 提交到错误的分支！

你提交到错误的分支了？这种情况很常见，而且很容易修复，除非你已经推送了更改（请告诉我你没有推送）。如果你还没有推送更改，那就太好了。如果你已经推送了更改，那我们稍后再处理。我们先解决比较容易的问题。

• git reset HEAD~ --soft- 回到上一次提交并保留更改
• git stash- 存储你的更改，以便我们可以切换分支

• git checkout feature2- 切换到另一个分支
• git stash pop- 从存储中解压你的更改

• git add .- 添加文件并正常提交
• git commit -m "fixed"

4 - 我想恢复 10 天前的这个特定提交

是不是总有那么一刻，你需要撤销几天前的更改？Git 可以帮你搞定。

• git log- 找到你想要恢复的提交的哈希值
• git revert <hash>

此操作会创建一个还原提交，这意味着它不会修改任何先前的提交，而只是创建一个包含完全相反文件修改的新提交。这很酷。您可以在下面看到这个反向提交，一个全新的提交。

5 – 哦，该死，我做错了一件大事，我丢失了我的承诺！

这个问题很棘手。我们最好先想象一下，这样才能一步步理解接下来会发生什么，因为我的朋友，大多数初学者都害怕进入“分离”状态。好了，玩笑归玩笑，说真的，当我第一次遇到类似的情况，不得不进入“分离”状态却做错了什么的时候，我感到非常迷茫，尽管我并没有完全迷失。这就是为什么我们会付出额外的努力，让它变得更加透明。

想象一下检查一个特定的提交，在本例中是重构。

$ git checkout c5b64
Note: checking out 'c5b647'.

You are in 'detached HEAD' state...

好吧，这到底是什么意思？冷静点，注意安全，除了前面提到的硬重置，或者干脆删掉你的文件夹，彻底结束这种痛苦之外，git 里几乎没有什么操作是无法恢复的。分离的 HEAD状态意味着你直接指向一个提交，而不是指向一个分支。就这样？耶！实验时间到！既然我们指向的是单独的提交，那就修改一下，然后提交，看看会发生什么。

看来我们仍然处于那个邪恶的分离 HEAD状态。假设我们在不了解 Git 细节的情况下执行了这样的操作，并通过 切换回 master 分支git checkout master。显然，我们现在知道了，git checkout master其最基本的形式就像是说“继续，直接指向 master 分支”。

你看，我们在某个分支上检出了一个未知的提交，做了一些修改，并以“重构后的一些修改”的名称提交，然后移回了主分支，对吗？现在请注意，由于你不知道那个“重构后的一些修改”提交的哈希值，而且它也没有明确的分支关联，所以你无法知道它是否存在。因此，你会觉得，在所有的开发和改进之后，你失去了一切，是时候从零开始了。就此打住，因为git reflog救援来了。

我们可以检查此命令的输出：

$ git reflog
5b35f6d HEAD@{1}: pull ...
ca92d15 HEAD@{2}: ...
759dab1 HEAD@{3}: commit (merge): ...
065e269 HEAD@{4}: commit: ...
f357606 HEAD@{5}: commit: ...
9u7b45 HEAD@{6}: checkout: moving from master to 9u7b45d272867b63d54f96d4aa57f8ecc479cd0

这9u7b45 HEAD@{6}: checkout: moving from master to 9u7b45d272867b63d54f96d4aa57f8ecc479cd0应该能让你大致了解自己做了什么，也就是说，你之前已经切换到了无分支提交。现在，你珍贵的小提交就在那里，它漂浮在空间中，没有任何标签。现在，去那里给它加个标签，或者说，创建一个分支，随便什么都可以。

我已经完成了 GIT！

如果你真的完成了我解释的这些疯狂的版本控制内容，这里有一个最终的解决方案：D

cd ..
sudo rm -r ducking-git-repo-dir
git clone https://some.github.url/ducking-git-repo-dir.git
cd ducking-git-repo-dir

继续将工作文件夹复制到 ->“/home/git_bender/last_last_final_version_of_git_tutorial/”

灵感来自Dangitgit。