NetNinja-Git-入门笔记-全-

NetNinja Git 入门笔记（全）

001：简介与设置

概述

在本节课中，我们将要学习Git和GitHub的基本概念，了解为什么版本控制对开发者至关重要，并完成Git的安装与基础配置。我们将从一个开发者的真实故事开始，逐步理解Git如何解决代码管理中的常见痛点。

为什么需要Git？一个开发者的故事

大约15年前，我刚开始作为一名自由职业的网页开发者，为咖啡馆、窗户清洁工、音乐家等小客户制作网站。当时我认为自己是一个相当称职的开发者，但我从未听说过版本控制或Git。

我遇到了一位特别挑剔的客户。他要求一轮又一轮的修改，然后更多的修改，甚至还想回到我之前做的某个版本。每次我对项目进行更改或添加新功能时，我都会在电脑上保存整个项目的一个全新副本。我的文件夹结构看起来像这样：project_v1, project_v2, project_v3, project_v4, project_v5……直到我认为项目完成时，我可能会有类似 project_final 的文件夹。但客户总是想要“最后一个”小改动，于是就有了 project_final_2、project_final_final、project_actual_final，以及我个人最喜欢的 project_final_for_reals_on_wheels。

在某个时刻，我的硬盘上可能散落着大约20个相同项目的不同版本。最糟糕的是，我永远记不清哪个版本包含了哪些更改。我需要花费大量时间打开不同的文件夹，试图找出哪个文件夹里包含了修复好的导航栏或能正常工作的联系表单。这就像在和我自己的代码玩一场扭曲的捉迷藏游戏，一点也不有趣。

几个月后，我在一个学习网站上通过视频发现了Git这个工具。我当时在想：Git到底是什么？听起来像是我会用来骂人的词。但这个视频解释说，Git实际上是一种叫做“版本控制系统”的东西。简单来说，它就像是为你代码准备的“时光机”。

有了Git，我不再需要为不同版本创建20个不同的项目文件夹，我只需要保留一个项目文件夹，然后Git会跟踪你在该文件夹中做出的每一个更改。如果你想回到三周前导航栏的样子，你只需告诉Git显示那个旧版本。你再也不需要翻找那些名字荒谬的文件夹了。

Git不仅记住了什么改变了，还准确地记住了何时改变以及你为何改变它，因为每次你保存一个新版本（称为提交）时，你都会写一条简短的消息来解释你做了什么。所以，你不再需要试图回忆哪个文件夹有“能正常工作的联系表单”，你只需浏览你的提交历史，找到那条写着“修复联系表单验证”的提交。

最好的部分是，你的项目文件夹保持整洁，只包含文件的当前版本。所有的历史和先前版本都由Git安全地保管，但你可以在需要时随时访问它们。这确实像是代码的时光机。

但这仅仅是开始，因为Git的功能远不止于提交。使用Git，你还可以通过一种叫做分支的东西，在隔离的环境中开发项目的新功能。分支，顾名思义，是从你的主代码中分叉出去的。当你对某个功能满意时，你可以将该分支合并回主代码库。如果你完全搞砸了这个功能，这非常有用，因为你可以直接删除这个分支，而不会影响你的主代码。

什么是GitHub？

还有GitHub，它就像是编码项目的“在线多人游戏模式”。你可以与同事和朋友共享一个中央代码库，然后你们可以一起在项目上工作，添加新功能，而不会互相干扰。此外，你们还可以互相审查代码修改、标记项目中的任何问题，并分配任务或Bug给对方处理。这基本上将编码变成了一种社交活动，你可以邀请世界各地的任何人加入你的项目，让他们为之做出贡献。

但这不仅仅适用于个人项目。几乎每一家严肃的开发公司或公司内的部门都在使用Git和GitHub。如果你想在这些公司中担任网页开发人员，那么你可能需要熟练使用这些工具。这不再只是一项锦上添花的技能，而是一项基础技能，就像知道如何使用浏览器一样。很多时候，公司会默认你掌握这些技能。

我认为，在AI驱动的编码助手时代，这一点将比以往任何时候都更加重要。因为如果你自己不写一些代码，并且无法确定结果，那么如果你不使用Git或某种形式的版本控制，你将陷入无尽的痛苦之中。因此，学习Git和GitHub不仅仅是为了让你自己的编码生活更轻松（尽管它确实会），更是为了能够加入任何开发团队，并在第一天就能做出实际贡献。

课程路线图

如果你和我当初一样，可能会觉得这一切听起来相当复杂，捂住耳朵继续不用Git似乎要简单得多。我不会骗你，刚开始使用Git和GitHub时，某些部分可能会有点复杂。但我们将一步一步来，我向你保证，它并不像你想象的那么可怕。一旦你掌握了它，它就会成为你的第二天性，你将无法想象没有它该如何编码。

在本课程中，我们将从绝对基础开始，逐步建立你的信心。首先，我们将在你的电脑上正确安装和设置所有内容。然后，我们将通过简单的实际例子学习Git的核心概念。我们将掌握分支和合并，这是Git真正开始大放异彩的地方。之后，我们将深入GitHub，学习如何与其他开发者协作。最后，我们将了解一些新的AI工具，它们可以让你的Git工作流程更加顺畅。

在整个过程中，我们将在我创建的几个虚拟项目上工作，这些项目我已经上传到了GitHub，稍后我会告诉你如何访问和下载它们。另外，如果你还不习惯使用命令行，请不要担心，我们将涵盖所有你需要了解的基础知识。此外，我还会向你展示一些可视化工具，它们可以在你学习时让事情变得更简单。我们的目标是让你对Git和GitHub充满信心和能力，而不是让你感到不知所措。

我们将在下一课中开始安装Git，并确保你拥有所有跟上课程所需的工具。

安装与配置Git

现在，希望你已经相信Git将如何让你的编码生活变得更好。让我们实际在电脑上安装和设置它。

首先，我们将在你使用的任何操作系统（Windows、Mac或Linux）上安装Git。然后，我们将用你的个人信息配置Git，这样它就知道是谁在进行这些提交。最后，我们将测试一切以确保其正常工作。

让我们从安装Git本身开始。安装过程会根据你使用的是Windows、Mac还是Linux而略有不同。但无论如何，你要做的第一件事是访问 git-scm.com，这是Git的官方网站。在主页上，你会看到一个大的下载按钮，它会自动检测你的操作系统。

Windows 安装步骤

如果你使用的是Windows，它会显示Windows，你将获得Windows安装程序并下载它。这实际上是一个非常好的Windows软件包，它不仅包含Git，还包含一个叫做Git Bash的东西。Bash是一个Shell，它在Windows上为你提供类似Unix的命令行体验。现在不要被这些术语困扰，我们稍后会讨论终端和Shell。

下载Windows安装程序并运行它。打开后，它会启动安装程序，我们可以点击“下一步”进入下一个屏幕。对于大多数屏幕，我们只需接受默认选项即可。

第一个选项是“添加Windows Explorer集成”。这意味着我们可以通过在桌面或任何文件夹中右键单击并选择“Open Git Bash here”或“Open Git GUI here”来使用这些工具。我们稍后会了解更多，但现在请保持选中状态，然后点击“下一步”。

下一个屏幕我建议更改，因为默认选项通常是Vim，这对新的Git用户和新的Web开发者来说可能有点令人望而生畏。我建议将其更改为“Notepad++”（如果你有的话），或者直接选择下面的“Notepad”，或者选择“Visual Studio Code”（我用的就是这个）。然后点击“下一步”。

这里有两个关于新仓库初始分支的选项。我们还不了解分支甚至仓库是什么，所以我不想深入探讨。但几年前，我们通常会选择 master 作为主分支，即新仓库的初始分支。如今，大多数公司和开发者都使用 main。因此，我建议选择此选项并将默认分支命名为 main。点击“下一步”。

然后在这里，我们可以调整你的PATH环境变量。中间选中的选项是推荐的，它会向你的PATH变量添加一些Git包装器。这意味着你可以在命令提示符或Windows PowerShell等环境中使用Git。我们将使用专门的终端（Git Bash），但我建议选择此选项。然后你可以点击“下一步”。

我们将保持其余大部分为默认设置。只需参考我的选项，选择相同的，然后继续点击“下一步”。最后点击“安装”，这将在你的Windows上安装Git。

Mac 安装步骤

如果你使用的是Mac，你有几个选择。最简单的方法可能是使用Homebrew（Mac的包管理器）来安装Git。如果你已经安装了Homebrew，只需在终端中运行 brew install git。如果你没有安装Homebrew，可以访问 brew.sh 并按照安装说明操作。或者，你也可以像Windows一样从Git网站下载安装程序。有些Mac可能预装了Git，但可能不是最新版本，你可以通过这种方式更新它。

Linux 安装步骤

如果你使用的是Linux，你可能已经知道如何在你的系统上安装软件包了。根据你的发行版，你可以通过不同的方式安装它。关键是要确保你获得的是相对较新的版本。

验证安装

你可以通过打开终端并输入 git version 然后按回车来查看当前安装的版本。

如果你在Windows上，并且安装时已将Git添加到PATH变量中，你可以使用标准的Windows终端。但我建议在本课程中使用Git Bash，它是随Git自动安装的一个Shell。Bash允许我们运行Git命令以及可以在Mac上运行的相同Unix风格命令。

要使用Git Bash，你可以在桌面或文件夹中的任何位置右键单击，然后转到“显示更多选项”并点击它，然后选择“Open Git Bash here”。这将打开一个看起来像这样的终端（外观可能略有不同，我自定义过）。现在我们可以在这里运行Git命令，因为它运行的是Bash Shell。

