前言：您的分叉是“源”，您分叉的存储库是“上游”。

假设您已经使用如下命令将分叉克隆到计算机：

git clone git@github.com:your_name/project_name.git
cd project_name

如果已给出，则需要按以下顺序继续：

将“上游”添加到克隆的存储库（“源”）：git远程添加上游git@github.com：original_author/project_name.git从“上游”获取提交（和分支）：git获取上游切换到分叉的“master”分支（“origin”）：切换到主分支停止“主”分支的更改：暂存将“上游”的“主”分支中的更改合并到“源”的“母”分支中：git合并上游/主解决合并冲突（如果有）并提交合并gitcommit-am“从上游合并”将更改推到叉上数字推送找回你藏起来的零钱（如果有的话）吉特藏弹你完了！祝贺

GitHub还提供了有关此主题的说明：同步分叉

许多答案最终会将fork移到父存储库之前一次提交。这个答案总结了这里找到的步骤，这些步骤会将您的fork移动到与父级相同的提交。

将目录更改为本地存储库。如果您不是git结账主管，请切换到master分支将父级添加为远程存储库，git remote Add upstream＜repo location＞向上游发出git fetch发布git上游/主数据库在这个阶段，您可以通过键入gitstatus来检查提交将要合并的内容发布git推送源主机

有关这些命令的更多信息，请参阅步骤3。

自2013年11月以来，GitHub发布了一个非官方的功能请求，要求他们添加一个非常简单直观的方法来保持本地分叉与上游同步：

https://github.com/isaacs/github/issues/121

注意：由于功能请求是非官方的，因此建议联系support@github.com添加对要实现的类似功能的支持。上述非官方功能请求可作为对正在实施的功能感兴趣的证据。

从github页面删除远程设备

然后应用这些命令：

1) git branch -D dev
2) git fetch upstream
3) git checkout master
4) git fetch upstream && git fetch upstream --prune && git rebase upstream/master && git push -f origin master
5) git checkout -b dev
6) git push origin dev
7) git fetch upstream && git fetch upstream --prune && git rebase upstream/dev && 8) git push -f origin dev

要查看配置，请使用以下命令：

git remote -v

有三种方法可以做到这一点：从web UI（选项1）、从GitHub CLI（选项2）或从命令行（选项3）。

---

选项1-Web UI

在GitHub上，导航到要与上游存储库同步的分叉存储库的主页面。选择“获取上游”下拉列表。

查看上游存储库中有关提交的详细信息，然后单击“获取并合并”。

---

选项2-GitHub CLI

要从父级更新远程分叉，请使用gh repo sync子命令并提供分叉名称作为参数。

$ gh repo sync owner/cli-fork

如果来自上游存储库的更改导致冲突，则GitHub CLI无法同步。您可以设置-force标志来覆盖目标分支。

如何安装GitHub CLIGitHub CLI手册

---

选项3-命令行

在将分叉与上游存储库同步之前，必须在Git中配置指向上游存储库的远程。

1打开Git Bash。

2将当前工作目录更改为本地项目。

3从上游存储库获取分支及其各自的提交。对BRANCHNAME的提交将存储在本地分支上游/BRANCHNAME中。

$ git fetch upstream
> remote: Counting objects: 75, done.
> remote: Compressing objects: 100% (53/53), done.
> remote: Total 62 (delta 27), reused 44 (delta 9)
> Unpacking objects: 100% (62/62), done.
> From https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY
>  * [new branch]      main     -> upstream/main

4查看fork的本地默认分支-在本例中，我们使用main。

$ git checkout main
> Switched to branch 'main'

5将来自上游默认分支（在本例中为upstream/main）的更改合并到本地默认分支中。这将使fork的默认分支与上游存储库同步，而不会丢失本地更改。

$ git merge upstream/main
> Updating a422352..5fdff0f
> Fast-forward
>  README                    |    9 -------
>  README.md                 |    7 ++++++
>  2 files changed, 7 insertions(+), 9 deletions(-)
>  delete mode 100644 README
>  create mode 100644 README.md

如果一个人的本地分支没有任何唯一的提交，Git将执行“快进”：

$ git merge upstream/main
> Updating 34e91da..16c56ad
> Fast-forward
>  README.md                 |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

---

注意：同步一个人的分叉只会更新回购的本地副本。要更新GitHub.com上的分叉，必须推送更改。

---

来源：GitHub Docs-同步分叉

从2014年5月开始，可以直接从GitHub更新fork。截至2017年9月，这仍然有效，但这将导致肮脏的犯罪历史。

在GitHub上打开你的分叉。单击拉取请求。单击New Pull Request。默认情况下，GitHub会将原始文件与您的fork进行比较，如果您没有进行任何更改，则不应该有任何可比较的内容。如果看到该链接，请单击切换基础。否则，手动将底叉向下设置到叉上，将头叉设置到上游。现在GitHub将您的分叉与原始分叉进行比较，您应该可以看到所有最新的更改。创建拉取请求并为拉取请求分配一个可预测的名称（例如，从原始请求更新）。向下滚动到Merge pull请求，但不要单击任何内容。

现在您有三个选项，但每个选项都会导致提交历史记录不那么清晰。

默认值将创建难看的合并提交。如果您单击下拉菜单并选择“压缩并合并”，所有中间提交都将被压缩为一个。这通常是你不想要的。如果您单击Rebase并合并，所有提交都将“与”您一起进行，原始PR将链接到您的PR，GitHub将显示This branch is X commits before，Y commits behind＜original fork＞。

因此，是的，您可以使用GitHub web UI保持回购的上游更新，但这样做会玷污您的提交历史。而是坚持使用命令行-这很简单。