🤕 Git 可视化：分叉了一个 Repo，现在原始版本有更多提交

让我们考虑一下您正在为开源项目做出贡献的场景。

现在该怎么办？你可能在职业生涯的某个阶段就遇到过这种情况。大多数初学者仍然会遇到这种情况。

对于所有正在苦苦挣扎的人来说，本指南将帮助你处理这种情况，并帮助你理解 git 的底层概念。那就让我们开始吧！

👨‍💻 Git 分支的当前状态

以下是当前场景的可视化。

对于不熟悉概念的人来说upstream，它既不是本地仓库，也不是 fork 仓库，而是指向 GitHub 上的原始仓库。默认情况下不设置。您需要手动将克隆的仓库与链接upstream。

为了方便起见，我们假设有两个存储库：

下面是执行此操作的 git 命令。

# Add Upstream Remote.
git remote add upstream https://github.com/dailydotdev/daily.git

# Fetch latest updates from it.
git fetch upstream

请记住，这些更新将在中upstream/[BRANCH_NAME]。完成后，本地仓库中的远程指针现在如下所示：

在此阶段，我们upstream/master在本地可用，我们需要将新的提交（即图中的 E 和 F）带到我们的feature分支。这里我们有两个选择：

两者都可用于获得最终结果——获取最新更新upstream/master并保留我们的提交。

确保你位于功能分支上。使用以下命令进行合并：

# Merge upstream/master to feature branch. 
git merge upstream/master

如果合并过程中存在任何冲突，请解决它们。否则，只需编写合并提交消息即可。在后台，您的feature分支如下所示。最后一次提交是每次执行合并时进行的合并提交。

这只是一些你可能不想要的复杂历史记录。你只需要在的基础上进行修改，upstream/master然后进行push origin拉取请求。

git rebase我发现它非常适合这种情况。有了它，你就能获得干净的 git 历史记录，仅此而已。因此，除了之外git merge，你可以执行以下操作：

# Rebase feature branch on top of upstream/master
git rebase upstream/master

现在，看一下功能分支的样子：

你注意到提交 C 和 D 顶部的星号 (*) 了吗？如果你不熟悉git rebase，我用它们来表示这些提交是原始提交 C 和 D 的副本。

🤔 看看这个功能分支——可能正是我们 PR 需要的，仅此而已。完美！

更新：
您还可以使用以下命令在一个命令中实现此全部操作。

git pull upstream master --rebase

让我们看看这两种情况是如何git push运作的。之后，我们只需要创建一个 PR。

# Push changes to the origin. 

#In case of merge
git push origin feature

# In case of rebasing
git push --force origin feature

你注意到--force变基时的那个标志了吗？这是因为我们正在重写历史。🙈

该feature分支最初有以下提交：

A — B — C — D

使用 rebase，我们将其更改为：

A — B — E — F — C* — D*

因此，我们不仅创建了 C 和 D 提交的副本，还将 E 和 F 放回了它们原来的位置：git 历史记录已更改。这就是为什么我们需要--force标记。否则，您可能会收到错误。

由于它会git rebase复制提交和更改历史记录，因此在与团队共享这些提交时请勿使用它。使用时务必谨慎。理想的情况是，您尚未与任何人共享您的工作。

通过用例学习是掌握任何东西的最佳方法。你不仅可以解决问题，还能了解过程中涉及的技术用法。

我希望这篇文章不仅能帮助你解决这种情况，还能帮助你了解它们的用法git merge和git rebase区别，以及在何处使用它们。如果你有任何疑问，请在下方评论区留言。

👋 在Twitter 上关注我们，了解最新动态！

有了 Daily，开发者可以专注于代码，无需搜索新闻。只需打开新标签页，即可立即访问所有这些文章及更多内容。