在Mac上，你可以直接使用常规终端，它允许你在其中运行Git和Unix命令。

现在只需输入 git version（小写），按回车，你应该会看到安装在电脑上的版本信息。

关于终端和Shell的说明

既然我们谈到了终端、Shell和其他一些术语，我想花点时间解释一下这些东西是什么，因为我知道一开始可能会让人困惑。

  • 终端 只是我们用来输入命令的窗口。
  • Shell 是在终端内运行的程序，它实际读取并执行这些命令。

例如，在Windows 11上，终端叫做“Windows Terminal”，其内部运行的默认Shell是“PowerShell”。在Mac上，终端就叫“Terminal”，其内部运行的默认Shell现在是“Z shell”。刚才我打开Git Bash时，它使用的终端叫做“Mintty”，其内部的Shell是“bash”。Bash代表“Bourne Again Shell”。

我使用Bash而不是PowerShell的原因是，Bash允许我们开箱即用地运行Unix风格命令和Git命令，就像Mac上的Z Shell一样，但PowerShell不行，我们需要进行一些额外的设置才能使用所有相同的命令。所以，如果你使用带有PowerShell的Windows终端，本课程中的一些命令可能无法直接运行，这就是为什么我建议在本课程中使用Git Bash。

配置Git用户信息

一旦你安装了Git，接下来我们需要告诉Git你是谁。因为请记住，Git会跟踪谁进行了每次提交，所以它需要知道你的姓名和电子邮件地址。这非常重要，因为这些信息会被嵌入到你进行的每一次提交（或更改）中。如果你与其他人一起在项目上工作，当他们查看项目历史时，他们会看到这些信息，从而知道是谁进行了哪些更改。

让我们来设置一下。我们需要打开一个终端，然后输入一个Git命令。Git命令以 git 开头。顺便说一下，现在不要太担心我们正在写的命令，我们将在后面的教程中讨论如何使用命令行，我们也会看到很多不同的Git命令。所以现在不要太担心这个命令是如何写的，只需大致按照我的操作来设置这些不同的属性。

首先设置用户名：

git config --global user.name "你的名字"

例如，对我来说是：

git config --global user.name "Shaun P"

按回车，这将在我们的电脑上全局设置用户名。

接下来设置电子邮件地址：

git config --global user.email "你的邮箱地址"

例如：

git config --global user.email "shaun@example.com"

我们刚刚在这里运行了两个Git命令，它们都以 git 开头。你可能会对 --global 部分感到疑惑，这是一个标志，在这种情况下，它表示为我们电脑上创建的所有仓库全局设置这些配置。如果需要，你实际上可以基于每个项目覆盖这些设置，但对大多数人来说，全局设置就足够了。

设置完成后，你可以运行另一个命令来检查它们是否正确：

git config --global --list

按回车，这将显示你所有的全局Git设置，你应该能看到你刚刚添加的姓名和电子邮件地址。如果需要，你可以稍后通过使用新值再次运行相同的命令来更改它们。

设置Visual Studio Code

好了，朋友们。现在我们已经安装并配置好了Git。在这节课中，我们将设置Visual Studio Code作为我们的主要开发环境。

你不必非得使用VS Code，如果你更喜欢其他编辑器，可以使用任何你喜欢的。但VS Code为我们提供了Git仓库状态的直观展示，你可以看到哪些文件被更改了，更改了什么，你甚至可以不碰命令行就暂存和提交更改。我们将大量使用命令行，因为我认为学习它非常重要，但在此基础上拥有可视化布局会让一切更容易理解，尤其是对初学者而言。老实说，即使是有经验的人，当你想快速做一些更改或瞥一眼发生了什么变化时，它也非常方便。

要安装VS Code，只需访问 code.visualstudio.com 并点击下载按钮。它会自动检测你的操作系统，你可以下载相应的版本。

安装并打开VS Code后，你应该会看到这个欢迎标签页。从这里，你可以通过点击这里的“打开文件夹”链接来打开一个项目文件夹，或者通过转到“文件”->“打开文件夹”来做同样的事情。

我将打开 the8bitdev 文件夹，这是我们在本系列大部分内容中将要使用的虚拟项目。如果你想和我使用相同的项目，你可以从这个页面从GitHub下载它，我会在视频下方留下该页面的链接。这是你第一次接触GitHub，但我们唯一需要做的就是下载这个虚拟项目，这非常简单。

首先，确保你从这个下拉列表中选择“start-project”，这被称为一个分支，我们稍后会学习分支。现在只需选择“start-project-one”。其次，点击“Code”按钮，然后选择“Download ZIP”。这将在你的电脑上下载一个包含该项目的ZIP文件夹。下载后，你需要先解压该文件夹，然后就可以像我展示的那样，在VS Code中打开其中的项目。

一旦你打开了一个文件夹，我们就可以开始使用Git来跟踪项目中的更改了。我们将在下一章中做这件事，但现在，我只想向你展示几件事。

首先，VS Code带有一个集成终端，你可以通过点击顶部的“终端”->“新建终端”来打开它。选择该选项后，终端应该在底部打开，并且应该已经在你的项目目录中了。因此，稍后我们运行的任何Git命令都将从这个集成到VS Code的终端中运行。你也可以通过点击右上角的面板图标来切换这个终端面板，我认为其键盘快捷键是 Ctrl+J（在Mac上是 Cmd+J）。

其次，你应该能在左侧看到一堆图标。这个图标是VS Code内置的Git工具。如果你现在点击它，可能看不到太多内容，但稍后我们会看看这个并了解它能做什么。

最后，我们可以通过点击这里四个小方块的图标来打开扩展面板。从这里，我们可以安装任何我们想要的扩展。现在，我还不建议安装任何特定的Git扩展，但我想在本课程后面，我们会安装几个不同的东西，用一些额外的Git功能来增强VS Code。这些扩展很可能是“Git Graph”和“GitLens”。我们稍后会看到这两个。

不过，在我们用Git做任何工作之前，我想花几分钟时间让你熟悉命令行。没什么疯狂或复杂的，别担心，只是基础知识和足够让你入门的内容。

总结

在本节课中，我们一起学习了Git和GitHub的基本概念，了解了版本控制在现代开发中的核心价值。我们从一个开发者的亲身经历出发，看到了没有版本控制时管理代码的混乱与低效，并理解了Git如何通过跟踪更改、管理分支和提交历史来解决这些问题。我们还完成了Git在不同操作系统上的安装与基础配置，设置了用户信息，并准备好了Visual Studio Code作为我们的开发环境。现在，我们已经为深入学习Git的核心操作打下了坚实的基础。

002：命令行基础 🖥️

在本节课中，我们将学习命令行（终端）的基础知识。这是有效使用Git的关键技能，因为Git最初就是为命令行设计的。掌握命令行不仅能帮助你更好地使用Git，也是一项通用的、可迁移的重要技能。

为什么需要学习命令行？🤔

上一节我们介绍了课程概览，本节中我们来看看学习Git前的一个重要工具——命令行。许多新手甚至一些有经验的开发者对命令行感到紧张，这是可以理解的。它看起来可能有些令人生畏：一个黑色的屏幕，一个闪烁的光标，等待你输入指令。

然而，命令行实际上是你的朋友。一旦掌握了基础，剩下的部分就不会那么可怕了。为了有效地使用Git，熟悉命令行是绝对必要的。虽然也有图形界面工具（GUI）可以操作Git，但要真正精通它，我建议你熟悉你的终端。此外，命令行技能是通用的，无论你在另一台电脑上还是使用不同的工具，这项技能都很有用。

本课目标 🎯

本课的目标不是让你一夜之间成为命令行高手，而是希望为你提供开始使用Git命令时可能需要的基本导航和文件管理技能。我们将从基础开始，逐步建立你的信心。如果你已经熟悉命令行，可以自由地跳到下一课。对于其他人，让我们开始吧。

启动与基本概念

尽管我们之后会在VS Code中使用其内置终端来操作Git和命令行，但为了减少干扰，专注于我们运行的命令，本课我将直接使用Git Bash。在本课结束时，我也会在VS Code终端中运行几个命令，向你展示其工作原理。

要打开Git Bash，只需在桌面或任何文件夹中右键单击，选择“更多选项”，然后选择“Git Bash Here”。（Mac用户使用系统自带的终端即可。）

让我们从命令行最基本的概念开始：你在文件系统中的当前位置。当你打开一个终端时，你总是位于计算机上的某个位置，即某个文件夹内。终端中你当前所在的位置被称为当前工作目录。

你可以通过输入你的第一个命令来确认当前位置：

pwd

这个命令代表 print working directory（打印工作目录）。按下回车后，你会看到当前文件夹的完整路径被打印在终端中。

查看目录内容

现在我们知道自己在哪了，那么如何导航到计算机上的不同文件夹呢？我们首先需要知道当前工作目录中有哪些文件夹可以进入。

要找出答案，我们可以使用另一个命令：

ls

这个命令代表 list（列表），它会列出当前目录中的所有子文件夹和文件。文件夹名称后面会有一个斜杠 /。

使用命令标志（Flags）

当我们使用像 ls 这样的命令时，很多时候可以添加所谓的标志。标志有点像可以附加到命令上的选项，用来改变命令的行为方式。

标志以单个短横线 - 或双短横线 -- 开头。通常，单个短横线用于短选项（通常由单个字母表示），双短横线用于长选项（使用完整的单词）。

例如，对于 ls 命令，我们可以使用标志 --all（长选项格式），表示我们希望列出所有文件和文件夹，包括隐藏的文件。因为默认情况下，隐藏文件不会被列出。

