Git 基础知识

什么是 git？

毫无疑问，Git 是当今使用最广泛的版本控制系统。它由 Linus Torvalds 于 2005 年为 Linux 内核的开发而开发。

版本控制系统实际上意味着它简化了我们开发人员的跟踪、查看文件的更改以及在出现问题时返回的时间。

需要知道的重要一点是，Git 并不是专为开发人员打造的令人生畏的工具。本质上，您可以在一些简单的活动中使用它，例如写博客来跟踪和观察您的更改。为了进一步扩展我们对 Git 的理解，让我们以一个作家团队为例。现在想象一下多个作家想要合作完成一个特定项目的情况。

他们需要一种方法来跟踪变化，以确定每个部分的作者是谁，并将他们各自的故事整合到主要故事中。所有这些都可以从根本上简化整个项目的进度。在我们想象中的作家完成一些工作后，我们可以观察他们的工作流程。

您可以看到绿色项目符号，它代表 Git 在您首次设置存储库时创建的默认分支（通常名为 master 或 main）。然后，编写者从主分支创建分支并合并他们的更改，这些更改最终会合并回主分支。我将提供有关如何执行此操作的更多说明以及所使用的命令。

Git 的状态

Git 命令的主要功能之一是操作数据。使用 Git 时，我们的数据可以存储在三个区域中。

修改的

分阶段

坚定的

“已修改”表示您已对文件进行了更改，但尚未提交。

“暂存”意味着您已将当前版本中的修改文件标记为将包含在下一次提交中。

“已提交”意味着更改已安全地本地存储在您的机器上。

所有这些状态都发生在本地存储库中。当我们推送已提交的更改时，它们将被传输到远程存储库。顾名思义，本地目录位于我们的本地计算机上，而远程存储库位于云端（GitHub、Bitbucket 等）。

基本 Git 命令

要初始化存储库，我们使用 git init。此命令会创建一个文件夹。如果您在文件夹路径中没有立即看到它，它可能在 Windows 中被隐藏了。您可以通过选择显示隐藏文件的选项来显示它，然后您将能够看到 .git 文件夹。

初始化后，要从“已修改”移至“已暂存”，我们使用 git add 命令。要从“已暂存”过渡至“已提交”，我们使用 git commit 命令。

当我们到达“提交”阶段时，我们可以继续使用 git push 命令将已提交的更改推送到远程存储库。

如果我们想从远程存储库检索数据，我们将使用 git pull 命令。

因此，让我们在推动新更改时一次性浏览所有命令：

1. git init
2. git add . // add your changes
3. git commit -m “commit message” // commit changes with message
4. git push origin  // push to remote repo

创建远程存储库

目前，流行的基于 Web 的版本控制平台之一是 GitHub。让我们通过在 GitHub 上创建您的第一个存储库并提交您的更改来深入了解它。

点击“新建”按钮后，你会看到以下选项

在这里，您可以先为您的存储库选择一个**描述性名称**。在描述字段中，您可以提供有关存储库中使用的技术的信息。如果它是一个公共存储库，在描述中包含相关关键字可以让其他人更容易发现它。

下一个选项允许您选择您的存储库是**公共**还是私有**。如果是私有的，则只有您和您的团队或组织可以访问源代码。如果是公共的，则任何人都可以查看、克隆或分叉存储库。

之后，有一个选项用于初始化 **readme 文件**。您可以选择在此阶段添加它或忽略它；这不会产生太大影响。

最后，有一个选择**许可证**的选项。这会告知其他人他们可以对您的代码做什么。常见的许可证包括 MIT 许可证，该许可证允许使用、复制、修改、合并、发布、分发、再授权和销售您的软件副本。如果您愿意，可以选择跳过此部分。

现在，选择所有所需的选项后，我们可以继续创建存储库，我们将看到以下内容。

这是下一页。现在，我们可以使用 Git 命令推送到远程存储库。GitHub 还提供了有关如何推送第一个提交的建议。

您可以使用任何终端来运行 Git 命令。如果您使用的是 Windows，则可以是 Git Bash、CMD，或者您可以在 Visual Studio Code 终端中运行命令。选择您习惯使用的终端来运行 Git 命令。

首先，在 Windows 中导航到您的存储库路径。您可以按住 Shift 并右键单击文件或文件夹来执行此操作。然后，选择“复制为路径”。或者，您可以在当前文件夹中按 ALT + D 并复制所选文本。

然后运行：

git init

git add .

git commit -m “initial commit”

git remote add origin “your repo” //Copy SSH

最后一件事是推动

git push “origin master”

就这样，您现在已将代码保存在远程存储库中。

Git 变基

Git rebase 是 Git 中的一个命令，它允许您通过合并来自另一个分支的更改来重写分支的提交历史记录。

换句话说，rebase 意味着将分支的起点移至另一个提交。这就像假装您从那个新点开始工作一样。

git rebase

大部分时间将是：

git rebase master

执行此命令后，您可以直观地看到

git rebase 使用示例

主要问题是人们为什么使用 Git rebase？

答案很简单，就是维持线性的项目历史。

哪一个是讨论 rebase 危险的良好起点

rebase 的危险

假设一个项目有两个分支：“feature”和“master”。“feature”分支是从主分支创建的，并且依赖于一个从“master”分支中取出的包。当您尝试将“feature”分支与最新的“master”同步时，您所做的初始修改将产生问题，导致项目构建时出错。

在对一长串提交进行变基的过程中处理冲突可能令人困惑且具有挑战性。它带来了复杂性，使得确保正确解决所有问题变得更加困难，并且成为过程中另一个潜在的错误来源。

摘自 Fredrik V. Mørken 的博客

对这个问题有一个很好的观察：

“我得出的结论是，这纯粹是为了虚荣。重新定基是一种纯粹的美学操作。表面上干净的历史记录对我们这些开发人员很有吸引力，但从技术或功能的角度来看，这是不合理的。”

Git 合并

Git 合并是将一个分支的更改合并到另一个分支。通常，您会将功能分支的代码合并到主分支（或 master）。这是一种融合单独工作历史的方法，可确保功能的最新更新包含在主项目中。

经过一些更改后合并的示例：

// Start a new feature
git checkout -b new-feature
//Edit some files
git add 
git commit -m "Start a feature"
// Edit additional files
git add 
git commit -m "Finish a feature"
// Merge in the new-feature branch
git checkout main
git merge new-feature

在团队协作中，我们经常使用平台（如 GitHub）进行代码管理。典型的工作流程包括在本地提交更改、将新分支推送到远程存储库，然后打开拉取请求或合并请求。之后，团队成员会审查您的提交，确保一切正常。如果一切顺利，他们会将您的更改合并到主分支中。此过程可确保以协作且有组织的方式将新功能或修复集成到项目中。

合并冲突

Git 合并不可避免的会遇到冲突。

我们通过一个例子来解释一下 Git 冲突：

考虑这样一种情况：项目主分支中存在一个名为 test.js 的文件。现在，设想有两个开发人员在同一个项目的不同分支上独立工作。每个开发人员都对其分支上的 test.js 文件进行了更改。开发人员 A 成功将其更改合并到主分支中。然后，开发人员 B 也尝试将其修改合并到主分支中。因此，Git 检测到冲突的更改并在 test.js 文件中创建合并冲突。现在，开发人员 B 必须解决冲突才能成功合并其分支。通常，这涉及使用一些提供可视化工具的 IDE 来有效识别和解决冲突。

！

当提交发生在不同的行或分支上时，Git 还可以自动合并更改。

CLIS.CC