变基会改变一系列提交的顺序。它会将一系列提交从当前分支移动或重新定位到目标分支。默认情况下，当前分支中尚未在其他分支上的提交将被变基。变基技术允许我们保持线性的历史记录。让我们从下面的图表中理解这一点。要进行变基，我们需要位于需要变基到目标分支的分支中。在我们的场景中，我们需要在特性分支上执行变基命令。执行变基命令后，我们将获得线性的历史记录。执行变基后…… 阅读更多

假设您的特性分支有大量提交 - 例如，数百次提交。与其从特性分支逐个将所有提交合并到主分支，不如选择将所有提交添加到单个提交中。这称为压缩提交，因为它将所有单个提交“压缩”到一个大的更改中。就主分支的历史记录而言，特性分支的历史记录将丢失。我们可以使用以下命令来压缩合并分支的提交到主分支。$ git merge --squash feature_branch该图显示我们有 3 次提交…… 阅读更多

假设我们执行了合并提交，共享了此提交，后来发现代码无法编译或我们的应用程序无法工作。如果我们在合并时出错，就会发生这种情况。在这种情况下，我们需要使用 git revert 命令撤消合并。考虑下图，其中存储库有两个分支——主分支和特性分支。这两个分支都已分叉，每个分支都有两个提交。特性分支中的提交 (C3 和 C4) 已合并到主分支，并且生成的提交已共享。让我们假设…… 阅读更多

假设我们执行了合并提交，后来发现代码无法编译或我们的应用程序无法工作。如果我们在合并时出错，就会发生这种情况。在这种情况下，我们需要使用以下命令撤消合并：- reset 命令；或 revert 命令git reset 命令可用于撤消对 Git 存储库状态的本地更改。git reset 命令将 HEAD 指针移动到给定的提交，并更新索引以匹配该提交。此命令会重写提交历史记录。但是，如果我们已与其他团队共享我们的提交…… 阅读更多

软重置会将 HEAD 指针移动到指定的提交。这不会重置暂存区或工作目录。示例该图显示了 git 存储库中名为 File1.txt 的文件。A、B、C 和 D 代表添加到文件中的行。该图表明在添加每行 A、B 和 C 后都会执行提交。c1 是添加行 A 后执行的提交，c2 是添加行 B 后执行的提交，C3 代表添加行 C 后执行的提交。现在添加行 D。此更改在工作目录中可用，并且…… 阅读更多

混合重置会将 HEAD 指针移动到指定的提交。这是 git 中的默认重置选项。它还会将提交快照的内容复制到暂存区，而不是工作目录。这将导致暂存区被覆盖。在这种情况下，工作目录内容将是安全的。让我们通过一个例子来理解这一点。示例该图显示了 git 存储库中名为 File1.txt 的文件。A、B、C 和 D 代表添加到文件中的行。该图表明在添加每行 A、B 和…… 阅读更多

该图显示了 git 存储库中名为 File1.txt 的文件。A、B、C 和 D 代表添加到文件中的行。该图表明在添加每行 A、B 和 C 后都会执行提交。c1 是添加行 A 后执行的提交，c2 是添加行 B 后执行的提交，C3 代表添加行 C 后执行的提交。现在添加行 D。此更改在工作目录中可用，并且此更改已暂存但尚未提交。现在，如果我们执行硬重置以移动 HEAD 指针…… 阅读更多

commit 命令会隐式地移动分支的 HEAD。下图显示，最初 HEAD 指向提交 c1。每次提交操作后，HEAD 指针都会向前移动到新的提交。我们可以使用 HEAD 指针或提交哈希值执行重置。git reset 命令将显式或强制地将分支的 HEAD 移动到特定提交。重置 HEAD 指针时，我们有 3 个选项：软、混合、硬硬重置当执行硬重置时，git 会将提交快照复制到工作区和暂存区。由于这一点，任何已完成的更改…… 阅读更多

在进行合并时，您可能会遇到一个或多个冲突。现在，如果我们还没有准备好处理此冲突怎么办？也许您有几个冲突，并且您没有足够的时间来解决这些冲突。在这种情况下，我们可以轻松地回到开始合并之前的状态。要中止合并，我们可以使用以下命令$ git merge --abort请注意，如果我们在解决一些冲突并暂存更改后执行此命令，则这些更改将不会保存。一旦命令发出，我们就会回到…… 阅读更多

在现实世界中，当我们合并分支时，我们会经常遇到冲突。冲突发生的原因如下：当同一行代码在两个分支中以不同的方式更改时。在一个分支中更改了给定的文件，但在另一个分支中删除了该文件。在两个不同的分支中添加了相同的文件，但文件的内容不同。在这些情况下，git 将停止合并过程，因为它无法确定如何合并更改。在这种情况下，我们需要手动干预并指示如何继续合并过程。给出的图表…… 阅读更多