ls --all

这个标志的短选项版本是 -a（单个字母），效果相同：

ls -a

长选项格式更易于人类阅读，但短选项输入更快，有时还可以让我们一次性组合多个选项。

另一个标志是 -l，它表示我们希望看到文件和文件夹的长列表，包含额外信息，如文件大小和最后修改时间。

ls -l

我可能想同时使用 a 和 l 两个标志。我可以这样做来组合它们：

ls -la

要查看像 ls 这样的命令可以使用的所有标志列表，我们可以输入命令，然后使用帮助标志 --help 或 -h。

ls --help

你会看到一些标志有仅使用单个字母的短版本，一些则有更长、更易读的版本。有时可能没有某个标志的长版本可用。

清理屏幕与导航

接下来我想展示的命令是 clear。输入它并回车，可以清空终端屏幕，给我们一个干净的工作区。我喜欢时不时这样做，以获得更多空白空间，感觉更清爽。

我们已经看到了如何列出当前工作目录中的内容，那么如何导航到不同的文件夹呢？

为此，我们可以使用 cd 命令，它代表 change directory（更改目录）。

假设我知道在我的当前工作目录中有一个名为 docs 的文件夹，我想导航进去。我可以输入：

cd docs

按下回车后，我就会进入那个文件夹。我可以再次输入 pwd 来证明这一点。

如果要导航的文件夹名称中包含空格，你需要用反斜杠 \ 转义空格，或者将整个文件夹名用双引号括起来。

例如，如果我想进入一个名为 PDF files 的文件夹：

cd "PDF files"

返回上级目录

那么如何返回到父文件夹呢？例如，我想从 PDF files 导航回 docs 文件夹。

我可以输入 cd，然后一个空格，接着是 ..。这两个点 .. 表示返回上一级目录。

cd ..

如果我再次运行相同的命令，我将继续向上返回。

使用相对路径

如果我想从当前位置直接一步进入 PDF files 文件夹，该怎么做呢？

我们再次以 cd 开头，然后可以输入到那个文件夹的完整相对路径。同样，如果路径中有空格，需要转义或用双引号括起来。

cd "docs/PDF files"

你也可以类似地向上穿越多个父目录。例如，我想向上返回两级父目录：

cd ../..

这将带我回到最初的位置。

创建与管理文件和文件夹

现在我们知道如何移动了，让我们学习如何从命令行实际创建和管理文件和文件夹。

我将首先在当前工作目录中创建一个新目录，可以使用 mkdir 命令，它代表 make directory（创建目录）。

mkdir test

按下回车后，将创建文件夹。我可以输入 ls 来查看新的 test 文件夹。

现在我们可以导航进入这个文件夹：

cd test

在这个文件夹里，我们可能想创建一个新文件，可以使用 touch 命令。

touch hello.txt

这将为我们创建一个文件。我可以再次输入 ls 来查看该文件。

在Windows上，我可以通过指定要使用的程序（如记事本）后跟文件名来打开这个文件：

notepad hello.txt

在Mac上，你会使用 open 命令后跟文件名。打开后，你可以编辑、保存文件，然后关闭它。

现在，我可以使用 rm 命令删除一个文件，它代表 remove（删除）。

rm hello.txt

这将删除该文件。如果我们输入 ls，就看不到那个文件了。

让我们使用 cd .. 退出这个文件夹。现在，假设我们想删除那个 test 文件夹。

我们可以使用 rmdir 命令（remove directory）后跟文件夹名。但这仅当文件夹为空时才会删除它。如果文件夹不为空，这个命令不会起作用。

rmdir test

实用小技巧：命令历史

这是命令行的一些非常基础的内容，足以让我们开始了。在本课程其余部分，当我们遇到新的命令时，我都会解释。

最后再分享一个非常实用的小技巧：你可以使用上下箭头键循环浏览之前运行过的命令。我在使用Git时经常这样做，因为我发现自己会快速连续多次运行某些命令。

在VS Code中使用终端

现在你知道了这些，让我们转到VS Code，我们将在其集成终端中做最后几个示例，可能与启动项目进行交互。

要切换VS Code中的终端面板，可以点击底部面板的这个图标。这样做会打开它，并将我们置于该项目文件夹根目录的新终端会话中。

对于Windows用户，默认情况下，当我们在VS Code中打开新终端时，它会使用PowerShell。但本课程中，我们希望使用Git Bash。

我们可以通过点击加号旁边的小箭头，选择启动一个运行Bash的新终端会话来做到这一点。完成后，你将自动进入该会话。你可以使用右侧的这些图标切换回其他终端会话。这个小竖线旁边的图标显示你当前所在的活跃终端。

如果你不想每次停止VS Code并切换终端面板时都手动这样做，可以将Bash设置为默认shell。

要这样做，使用快捷键 Ctrl+Shift+P 打开命令面板，然后开始输入“terminal profile”，你会看到“选择默认配置文件”这个选项。点击它，然后选择Git Bash作为默认配置文件。

现在，如果我们通过点击每个终端的垃圾桶图标来关闭所有打开的终端，终端面板会关闭。然后如果我们再次切换面板，它将自动使用Bash而不是PowerShell启动。

在这个终端内部，我们可以使用之前所有相同的命令。例如，我可以使用 pwd 打印当前工作目录（默认应该是我们在VS Code中打开的项目目录）。我们可以使用 ls 命令列出所有文件和文件夹，也能看到它们。我们还可以通过输入 touch 后跟文件名（例如 hello.html）来创建一个新文件。这样做之后，我们应该能在左侧的文件树中看到这个新文件。

最后，我将输入 clear 然后回车来清空我的终端。

总结 📝

本节课中我们一起学习了命令行（终端）的基础知识。我们了解了为什么命令行对使用Git至关重要，学习了如何查看当前目录（pwd）、列出内容（ls）、使用命令标志、在目录间导航（cd）、创建目录和文件（mkdir, touch）、以及删除它们（rm, rmdir）。我们还介绍了如何在VS Code中设置和使用集成终端。

希望现在你对终端感觉更自在一些。正如我所说，当你开始更多地使用它时（我们将在本课程中大量使用），它会很快变得像第二天性一样自然。

接下来，我们将真正开始使用Git。

003：创建新的Git仓库 🚀

在本节课中，我们将开始实际使用Git。我们将深入理解什么是Git仓库，并学习如何初始化我们的第一个仓库。

什么是Git仓库？

上一节我们了解了Git的基本概念，本节中我们来看看Git仓库。你可以将仓库视为一个围绕项目的容器，它跟踪项目内所有内容的完整历史记录和所有更改。这个仓库会记录一切：谁做了更改、何时更改以及为何更改。这基本上就像为你的项目准备了一本巨大的日记，但这是一本可以在需要时找回所有文件版本的日记。

例如，如果你上周修改了CSS文件并提交了该更改，那么Git将存储该版本的项目。这就像在那一刻为你的代码拍摄快照并保存该快照。然后，如果你几天后又更改了其他文件并也提交了这些更改，Git将安全地存储这两个版本或快照。如果你需要，可以随时回到之前的版本。

顺便提一下，你会经常听到我说“提交”这个词。这是一个Git术语，目前基本上意味着我们正在“保存”一个版本。我们稍后会详细讨论提交。这就像在视频游戏中拥有无限的存档点，如果你搞砸了某些事情，总是可以回到某个时间点。

你可能会想，如果Git仓库在计算机上存储项目的每个提交版本，它不会占用大量空间吗？答案是不会，因为Git存储版本的方式非常巧妙。它不存储整个项目的多个版本，而是只存储版本之间的差异，即文件中发生变化的部分。因此，如果我们需要回滚，Git只需要移除那些更改即可。

初始化Git仓库

如果我们想在项目中使用Git，需要为该项目创建一个新的仓库。为此，我们可以在项目的根目录中使用 git init 命令。请确保在运行此命令时位于正确的文件夹中。默认情况下，在VS Code终端中，你应该已经位于项目的根目录。但请记住，如果不是，可以使用我们之前见过的 cd 命令来更改目录。

以下是初始化仓库的命令：

git init

当我们运行此命令时，本质上是在告诉Git开始跟踪此项目中发生的一切。Git会通过在项目根目录内创建一个隐藏的 .git 文件夹来实现这一点。我们可以使用带有 -a 标志的 ls 命令来演示，以显示包括隐藏文件在内的所有文件，我们应该会看到那个 .git 文件夹。

以下是查看隐藏文件的命令：

ls -a

这个 .git 文件夹是Git存储所有历史记录、不同版本和项目元数据的地方。你永远不需要自己进入该文件夹，Git会处理所有这一切。但知道它的存在是好的，因为这正是将一个常规项目转变为Git仓库的原因。

顺便说一下，如果你删除了那个 .git 文件夹，你将丢失所有的版本历史记录，所以请尽量不要意外删除它。

理解工作目录与暂存区

你可能还会注意到，当我在此文件夹中初始化Git仓库后，其中的所有文件和文件夹都变成了绿色。这是VS Code的一个功能，它与Git集成得很好，会自动检测仓库中任何未跟踪的更改或新添加的文件，然后在文件树中高亮显示这些文件。在这种情况下，它们全部显示为绿色，因为Git尚未开始跟踪它们。

这是一个需要理解的重要概念：即使我们的仓库中有这些文件，Git一开始并不会自动跟踪它们。我们需要明确告诉Git我们希望它跟踪哪些文件，我们将在后面学习如何操作。

现在，让我们理解到目前为止我们所做的事情：我们通过运行 git init，将一个常规的项目文件夹转变成了一个Git仓库。从现在开始，你可能会听到我提到“repo”，这实际上是“repository”的简称，我会交替使用这两个词。

