迹忆客 专注技术分享

本篇文章将介绍从 Git 中的远程仓库分支中拉取更改时重新设置本地分支的基础。

我们使用版本控制系统 Git 来跟踪对文件所做的更改。我们在本地仓库的本地分支中提交更改。此本地分支与远程仓库的远程分支相关联。

有时，我们会将远程仓库的更改与本地仓库中的更改同步。我们将远程分支的更改拉入本地分支。

当我们拉入远程分支更改时，我们可以重新设置本地分支（即）以在已发布的更改之上重新应用未发布的更改。

我们现在将用一个例子来说明这一点。

从 Git 中的远程仓库分支拉取时，使用 git pull --rebase 对本地分支进行 Rebase

在协作开发环境中，我们使用 Git 在本地系统的本地仓库中创建分支。我们将此本地分支与远程仓库中的远程分支相关联。

我们暂存并提交对本地分支中的文件所做的更改。然后我们将这些更改发布到远程仓库中的远程分支。

然后，团队的其他成员也使用相同的仓库，将已发布的更改拉入其系统的本地分支中。

因此，我们定期执行将本地更改推送到远程仓库并从远程仓库拉入已发布更改的过程。

当将远程分支的已发布更改拉入我们的本地分支时，我们可以选择进行合并或进行变基。

在合并的情况下，我们使用命令 git pull --merge，这是默认选项。当我们在合并案例中拉入远程仓库更改时，本地更改将与远程更改合并。

创建合并提交以指向最新的本地和远程提交。

在变基的情况下，我们使用命令 git pull --rebase。在 rebase 中，本地分支的未发布的本地更改被重新应用到远程仓库的已发布更改之上。

在 rebase 的情况下，不会创建新的提交。

假设我们在本地仓库中有一个名为 feature 的分支，它与远程仓库中同名的远程分支相关联。

团队中的每个开发人员都将在其本地系统中拥有 feature 本地分支。

假设一位开发人员已对本地分支 feature 提交了一些更改。

现在，假设其他开发人员已经发布了对远程仓库的远程分支 feature 的一些更改。

因此，现在分支的情况如下图所示。

              P---Q---R feature (local branch)
             /
A---B---C---D---E---G feature (remote branch)

如上图所示，我们现在有一个分叉的历史。我们需要将远程分支的更改拉入本地分支以获取已发布的更改。

假设远程分支 feature 中的新提交与本地分支中的提交相关（通常是这种情况）。因此，在这种情况下进行拉取时，我们会进行变基而不是合并。

我们需要执行带有 --rebase 选项的 git pull 命令来执行 rebase。该命令的语法是 git pull --rebase <remote-repository> <remote-branch-name>。

因此，在我们的例子中，要重新定位我们的本地分支 feature，我们将执行以下操作。

$ git pull --rebase origin feature

因此，执行上述 git pull 命令后，分支如下图所示。

                      P---Q---R feature (local branch)
                     /
A---B---C---D---E---G feature (remote branch)

因此，如图所示，本地分支 feature 的所有未发布提交都移动到远程分支 feature 更改的尖端。不会创建新的提交。

rebase 选项的主要优点是项目历史比使用合并选项更清晰。

此外，如上图所示，我们获得了线性项目历史记录。没有分叉。使用 git log 命令可以轻松浏览项目的历史记录。

因此，我们已经详细说明了在从 Git 中的远程仓库中提取更改时重新定位本地分支。