Git命令学习--基础篇

前言

一些关于Git命令的总结和原理分析，帮助小伙伴们更清晰的理解。

目录

前言

一、Git Commit

二、Git Branch

三、Git Checkout

四、Git Merge 

五、Git Rebase

总结

---

一、Git Commit

        Git Commit 提交记录到本地仓库，其特点：1.快照：提交记录相当于你目录下所有文件的一个完整状态备份，就像复制并粘贴整个目录，但更加高效和优雅。2.轻量化：每次提交时，Git 不会复制整个目录，而是仅记录与上次提交的不同之处，从而保持提交记录的轻量化。3.历史记录：每个提交都有一个或多个父节点【我会在图示中用箭头来表示这种关系】，形成了一个连续的历史记录链，这有助于团队成员理解和追踪项目的演变。4.快速切换：由于提交记录轻量且结构化，可以在不同的提交之间快速切换，方便回溯和比较不同版本。

        下面我将以图画的形式来展示提交记录是怎样的。下图模拟了一个（小型）Git 代码库。当前有两个提交记录【设初始提交 C0 和 修改的提交 C1】。main*为当前使用的分支，黑色箭头指向父节点c0。记住后边要考！！！

Git Commit未执行前

        当我们提交代码到本地仓库后，本地代码库就被修改了，并把这些修改保存成了一个提交记录 C2。C2 的父节点是 C1， 父节点是当前提交中变更的基础。 

Git Commit执行后

二、Git Branch

        Git Branch<分支名>创建分支，其特点1.轻量分支：Git 分支只是简单地指向某个提交记录，因此创建分支几乎不占用存储或内存资源。2.最佳实践：建议尽早创建分支并频繁使用分支，因为这比维护臃肿的分支更简单且逻辑清晰。

        下面让我们来看看分支是什么样子吧！如下图设我们要创建一个名为newImage的分支

Git Branch newImage未执行前

        执行Git Branch newImage后，新创建的分支newImage指向的是提交记录 C1。 

Git Branch newImage执行后

      接下来我们结合上边学的Git Commit,我们尝试着往新分支里提交一些东西，看看会发生什么？

Git Commit执行后

哎呀！为什么 main 分支前进了，但 newImage 分支还待在原地呢？！

        这是因为我们没有“在”这个新分支上，看到 main 分支上的那个星号（*）了吗？这表示当前所在的分支是 main。都说了要考还不信！！所以我们得先切换分支。

三、Git Checkout

        Git Checkout<要切换的分支名>，回归上题在我们新建分支newImage 之后，我们先切换分支为newImage ，在提交记录。

Git Checkout newImage;Git Commit执行后

        接下来我们可以结合创建分支，进行补充Git Checkout -b<分支名>创建并切换到该分支。注意：在Git 2.23版本中，引入了一个名为git switch的新命令，最终会取代git checkout，因为checkout作为单个命令有点超载（它承载了很多独立的功能）

四、Git Merge 

        Git Merge<指定分支名>将指定分支合并到当前的分支中，这是合并分支的第一种方法，往下我们还会介绍第二种方法。Merge合并两个分支时会产生一个特殊的提交记录，它有两个父节点。翻译成自然语言相当于：“我要把这两个父节点本身及它们所有的祖先都包含进来。”

        如下图，我们有两个分支bugFix和main，每个分支上都有一个独有的提交C2和C3，我们把bugFix合并到当前的分支main中，看看会发生什么吧？

Git merge bugFix未执行前

        当我们执行Git merge bugFix后，首先我们可以看到，当前分支main指向了一个拥有两个父节点的提交记录C4。假如从 main 开始沿着箭头向上看，在到达起点的路上会经过所有的提交记录。这意味着 main 包含了对代码库的所有修改。

Git merge bugFix执行后

补充：上步操作后main分支包含了对代码库的所有修改，而bugFix分支不能，如果我们再把main分支合并到bugFix中，则两个分支都实现了代码库的修改。Git只是简单把 bugFix移动到 main所指向的那个提交记录。是因为 main继承自 bugFix，如下图所有提交记录的颜色都一样了，这表明每一个分支都包含了代码库的所有修改！大功告成！

Git checkout bugFix;Git merge main执行后

五、Git Rebase

        Git Rebase<指定分支名>将当前分支的提交重新应用到指定分支的顶部，这是合并分支的第二种方法。Rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下Rebase 的优势就是可以创造更线性的提交历史，这听上去有些难以理解。如果只允许使用 Rebase 的话，代码库的提交历史将会变得异常清晰。

        如下两个分支，注意当前所在的分支是 bugFix（星号标识的是当前分支），我们想要把 bugFix 分支里的工作直接移到 main 分支上。移动以后会使得两个分支的功能看起来像是按顺序开发，但实际上它们是并行开发的。

Git rebase main未执行前

        当执行完Git rebase main后，bugFix 分支上的工作会在 main 的最顶端，同时我们也得到了一个更线性的提交序列。注意，提交记录 C3 依然存在（树上那个半透明的节点），而 C3' 是我们 Rebase 到 main 分支上的 C3 的副本。

Git rebase main执行后

---

总结

这是我在学习过程中的一些学习记录，分享出来希望可以对你有帮助吧！