这个仓库现在有潜力跟踪我们对项目所做的每一次更改。我们在此仓库中创建的文件位于Git所谓的工作目录中。目前，这些文件是未跟踪的，这意味着Git知道它们存在，但并未过多关注它们。

因此：

  • 工作目录：是你编辑文件、编写代码和进行更改的地方。
  • 仓库本身（即隐藏的 .git 文件夹）：是Git存储所有项目历史和版本的地方。
  • 实际上，在这两者之间还有第三个区域，称为暂存区，我们将在下一课中讨论。

总结

本节课中我们一起学习了Git仓库的核心概念。我们了解到Git仓库是一个跟踪项目完整历史的容器，它通过存储版本间的差异而非完整副本来高效管理历史。我们实践了使用 git init 命令在项目根目录初始化一个新的Git仓库，这会在项目中创建一个隐藏的 .git 文件夹来存储所有元数据。我们还初步认识了工作目录（我们进行修改的地方）和暂存区（准备提交的中间区域）的概念，为下一课学习如何跟踪和提交文件打下了基础。

004：暂存文件 🗂️

在本节课中，我们将深入探讨 Git 如何组织和跟踪项目文件。理解 Git 的三个核心区域——工作目录、暂存区和仓库——是有效使用 Git 的关键。我们将通过一个示例项目来演示这些概念。

概述：Git 的三个区域

Git 通过将文件组织到三个不同的区域来跟踪项目变化。理解这三个区域对于有效使用 Git 至关重要。

这三个区域分别是：

  1. 工作目录：即你的项目文件夹，你在这里创建和编辑文件。
  2. 暂存区：在这里，你将希望包含在下一次提交中的更改排列起来。
  3. 仓库：这是 Git 存储的所有提交历史的集合。

通过使用 Git 命令，你可以决定何时将更改从工作目录移动到暂存区，以及何时将暂存的更改提交到仓库历史中。

工作流程详解

上一节我们介绍了 Git 的三个核心区域，本节中我们来看看它们是如何协同工作的。

整个流程可以概括为：编辑文件 -> 添加到暂存区 -> 提交更改。你会频繁地使用这个工作流程。

具体步骤如下：

  1. 你从在项目文件夹（工作目录）中编辑文件开始。
  2. 当你对更改满意时，使用 git add 命令将其添加到暂存区，这就像在决定购买前将商品放入购物车。
  3. 当你准备好使其永久化时，使用 git commit 命令提交更改。这将暂存区中的所有内容保存到仓库的历史记录中。沿用购物车的比喻，这就像是结账购买商品。

在我们的示例项目中，我们已经有一个包含文件的项目文件夹。当我们使用 git init 为该项目初始化一个 Git 仓库时，Git 就知晓了该工作目录中的所有内容。但目前，它并没有跟踪这些文件中的任何一个，因为我们还没有将它们添加到暂存区。

如果我们想将项目的当前版本存储到仓库历史中，首先必须将我们想要跟踪的文件添加到暂存区。对于第一次提交，通常你会希望添加所有或大部分文件，除非有特定文件你不想让 Git 跟踪。

一旦我们对暂存区中的文件感到满意，就可以进行一次“提交”，将这个版本的项目提交到仓库历史中。

实践：查看与添加文件

现在，让我们实际操作一下，看看项目中发生了什么。

首先，运行 git status 命令。运行后，你会看到列出了一系列“未跟踪的文件”。

在 Git 仓库中，“未跟踪的文件”基本上意味着你创建了但 Git 尚未开始跟踪的新文件，因此这些文件还没有对应的提交记录。

为了让它们成为被跟踪的文件，我们首先必须将它们添加到暂存区，并最终提交它们。

以下是添加文件到暂存区的步骤：

1. 添加单个文件
使用命令 git add，后跟你想要添加的文件名。例如：

git add index.html

运行后，再次执行 git status，你会看到 index.html 文件现在显示为绿色，并位于“要提交的更改”标题下。任何已暂存的文件都会显示在这里。

2. 添加多个文件
你可以一次添加多个文件。命令同样是 git add，然后列出不同的文件名。例如：

git add about.html contact.html

3. 添加所有文件
通常，在首次设置项目时，你会希望将所有文件添加到暂存区以进行初始提交。你可以使用一个点 . 来代表当前目录下的所有新文件或更改过的文件。

git add .

运行此命令后，所有文件都将进入暂存区。再次运行 git status 可以确认这一点。

暂存区的作用

此时，你可能会问：为什么需要暂存区？我们能不能直接用一个命令将版本提交到历史中，跳过暂存区？

这个问题的答案会随着课程的深入自然浮现。但本质上，暂存区让我们能够精确地控制，在某个特定版本中，我们想要提交哪些文件和更改。

例如，你可能修改了10个不同的文件，但也许你现在只想保存其中的3个，因为它们都与某个单一功能相关。暂存区允许你将相关的更改分组在一起。随着我们在后续课程中更多地实践这个工作流程，你会看到一些具体的例子。

目前，本节课希望你掌握的两个要点是：

  1. 工作目录中的所有新文件在开始时都是未跟踪的。
  2. 在我们希望 Git 跟踪文件并将其提交到仓库历史之前，必须先将文件添加到暂存区。

总结

本节课中，我们一起学习了 Git 跟踪文件的三个核心区域：工作目录、暂存区和仓库。我们理解了标准的工作流程是“编辑 -> 添加 -> 提交”，并通过 git add 命令实践了如何将文件从工作目录移动到暂存区。暂存区的作用是让我们能够精心挑选和组织要纳入下一次提交的更改，为创建清晰、有意义的项目历史打下基础。

现在我们已经将文件添加到了暂存区，在下一课中，让我们尝试进行一次提交。

005：首次提交 🚀

在本节课中，我们将学习Git的核心操作之一：提交（Commit）。提交是将暂存区中的更改永久保存到项目历史记录中的关键步骤。我们将了解提交的概念、如何创建提交，以及如何利用暂存区来组织相关的更改。

理解提交

上一节我们介绍了如何将文件添加到暂存区。本节中，我们来看看如何将这些暂存的更改提交到仓库历史中。

提交是使用Git的核心。每次提交都代表项目在特定时间点的一个快照。我们可以将提交理解为项目的“保存点”。

  • 初始提交代表项目的起点，即存储在历史中的第一个版本。
  • 之后，当我们添加新功能或进行修改后，可以暂存这些更改并创建另一个提交，保存项目在那一刻的状态。
  • 我们可以不断重复这个过程，创建多个提交。每个提交都代表项目的一个不同版本或快照。

在我们的项目中，我们已经将所有新文件添加到了暂存区。现在，我们需要创建一个提交将它们保存到历史中。

创建第一个提交

首先，我们使用 git status 命令确认所有文件都已暂存（显示为绿色）。接下来，我们使用 git commit 命令进行提交。这个命令会告诉Git将暂存区的所有内容保存到提交历史中，就像为项目当前状态拍一张快照。

在运行提交命令前，我们需要为提交添加一条消息。提交消息非常重要，它解释了这次快照或提交代表了什么，例如，项目做了哪些更改以及为什么更改。

以下是创建提交的命令格式：

git commit -m "提交消息"

其中，-m 标志代表“消息”（message），后面用双引号包裹具体的描述信息。

对于我们的第一个提交，可以使用类似“添加初始网站结构和页面”这样的描述性消息。运行命令后，我们就完成了在仓库中的第一次正式提交。

再次运行 git status，可以看到工作目录是干净的，没有未跟踪的文件，暂存区也是空的，因为所有更改都已提交到历史中。文件树中之前绿色的文件也恢复为默认颜色。

查看提交历史

提交完成后，我们可以使用 git log 命令查看项目的历史记录。目前，我们可以看到一次提交，其中包含几个信息：

  • 提交哈希值：一长串字母和数字，是提交的唯一标识符。
  • 作者：提交者。
  • 日期和时间：提交创建的时间。
  • 提交消息：我们添加的描述。

这个提交现在已存储在提交历史中，可以将其视为代表项目此刻状态的快照。

实践：创建更多提交

现在，让我们尝试进行一些更改并创建更多提交，以熟悉这个流程。

首先，我们在 assets 文件夹的 script.js 文件中添加一些代码，为联系页面的表单提交功能添加模态框。同时，我们也在 styles.css 文件中添加相应的样式，并修改 contact.html 文件以链接脚本并添加模态框的HTML结构。

完成这些更改后，我们在工作目录中修改了三个文件。此时，运行 git status 命令，会看到这三个文件以红色列在“Changes not staged for commit”标题下。

现在，我们需要遵循三步流程：

  1. 在工作目录中进行更改（已完成）。
  2. 将想要提交的更改添加到暂存区。
  3. 创建提交，将暂存的更改提交到历史。

我们使用 git add . 命令将所有更改的文件添加到暂存区（. 代表当前目录下的所有更改）。然后，再次运行 git status 确认更改已暂存（显示为绿色）。

接下来，我们创建第二次提交：

git commit -m “为联系表单添加模态框”

运行 git log 命令，现在可以看到历史记录中有两次提交：初始提交和最新的模态框提交。

暂存区的优势：拆分提交

现在，我们通过一个例子来展示使用暂存区将多个更改拆分为独立提交的好处。

假设我们同时做了两个不相关的修改：

  1. 在CSS文件中更新了导航栏的样式。
  2. 在主页（index.html）上更新了欢迎文本。

我们希望为导航栏的样式更改创建一个单独的提交，再为主页的内容更改创建另一个提交。由于两个更改是同时在工作目录中完成的，我们该如何操作？

这正是暂存区发挥作用的地方。因为只有添加到暂存区的更改才会在我们运行提交命令时被提交。

我们可以这样做：

  1. 首先，只将CSS文件的更改添加到暂存区：
    git add assets/styles.css
  2. 运行 git status，确认只有样式文件被暂存，主页的更改仍未暂存。
  3. 为这个更改创建提交：
    git commit -m “更新导航栏样式”
  4. 运行 git log，可以看到第三次提交。
  5. 现在，处理主页的更改。首先将其添加到暂存区（使用 git add . 或指定文件名）。
  6. 最后，为这个更改创建另一个提交：
    git commit -m “更新主页标题”

这样，我们就利用暂存区将两个不相关的更改分别提交，保持了提交历史的清晰和逻辑性。这是暂存区的主要优势之一，允许我们一次一个地创建提交，将相关的更改分组在一起。

提交的最佳实践

我们已经学习了如何初始化新仓库、将文件添加到暂存区以及创建提交。这是使用Git时最基础也是必须掌握的工作流程。

在结束之前，这里有一些关于创建提交的最终建议：

首先，注意提交的范围。 尽量保持每次提交的更改集中且精确，确保所有更改彼此相关。例如，如果你要修复三个不同的错误，并且修复这些错误的更改涉及不同的文件，那么最好将每个修复作为单独的提交，而不是将它们全部集中在一个提交中。

其次，确保提交信息的准确性。 与其写“修复错误”这样模糊的信息（我们很多人都犯过这个错误），不如尝试写一些更具描述性的内容，例如“修复联系表单上阻止提交的错误”。

关于提交信息还有很多可以探讨的内容，但目前我们暂时不深入，以免偏离当前更重要的学习重点。也许在课程后面我们会再回顾其中的一些内容。

总结

本节课中，我们一起学习了Git提交的核心操作。我们理解了提交是项目历史的快照，掌握了使用 git commit -m “消息” 命令创建提交的方法，并通过实践熟悉了从更改、暂存到提交的完整流程。我们还探讨了利用暂存区拆分不相关更改、创建清晰提交历史的优势，并了解了一些提交时的最佳实践。掌握这些是有效使用Git的基础，在接下来的课程中我们将获得更多练习。

006：删除与取消跟踪文件

在本节课中，我们将学习如何在Git中管理文件的删除、从暂存区移除更改，以及如何让Git停止跟踪特定文件。这些操作是日常版本控制工作流中的重要组成部分。

删除已跟踪的文件

上一节我们学习了如何添加和提交新文件。本节中我们来看看如何删除一个已被Git跟踪的文件。

删除文件的操作流程与添加或修改文件类似。首先，你需要在文件系统中手动删除文件（例如，右键点击并删除）。然后，这个删除操作需要被Git记录。

删除文件后，运行 git status 命令，你会看到该文件被列为“未暂存的更改”。这意味着你需要将这个删除操作添加到暂存区。

无论文件是被删除、新增还是修改，我们使用相同的命令来暂存更改。以下是具体步骤：

  1. 使用 git add <文件名> 或 git add . 来暂存删除操作。
  2. 使用 git commit -m “提交信息” 来提交这次删除。

提交后，你可以通过 git log 命令查看提交历史，确认删除操作已被记录。

从暂存区移除更改

有时，你可能不小心将更改添加到了暂存区。以下是将其移回工作目录的方法。

首先，你需要一个已暂存的更改。对任意文件进行修改并保存，然后运行 git add . 将其暂存。运行 git status 可以确认更改已处于暂存状态。

要从暂存区移除这个更改，使用 git restore --staged <文件名> 命令。这个命令会将指定文件的更改从暂存区移回工作目录，使其恢复为“未暂存”状态。

运行 git status 可以验证更改已不再位于暂存区。

丢弃工作目录中的更改

如果你对文件做了一些修改，但后来决定放弃这些修改，希望将文件恢复到最近一次提交时的状态，可以使用 git restore 命令。

这个操作会直接覆盖工作目录中未提交的更改，且无法撤销，请谨慎使用。

命令格式为 git restore <文件名>。执行后，该文件在工作目录中的所有未暂存更改都将被丢弃，文件内容会回退到上一次提交的版本。

运行 git status 可以确认工作目录现在是干净的，没有待处理的更改。

让Git停止跟踪文件

最后，我们学习如何让Git停止跟踪一个文件，同时保留该文件在你的项目文件夹中。这适用于你误提交了某些文件（如配置文件、日志文件），现在希望Git忽略它们，但又不希望从磁盘上删除的情况。

实现此功能的命令是 git rm --cached <文件名>。其中 --cached 参数是关键，它告诉Git：“从版本库的跟踪列表中移除这个文件，但把它保留在我的工作目录里。”

执行此命令后，该文件在你的编辑器中可能会显示为新的未跟踪文件（颜色可能变绿）。此后，Git将不再追踪此文件的任何变化。

请注意：

  • 如果后续你再次使用 git add 和 git commit 添加了这个文件，Git会重新开始跟踪它。
  • 如果不加 --cached 参数，git rm <文件名> 会同时从Git跟踪列表和你的工作目录中删除该文件，效果等同于手动删除文件后执行 git add。

本节课中我们一起学习了Git中关于文件删除与管理的几个核心操作：提交文件删除、从暂存区撤销更改、丢弃工作区的修改，以及让Git停止跟踪特定文件。掌握这些命令能帮助你更灵活地管理项目版本。下一节，我们将学习如何浏览项目的提交历史。

007：查看项目历史 📜

在本节课中，我们将学习如何查看和管理项目的提交历史。这对于回顾代码变更、追踪问题或回退到旧版本至关重要。

概述

上一节我们学习了如何提交更改。本节中，我们将深入了解如何查看项目的提交历史，包括查看详细变更、比较不同提交以及理解日志中的关键信息。

查看完整提交历史

要查看项目的完整提交历史，可以使用 git log 命令。该命令会按时间顺序列出所有提交，最新的提交显示在最上方。

git log

每个提交条目都包含以下信息：

  • 一个唯一的提交哈希值（ID）。
  • 提交的日期和时间。
  • 提交者的信息。
  • 提交时填写的提交信息。

查看简洁历史记录

如果你需要快速浏览历史记录，可以使用 --oneline 标志来获得一个简洁的视图。这个命令将每个提交压缩为一行显示。

git log --oneline

以下是简洁日志的特点：

  • 只显示每个提交哈希值的前几个字符。
  • 仅显示提交信息，不包含作者和日期。
  • 这种格式更紧凑，便于快速扫描。

查看特定提交的详细信息

当你在历史记录中找到感兴趣的提交时，可以使用 git show 命令查看该提交的详细信息。你需要提供该提交的哈希值。

git show <commit-hash>

运行此命令后，你将看到：

  • 提交的完整信息（作者、日期、提交信息）。
  • 该提交引入的差异（diff）。

差异（diff）显示了在该次提交中具体哪些行被添加或删除：

  • 以 + 开头的行表示被添加。
  • 以 - 开头的行表示被删除。
  • 在大多数终端主题中，新增行显示为绿色，删除行显示为红色。

注意：git show 的输出通常通过分页器（pager）显示。你可以按 Enter 键逐行查看，按 Space 键翻页，查看完毕后按 q 键退出。

查看包含统计信息的日志

另一种查看历史的方式是使用 git log 的 --stat 标志。这会显示每次提交的统计信息。

git log --stat

此命令提供以下额外信息：

  • 在每次提交中，哪些文件被更改。
  • 每个文件增加或删除了多少行代码。
  • 输出同样使用分页器，操作方式与 git show 相同。

比较两个提交之间的差异

git diff 命令可以直接比较任意两个提交之间的差异。你需要提供两个提交的哈希值。

git diff <commit-hash-1> <commit-hash-2>

运行此命令将显示两个指定提交之间的所有代码差异。输出会清晰地标出哪些内容被添加或删除，帮助你理解项目在两个时间点之间的变化。

理解 HEAD 指针

当你运行 git log 时，可能会在最新的提交旁看到 (HEAD -> main) 的标记。

  • HEAD 是一个指针，它代表你当前所在的位置。
  • 它通常指向你当前所处的分支（例如 main 分支）。
  • 而分支本身又指向该分支上的最新提交。

简单来说，HEAD -> main 表示：“你当前位于 main 分支上，并且正在查看该分支最新的提交”。随着你在该分支上不断进行新的提交，HEAD 指针会随之移动到最新的提交上。

总结

本节课中我们一起学习了如何有效地查看 Git 项目历史。我们掌握了使用 git log 浏览提交列表，用 git show 查看详细变更，用 git diff 比较不同版本，并理解了 HEAD 指针的基本概念。这些技能是进行版本控制、代码审查和问题排查的基础。下一节课，我们将学习如何利用历史记录，将项目回退到之前的某个提交状态。

008：撤销更改 🔄

在本节课中，我们将学习Git中两个用于撤销更改的核心命令：git revert 和 git reset。它们允许你“回退”项目的历史，但实现方式和影响截然不同。我们将通过实例演示它们的具体用法和适用场景。

概述

我们已经为项目创建了一些提交历史，并学会了如何查看这些历史。现在，我们将探讨如何撤销已做出的更改。git revert 通过创建一个新的提交来安全地撤销某个旧提交的更改；而 git reset 则直接将项目状态“重置”回历史上的某个特定提交点，就像时间旅行一样。理解两者的区别对于管理项目历史至关重要。

Git Revert：安全撤销提交

git revert 命令用于撤销一个已存在的提交。它的工作方式是：分析你想要撤销的那个提交所做的所有更改，然后创建一个全新的提交来反向应用这些更改（即删除原提交添加的内容，或添加原提交删除的内容）。这意味着它不会删除历史记录，而是通过增加一个新的提交来修正历史。

以下是使用 git revert 的基本步骤：

  1. 首先，使用 git log --oneline 查看提交历史，并找到你想要撤销的提交的哈希值（hash）。
  2. 执行命令 git revert <commit-hash>。
  3. Git会尝试自动创建反向更改。通常，它会打开一个编辑器让你为这个新的“撤销提交”编写提交信息。
  4. 保存并关闭编辑器后，Git会完成新提交的创建。

运行 git log --oneline 再次查看，你会发现历史记录顶端多了一个新的提交，其信息通常为“Revert ‘原提交信息’”。原来的提交依然保留在历史中。

核心概念公式：
git revert = 历史记录 + 新的反向提交

需要注意：如果你尝试撤销一个较旧的提交，而这个提交的更改被后续的提交所依赖或修改，就可能引发冲突（conflict）。例如，提交A将按钮改为蓝色，提交B又将同一个按钮改为绿色。此时撤销提交A，Git无法自动决定按钮最终应该是绿色（遵循B）还是移除蓝色规则（撤销A）。我们将在后续课程中详细学习如何解决冲突。

上一节我们介绍了通过增加新提交来安全撤销更改的 git revert。本节中我们来看看一个更“强力”的工具——git reset，它可以直接将项目状态回退到过去的某个时间点。

Git Reset：重置项目状态

git reset 命令用于将当前分支的指针移动到指定的提交，从而“重置”项目状态。根据使用的选项不同，它对工作目录和暂存区的影响也不同。主要有两种模式：--hard 和 默认模式（即 --mixed，通常省略）。

硬重置（Hard Reset）

使用 git reset --hard <commit-hash> 会执行一次彻底的“硬重置”。它将：

  1. 移动分支指针到目标提交。
  2. 重置暂存区（Staging Area），使其与目标提交一致。
  3. 重置工作目录（Working Directory），使其与目标提交一致。

这意味着：目标提交之后的所有提交都会从当前分支的历史中消失，并且你工作目录中所有未提交的更改（包括已暂存和未暂存的）都将被永久丢弃，完全回到目标提交时的项目状态。

操作非常危险，请务必确认你真的不需要那些更改后再执行。

如果不慎执行了硬重置，还有一个安全网：引用日志（Reflog）。使用 git reflog 命令可以查看HEAD和分支引用在本地仓库中的所有移动记录。你可以找到重置前的提交哈希，然后再次执行 git reset --hard <old-commit-hash> 跳转回去。但请注意，Git会定期清理旧的reflog记录，所以它并非永久保险。

混合重置（默认，Mixed Reset）

使用 git reset <commit-hash>（不带 --hard 标志）执行的是默认的“混合重置”。它的行为是：

  1. 移动分支指针到目标提交。
  2. 重置暂存区，使其与目标提交一致。
  3. 但不会改变工作目录。

这意味着：目标提交之后的所有提交也会从历史中消失，但这些提交所带来的代码更改并不会丢失。相反，它们会变成未暂存的修改（Unstaged Changes） 保留在你的工作目录中。

以下是使用混合重置后可能进行的操作：

  • 你可以重新审查这些更改，使用 git add 有选择地将部分修改加入暂存区。
  • 然后，你可以用新的提交信息重新提交它们，从而整理或重写项目历史。

核心概念代码对比：

# 硬重置：彻底回退，丢弃所有后续更改
git reset --hard a1b2c3d

# 混合重置：回退历史，但保留后续更改作为未暂存的修改
git reset a1b2c3d

总结

本节课中我们一起学习了Git中撤销更改的两种主要方法：

  • git revert：通过创建一个新的提交来安全地撤销指定提交的更改。这是公开历史（如推送到远程仓库后）中撤销更改的推荐方式，因为它保留了完整的历史记录。
  • git reset：将分支指针直接移动到历史中的某个提交点，用于本地历史的重写。根据是否使用 --hard 标志，它可以选择是彻底丢弃后续所有更改（--hard），还是将这些更改保留为未暂存的修改（默认）。

理解 revert 与 reset 的区别，以及 reset --hard 的风险，是掌握Git版本控制能力的关键一步。在下一节课中，我们将介绍一个特殊的文件——.gitignore，它可以帮助我们自动排除不需要版本控制的文件。

009：.gitignore文件 📝

在本节课中，我们将要学习一个非常重要的Git工具：.gitignore文件。我们将了解它的作用、如何创建它，以及如何使用它来告诉Git忽略项目中不需要跟踪的文件或文件夹。

概述

到目前为止，我们一直在提交更改并跟踪项目文件。但有时，我们不希望Git跟踪项目文件夹中的某些内容。这正是.gitignore文件发挥作用的地方。

什么是.gitignore文件？

想象一下，你正在一个项目上工作，并且使用了像VS Code这样的代码编辑器。VS Code会创建自己的.vscode文件夹来存储你的个人设置。这些文件实际上并不是你项目的一部分，它们只是VS Code自动生成的“杂物”。如果Git跟踪它们，你的提交记录中就会充满不相关的文件，这对项目中的其他协作者和你自己来说都很烦人。

对于像node_modules这样的文件夹也是如此。我们不希望Git跟踪此类文件夹，因为它们也只是“杂物”。

更糟糕的是，你可能会不小心提交敏感信息，例如.env文件中的API密钥、密码或数据库凭证。如果你将来使用GitHub等平台将此仓库发布到网上，就会暴露这些信息。

因此，有些情况下你并不希望Git跟踪某些内容。我们将把这些内容写在.gitignore文件中。.gitignore文件就是一个特殊的文件，Git可以读取它，并被告知要完全忽略哪些文件和文件夹。

创建并使用.gitignore文件

让我们首先在项目中添加一个名为notes.txt的新文件。假设这只是我为项目做的一些笔记，我并不真的希望Git跟踪这个文件，它仅供我个人使用。

目前，如果我们运行git status，你会看到Git检测到了这个文件，但尚未跟踪它。然而，如果我们在对项目进行更改后运行git add .命令，那将把所有更改和新文件（包括我们刚创建的notes.txt）添加到暂存区。

但正如我所说，我不希望Git跟踪那个文件。所以，让我们在项目的根目录下创建一个.gitignore文件，用它来告诉Git不要跟踪那个文件。请注意，文件名以点开头，不要忘记这一点。

现在，我再次运行git status，会看到两个新的未跟踪文件等待被暂存。然而，我将在.gitignore文件中添加notes.txt，就像这样，然后保存它。

完成之后，你会注意到该文件在文件树中不再高亮显示。而且，如果我们再次运行git status，可以看到它已完全从列表中移除，现在我们只看到刚刚创建的.gitignore文件。

接下来，我将运行git add .将所有更改添加到暂存区。完成后，我会再次运行git status以确保只添加了.gitignore文件，而没有添加notes.txt文件。

最后，我将通过运行git commit来为此更改创建一个提交。我们将使用-m标志来添加一条提交信息，例如“add .gitignore file”。

现在，我们将这个.gitignore文件提交到历史记录中，而该文件本身告诉Git完全忽略notes.txt文件。因此，现在对该文件所做的任何更改都不会被跟踪。

在.gitignore中添加更多规则

我们可以在.gitignore文件中添加许多不同的文件路径，也可以添加文件夹。

例如，假设我们想忽略整个.vscode文件夹（它有时由VS Code生成以存储某些设置）。这不需要提交到项目历史记录中，只是“杂物”。我们可以通过添加.vscode/来将该文件夹添加到.gitignore文件中。末尾的斜杠表示这是一个文件夹，其内部的所有内容都应被忽略。

你也可以添加.env到这个文件中（虽然我们实际上没有这个文件），但万一我们有，Git也不会跟踪它。

常见的你可能不想跟踪的文件还有.log文件，即任何以.log扩展名结尾的文件。我们可以通过添加*.log来告诉Git忽略它们。这里的星号*本质上是一个通配符，可以匹配任何文件名，只要它以.log扩展名结尾。所以，现在每个以.log结尾的文件都会被忽略。

你还可以添加像node_modules这样的包文件夹，以及其他内容。

现在我们已经添加了一些规则，让我们在项目历史中做一个提交。首先，我们通过运行git add .来暂存文件（我通常使用点号，因为它写起来更快）。接下来，我们通过运行git commit -m命令来创建一个提交，提交信息可以是“updated .gitignore file”。

现在，我们为这个项目设置了一个.gitignore文件。随着项目的扩展，我们可能只需要向这个文件添加更多内容。

使用现成的.gitignore模板

实际上，你可以在网上的个人编程网站以及GitHub本身上找到针对各种不同类型项目的.gitignore模板。

例如，GitHub本身就创建了大量的不同模板。你可以向下滚动，看到他们在这里创建了一个Flutter模板。点击它，你会看到该文件包含了你在进行提交时可能不想添加到项目历史记录中的所有内容。你基本上可以直接复制这个.gitignore文件并粘贴到你自己的项目中。

此外，当你使用某种CI工具通过像Flutter、Vue或Next这样的框架来搭建新项目时，很多时候它会自动为你生成一个预填充的.gitignore文件。虽然不总是如此，但有时确实如此。然后你就可以根据需要随时添加内容。

总结

本节课中，我们一起学习了.gitignore文件。我们了解了它的核心作用是告诉Git忽略项目中特定的文件或文件夹，从而避免将无关的“杂物”或敏感信息提交到版本历史中。我们学习了如何创建该文件，并通过添加如notes.txt、.vscode/、*.log等规则来配置它。最后，我们还了解到可以利用GitHub等平台提供的现成模板来快速为特定类型的项目配置.gitignore文件。

在下一课中，我们将看看VS Code内部一些内置的Git功能，这些功能可以让我们的Git工作流程更加顺畅。

010：VS Code中的Git功能

在本节课中，我们将学习如何在VS Code中使用其内置的Git功能。之前我们一直在终端中使用git add、git commit等命令进行Git操作，这对于理解Git的工作原理非常有帮助。然而，VS Code提供了一系列直观的Git工具，可以让我们的工作流程更加顺畅。由于我们大部分时间都会在VS Code中工作，了解这些工具的使用方法很有意义。

文件树高亮显示

上一节我们介绍了终端中的Git命令，本节中我们来看看VS Code如何通过视觉提示来展示文件状态。首先，我们来快速了解一下文件树中的高亮显示，它能告诉我们哪些文件发生了更改。

当工作目录中没有未提交的更改时，所有文件和文件夹都显示为标准白色。一旦我们对文件进行修改，例如在index.html文件中更改一个字母并保存，该文件名在文件资源管理器中的颜色就会改变。

以下是不同颜色代表的含义：

  • 蓝色（或橙色/黄色，取决于主题）：表示已修改的现有文件（未暂存的更改）。
  • 绿色：表示项目中新增的、尚未被Git跟踪的文件。
  • 淡橙色：表示文件已修改并已添加到暂存区。

如果你在终端运行git add .命令将所有更改暂存，已修改的文件会变为淡橙色，而新文件仍保持绿色。运行git commit -m "提交信息"提交后，所有颜色将恢复为正常的白色。这是一种无需频繁运行git status命令即可了解项目状态的便捷视觉指示器。

源代码管理面板

了解了文件树的高亮后，接下来我们深入看看源代码管理面板。点击侧边栏中类似地铁线路图（带有三个圆圈）的图标即可打开此面板。

在这个面板中，顶部列出了仓库名称和当前分支（例如main）。下方是“更改”部分，列出了工作目录中所有未暂存的更改，其作用类似于运行git status命令。

以下是面板中的主要操作：

  • 将鼠标悬停在某个文件上，点击出现的 + 图标，可以将该单个文件添加到暂存区（相当于 git add <文件名>）。
  • 面板顶部有一个 + 图标，点击它可以添加所有更改到暂存区（相当于 git add .）。
  • 文件被暂存后，会移动到“暂存的更改”标题下。点击文件旁的 - 图标可以将其从暂存区移除。
  • 在顶部的文本输入框中输入提交信息，然后点击“提交”按钮，即可完成提交（相当于 git commit -m "提交信息"）。

面板底部还有一个“图”部分，按顺序列出了所有的提交记录。将鼠标悬停在某个提交上，可以查看其提交哈希值、作者和提交信息等详细信息。

这个源代码管理面板非常实用，我有时会用它来查看更改和进行提交。不过在本课程中，90%的时间我们仍将使用命令行，因为对于初学者而言，使用命令行练习能帮助你更好地理解Git的底层机制。当然，在后续章节中，我们也会偶尔使用这个面板。

文件内更改对比

最后，让我们看看VS Code中我最喜欢的一个功能：如何在文件内部精确显示更改。

当你打开一个文件并开始修改时，会注意到编辑器左侧的装订线（gutter）会出现彩色高亮条。这些条状标记精确地指出了哪些行被更改了。

以下是不同颜色的含义：

  • 蓝色线条：表示该行代码已被编辑。
  • 绿色线条：表示该行是新增的代码。
  • 红色三角形：表示该行代码已被完全删除。

点击任何这些标记，都会在一个弹出框中显示具体被更改、添加或删除的内容。这在提交前审查自己的更改时非常有用，因为你可以快速浏览文件并查看所有修改。另一个贴心的设计是，右侧的滚动条上也会显示这些彩色线条，让你一眼就能看出文件中所有更改的位置。

请注意，这些高亮显示仅在你处理未提交的更改时出现，一旦提交，它们就会消失。

总结

本节课中我们一起学习了VS Code为Git工作流提供的几个实用视觉工具。我们了解了文件树中的颜色高亮如何指示文件状态，探索了源代码管理面板如何让我们可视化地暂存文件和提交更改，最后还学习了如何在文件内部精确查看每一行的修改内容。

这些工具可以根据你的喜好选择使用。我个人习惯使用Git面板进行简单的提交操作，而对于更复杂的任务则回到命令行。文件内更改对比的高亮功能也让我非常受用。

接下来，我们将讨论Git最强大的功能之一：分支。

011：理解分支 🌿

在本节课中，我们将要学习Git中一个极其重要的概念——分支。到目前为止，我们的操作都像是在一条直线上进行。但实际开发中，项目往往需要同时进行多种尝试或开发多个功能。分支就是帮助我们实现这一点的强大工具。

什么是分支？

上一节我们介绍了提交历史，本节中我们来看看如何让历史“分叉”。

分支，顾名思义，就是允许你的代码历史从一个点开始，向不同方向发展的机制。你可以把它想象成游戏中的存档点或平行宇宙。

在Git中，分支本质上是一个指向一系列提交历史的可移动标签。

为什么需要分支？

以下是使用分支的几个核心原因：

  1. 安全开发新功能：你可以在一个独立的分支上开发新功能，而不会影响主线上稳定运行的代码。
  2. 尝试与实验：如果某个新想法效果不佳，你可以直接丢弃整个分支，轻松回到起点。
  3. 保持主线整洁：只有经过测试、确认可用的功能才会被合并回主线，这使得主分支的历史清晰、稳定。
  4. 团队协作：团队成员可以同时在各自的分支上工作，互不干扰，最后再将完成的工作合并。

分支的工作流程

想象一下，你正在主分支（main）上开发一个网站。现在你需要添加一个“邮件注册”功能。

不推荐的做法是直接在 main 分支上修改代码。如果你中途发现代码有问题，开始回退、修补，很容易把提交历史弄得一团糟。

推荐的做法遵循以下步骤：

  1. 创建新分支：从 main 分支的当前状态创建一个新的分支，例如 feature-email-signup。
    git branch feature-email-signup
  2. 切换到新分支：在这个新分支上进行所有关于该功能的开发工作。
    git checkout feature-email-signup
  3. 自由开发与提交：在新分支上修改文件、进行提交。所有这些更改都只存在于 feature-email-signup 分支上，main 分支完全不受影响。
  4. 完成与合并：当功能开发完毕并测试通过后，将该分支合并回 main 分支。
    git checkout main
git merge feature-email-signup
  5. （可选）删除分支：功能合并后，可以安全地删除这个特性分支。
    git branch -d feature-email-signup

查看当前分支

在开始操作前，了解你当前位于哪个分支非常重要。

  • 使用 git status 命令，输出信息的第一行会显示当前所在分支。
    $ git status
On branch main
Your branch is up to date with 'origin/main'.
...
  • 使用 git branch 命令，可以列出仓库中的所有分支。当前所在分支前会有一个星号（*）标记。
    $ git branch
* main
  feature-email-signup

总结

本节课中我们一起学习了Git分支的核心概念。我们了解到分支是一个指向提交历史的标签，它允许我们从开发主线分离出去，在独立的环境中进行安全的开发、测试和实验。通过创建新分支来开发功能，最后再合并回主分支（main）的工作流，是保持项目代码整洁、稳定和便于团队协作的标准实践。在下一课，我们将动手创建并操作我们的第一个分支。

012：切换分支 🪢

在本节课中，我们将学习如何创建新的Git分支，以及如何在不同的分支之间进行切换。这是实现并行开发和功能隔离的核心操作。

概述

上一节我们介绍了分支的概念及其重要性。本节中，我们来看看如何实际操作分支：创建新分支、在不同分支间切换，并理解分支如何形成独立的历史线。

查看当前分支

在开始创建新分支前，我们需要知道当前处于哪个分支。可以使用以下两个命令之一：

  • git status
  • git branch

我们使用 git branch 命令。该命令会列出仓库中的所有分支，并在当前所在分支旁用星号（*）标记，通常还会高亮显示。

git branch

运行后，你会看到类似输出，表示当前只有一个名为 main（或 master）的默认分支。

创建新分支

要创建一个新分支，我们再次使用 git branch 命令，但这次需要跟上你想要创建的分支名称。

以下是创建分支的命令格式：

git branch <新分支名称>

例如，创建一个名为 my-new-branch 的分支：

git branch my-new-branch

执行此命令后，新分支即被创建。此时再次运行 git branch，你会看到列表中多了一个 my-new-branch，但星号仍然在 main 分支旁，表示你尚未切换到新分支。

切换到指定分支

创建分支后，通常需要立即切换到该分支开始工作。使用 git switch 命令可以切换到指定分支。

以下是切换分支的命令格式：

git switch <分支名称>

例如，切换到我们刚创建的 my-new-branch：

git switch my-new-branch

现在运行 git branch，你会发现星号已经移动到了 my-new-branch 旁边。

重要概念：新分支在创建时，是源分支（此处是 main）在那一刻的完整副本，包含了截至分支点所有的提交历史。因此，在做出新提交之前，两个分支的代码和提交历史是完全相同的。

创建并立即切换分支

由于我们经常在创建分支后立即切换过去，Git 提供了一个更快捷的命令，可以一步完成创建和切换操作。

使用 git switch 命令并加上 -c（代表 create）标志，即可创建新分支并立即切换到它。

以下是创建并切换分支的命令格式：

git switch -c <新分支名称>

例如，创建一个更合理的功能分支 feature-newsletter：

git switch -c feature-newsletter

执行后，系统会创建该分支并自动切换过去。运行 git branch 可以确认当前已位于新分支上。

关于 git checkout：你可能会看到有人使用 git checkout <分支名> 来切换分支。这个命令仍然有效，但 checkout 功能较多，不仅用于切换分支。从 Git 2.23 版本开始引入了更直观的 switch 命令专门用于分支切换。本教程将使用 switch 命令。

在不同分支上独立工作

现在我们有三个分支：main、my-new-branch 和 feature-newsletter。后两个目前是 main 的副本。

分支的强大之处在于隔离性。当你在某个分支（例如 feature-newsletter）上修改代码并提交时，这些更改只会记录在该分支的历史中，完全不会影响 main 或其他分支。

让我们在 feature-newsletter 分支上模拟一些工作：

  1. 确认当前分支：git branch
  2. 修改项目文件（例如，添加一个新闻通讯表单的HTML、CSS，并在主页添加链接）。
  3. 将这些更改分次提交：
    # 第一次提交：添加HTML表单
git add .
git commit -m "add newsletter html form"

# 第二次提交：添加CSS样式
git add .
git commit -m "add styles for newsletter"

# 第三次提交：在主页添加链接
git add .
git commit -m "add link to newsletter"

现在，使用 git log --oneline 查看提交历史，你会发现最新的三次提交只出现在 feature-newsletter 分支的历史记录中。同时，HEAD 指针（代表你当前的位置）指向 feature-newsletter。

验证分支间的独立性

要验证分支间的独立性，我们可以切换回 main 分支查看。

  1. 切换回主分支：
    git switch main
  2. 查看 main 分支的提交历史：
    git log --oneline
    你会发现，刚才在 feature-newsletter 上做的三次提交消失了。HEAD 指针现在指向一个更早的提交，main 分支的历史线里没有那些新功能提交。
  3. 检查工作目录：你在 feature-newsletter 上修改的代码文件，在 main 分支的视图下会恢复成修改前的状态。新添加的新闻通讯部分将不可见。
  4. 切换回功能分支以查看更改：
    git switch feature-newsletter
    一切又都回来了。

直观演示：如果你在 feature-newsletter 分支运行时在浏览器中预览项目，可以看到新闻通讯功能。但如果在 main 分支预览，则看不到该功能，因为它尚未被合并到主分支中。

理解分支工作流的意义

到目前为止，我们创建了分叉的历史。想象一棵树，树干是共享的提交历史（main 分支），在某个点分出一个树枝（feature-newsletter），这个树枝独立生长，拥有了自己额外的提交。

这种工作流非常有用，原因如下：

以下是使用分支的主要优势：

  • 安全实验：你可以在新分支上自由尝试新功能，即使彻底搞砸了，只需删除该分支即可，主分支代码安然无恙。
  • 并行开发：团队成员可以同时在不同的分支上开发不同的功能，互不干扰。这在后续使用 GitHub 协作时尤为重要。
  • 历史清晰：保持主分支提交历史的整洁和有序，每个功能或修复都有自己独立的历史线。
  • 便于测试与审查：可以在独立的分支上完整地开发、测试一个功能。只有当功能完善并通过测试后，才决定是否将其整合到主代码库中。

总结

本节课中我们一起学习了 Git 分支的核心操作。我们掌握了如何使用 git branch 查看和创建分支，以及如何使用 git switch（和 git switch -c）在不同分支间切换。我们实践了在独立分支上开发功能并提交更改，验证了分支间的隔离性。最后，我们探讨了基于分支进行开发的工作流程为何如此强大，它能保障代码安全、支持并行协作并保持项目历史清晰。

当我们决定将一个分支上完成的功能整合回主分支时，这个过程被称为合并，这将是下一节课的主题。

013：合并分支 🔀

在本节课中，我们将要学习Git中一个核心操作：合并分支。我们将了解如何将一个分支上的工作成果整合到另一个分支（通常是主分支）上，并重点介绍最简单、最常见的合并类型——快进合并。

上一节我们学习了如何创建和切换分支，并在独立的分支上开展工作。本节中我们来看看，当对一个功能分支上的工作感到满意，并希望将其作为核心项目的一部分时，如何将这些更改带回主分支。因为主分支通常代表你准备部署的主要代码库，所以合并操作至关重要。

合并本质上是Git将来自一个分支的更改整合到另一个分支的方式。例如，我们一直在 feature-newsletter 分支上工作并提交了一些更改。当我们认为该功能已经完成并经过测试，希望将其纳入主代码库时，就需要将这个功能分支合并回主分支。合并操作会将该功能分支上的所有提交都集成到主分支上，使我们在功能分支上添加和更新的代码同样出现在主分支中。

Git中有不同类型的合并，我们将在课程后续部分介绍。在本例中，我们将关注最简单也最常见的一种：快进合并。当目标分支（通常是主分支）自你创建功能分支以来，没有进行过任何新的提交时，就会发生快进合并。这在个人开发中非常常见，因为在你开发功能时，没有其他开发者对主分支进行修改。本质上，这种场景下，主分支只是“快进”到功能分支当前所在的位置。

以下是执行合并的基本步骤：

  1. 确保你位于目标分支：在合并前，你需要切换到接收更改的分支，通常是 main 分支。
  2. 执行合并命令：使用 git merge <branch-name> 命令，将指定的分支合并到当前分支。

让我们通过一个具体的例子来演示这个过程。

首先，我们查看功能分支的提交历史，确认它领先于主分支。然后，我们切换回主分支，并查看其提交历史，会发现它缺少功能分支上的最新提交。接着，我们在主分支上运行合并命令 git merge feature-newsletter。由于主分支自功能分支创建后没有新提交，Git执行了一次快进合并，直接将主分支的指针移动到功能分支最新的提交上。

合并完成后，再次查看主分支的日志，会发现它现在包含了功能分支的所有提交。此时，两个分支指向了同一个最新的提交。我们可以通过预览项目来验证新功能（例如新闻通讯表单）是否已成功整合到主分支中。

最后，虽然功能分支的内容已被合并，但分支本身仍然存在。良好的Git工作流习惯是，在合并完成后，删除那些不再需要的功能分支以保持仓库的整洁。我们将在下一课中学习如何删除分支。

本节课中我们一起学习了Git合并分支的基础知识，特别是快进合并的操作流程。我们了解到，合并是将不同分支的开发线重新组合的关键步骤，而快进合并则是在目标分支没有并行开发时最高效的合并方式。记住，合并后，原功能分支仍然存在，通常建议在合并后将其删除。

014：删除分支 🗑️

在本节课中，我们将学习如何清理不再需要的Git分支。保持仓库的整洁有序是良好的开发习惯，尤其是在团队协作中。我们将学习安全删除分支的两种方法。

上一节我们完成了分支的合并，现在我们的main分支已经集成了新闻通讯功能。但查看分支列表时，会发现feature-newsletter分支和之前创建的测试分支my-new-branch仍然存在。

一般来说，完成分支的工作后，及时清理它们是一个好习惯。这样可以避免仓库中堆积大量陈旧分支，造成混乱，让你难以分辨哪些是活跃的工作分支。当团队中有多名开发者各自在分支上工作时，这一点尤为重要。

删除已合并的分支

首先，我们来看看如何删除已经合并到主分支的feature-newsletter分支。

重要提示：在删除一个分支之前，必须确保你当前没有处在该分支上。如果你正在要删除的分支上，需要先使用git switch命令切换回main分支。

以下是删除分支的步骤：

  1. 确保你位于main分支。
  2. 运行删除命令：git branch -d <分支名>。其中-d标志代表删除（delete）。

现在，让我们删除feature-newsletter分支。运行命令：

git branch -d feature-newsletter

命令执行后，该分支即被删除。你可以通过再次运行git branch命令来验证，列表中应该已经看不到feature-newsletter分支了。

删除未合并的分支

接下来，我们处理另一个分支my-new-branch。在删除它之前，我们先切换到该分支，并模拟一种常见情况：你在一个分支上做了一些提交，但后来决定放弃这些更改，不将其合并回主分支，而是直接删除整个分支。

首先，切换到my-new-branch分支：

git switch my-new-branch

现在，我们在这个分支上做一些修改并提交，例如更新主页标题。完成提交后，假设我们觉得这个功能很糟糕，想要删除整个分支。

再次强调，删除分支的第一步是离开该分支。切换回main分支：

git switch main

然后，尝试用同样的命令删除my-new-branch分支：

git branch -d my-new-branch

此时，Git会阻止操作并提示“该分支尚未合并”。这是Git的保护机制，防止你意外删除包含未合并提交的分支，从而丢失工作。

如果你确认要强制删除这个未合并的分支，需要将删除命令中的小写-d改为大写-D：

git branch -D my-new-branch

这个命令的意思是：“我知道这个分支上有未合并的工作，但我仍然要删除它。”执行此命令后，分支将被强制删除。再次运行git branch，可以看到只剩下main分支了。

总结

本节课中，我们一起学习了如何删除Git分支。我们掌握了两种方法：

  • 使用 git branch -d <分支名> 删除已合并的分支。
  • 使用 git branch -D <分支名> 强制删除未合并的分支。

养成完成后及时清理分支的习惯，可以有效保持仓库的清晰和项目的可维护性，避免它变成一个堆满陈旧工作和分支的“墓地”。

posted @ 2026-03-29 09:23  绝不原创的飞龙  阅读(1)  评论(0)    收藏  举报