如何从分叉的 github 存储库合并非主分支上的更改?

发布于 2024-08-16 20:37:25 字数 880 浏览 6 评论 0 原文

在以下两个 StackOverflow 问题中,接受的答案描述了在分叉存储库、修改原始存储库,然后要将主分支所做的更改合并回的情况下,如何合并分叉存储库中的更改你的分叉仓库。

但是,我不清楚你如何保留您分叉的原始存储库中的非主分支是最新的。例如,当我最初分叉bitprophet的fabric存储库时,它包含以下分支:

  • master
  • 0.9
  • 0.9-doc- rewrite(不再存在)
  • path-and-#24(不再存在)

最后两个分支不再存在,现在有一个新分支flexible-task-declarations。我已经获取、合并并推送了 master 分支,以便 master、origin/master 和upstream/master 都具有相同的 SHA1 哈希值并指向相同的 git 快照。但是,我不确定如何删除不再存在的分支并更新新分支,以便我的分支是最新的。我是否需要跟踪每个上游分支,然后单独获取、合并和推送每个分支,还是有更好的方法?

In both of the following StackOverflow questions, the accepted answer describes how to merge changes from a forked repository in the situation where you fork a repo, the original repo is modified, and then you want to merge the changes made to the master branch back into your forked repo.

However, I'm not clear on how you keep up to date on the non-master branches in the original repo that you forked. For instance, when I originally forked bitprophet's fabric repository, it contained the following branches:

  • master
  • 0.9
  • 0.9-doc-rewrite (no longer exists)
  • path-and-#24 (no longer exists)

The last two branches no longer exist, and now there is a new branch flexible-task-declarations. I have fetched, merged, and pushed my master branch, so that master, origin/master, and upstream/master all have the same SHA1 hash and point to the same git snapshot. However, I'm not sure how to remove the branches that no longer exist and update the new branches so that my fork is up to date. Do I need to track each upstream branch and then fetch, merge, and push each branch individually, or is there a better way?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

衣神在巴黎 2024-08-23 20:37:25

场景 1:删除不再存在的分支

要删除不再存在的分支,我按照 StackOverflow 问题 如何通过发出以下命令删除本地和 Github 中的 Git 分支?

$ git push origin :0.9-doc-rewrite
$ git push origin :path-and-#24

场景2:合并现有非主分支中的更改

为了使upstream/0.9分支保持最新,我执行了以下操作:

$ git checkout --track origin/0.9
$ git fetch upstream
$ git merge upstream/0.9
$ git push

场景3:跟踪新的非主分支

不确定这是最好的处理方式,但这就是我所做的:

$ git branch flexible-task-declarations upstream/flexible-task-declarations
Branch flexible-task-declarations set up to track remote branch flexible-task-declarations from upstream.
$ git checkout flexible-task-declarations
$ git push origin flexible-task-declarations

确认所有分支都处于同一提交:

$ git branch -av

这将显示所有分支(本地和远程)并显示最新的提交消息和 SHA1 哈希值。

网络研究可能会揭示处理场景 3 的更好方法

与简单的 Git 克隆或 SVN 签出相比,Git 分叉之间的一个关键区别是,除非您这样做,否则您的分叉永远不会与主存储库保持同步。幸运的是,有一个简单的工具可以帮助您做到这一点。你的分叉是独立的,并且与 Git 术语中的主分支相同,因此如果你想跟踪主分支的更改,你可以在你的分叉存储库中创建一个跟踪分支,并在你想要提交某些内容时将这些更改合并到你的分叉的主分支中。
我强烈推荐“GitHub”gem,它是一个可以安装的工具,可以帮助您轻松跟踪与您的存储库相关的任何其他存储库中的更改。有关安装和使用的信息,请参阅本页底部的 README 文本:
http://github.com/defunkt/github-gem/tree/master

忽略 Github Fork 队列这太邪恶了! fork 队列是维护者的一个工具,他们喜欢从贡献者那里选择单个提交,但不希望合并到整个分支中。如果你玩弄分叉队列,你会损坏你的分叉(不过它可以修复,请阅读“出了点问题”)。 github 上的许多新手觉得他们应该对 fork 队列做一些事情,因为那里有很多可能相互冲突的更改,并且他们不知道保持 fork 最新的假定方法。阅读让你的 fork 保持最新状态并找出答案!

Django 的 Github 工作流程

Django 项目有关于如何在 Github 上协作的说明,该说明使用了以下内容处理分叉和拉入上游更改的标准方法。

不同的初始分叉配置

Long Nguyen 的客座帖子,标题为 为 GitHub 上的开源项目设置 Git 存储库 描述了一种有趣的方法来设置您已分叉的 Github 存储库。根据本文,此方法的目标是:

  • 保持存储库同步,以便每个存储库都包含完整的“官方”存储库
  • 允许开发人员引入官方更新
  • 鼓励在 master 以外的分支上工作

Scenario 1: Deleting the branches that no longer exist

To delete the branches that no longer exist, I followed the instructions in the answer to StackOverflow question How do I delete a Git branch both locally and in Github? by issuing the following commands:

$ git push origin :0.9-doc-rewrite
$ git push origin :path-and-#24

Scenario 2: Merging changes in an existing non-master branch

To get the upstream/0.9 branch up to date, I did the following:

$ git checkout --track origin/0.9
$ git fetch upstream
$ git merge upstream/0.9
$ git push

Scenario 3: Tracking the new non-master branches

Not sure that this is the best way to handle, but here's what I did:

$ git branch flexible-task-declarations upstream/flexible-task-declarations
Branch flexible-task-declarations set up to track remote branch flexible-task-declarations from upstream.
$ git checkout flexible-task-declarations
$ git push origin flexible-task-declarations

To confirm that all branches are at the same commit:

$ git branch -av

This will show all branches—local and remote—and show the most recent commit message and SHA1 hash.

Web research that may shed light on a better method for handling scenario 3

A key difference between a Git fork, when compared to either a simple Git clone, or an SVN checkout, is that your fork will never keep itself up to date with the master repo unless you do it. Fortunately, there is a simple tool to help you do this. Your fork is separate and equal to the master in Git terms so if you want to track changes to the master you can create a tracking branch in your forked repo and merge those changes into your fork’s master branch whenever you want to commit something.
I highly recommend the ‘GitHub’ gem which is a tool you can install to help you easily track changes in any other repository related to yours. See the README text at the bottom of this page for installation and usage:
http://github.com/defunkt/github-gem/tree/master

Ignore the Github Fork Queue It's evil! The fork queue is a tool for maintainers who like to pick single commits from contributors but don't wish to merge in their whole branch. If you play around with the fork queue you will corrupt your fork (it can be fixed though, read Something went wrong). Many newbies on github feel like they should do something with the fork queue because there are a lot of possibly conflicting changes in there and they don't know what is the supposed way of keeping one's fork up-to-date. Read Keeping your fork up to date and find out!

Django's Github Workflow

The Django project has instructions on how to Collaborate on Github which uses what appears to be the standard way to handle forking and pulling in upstream changes.

Different Initial Fork Configuration

Long Nguyen's guest post entitled Setting up your Git repositories for open source projects at GitHub on Michael Hartl's blog describes an interesting method to setup a Github repository that you've forked. The goals of this method according to the article are to:

  • Keep the repositories in sync so that each contains the full “official” repository
  • Allow developers to pull in official updates
  • Encourage working on branches other than master
忘年祭陌 2024-08-23 20:37:25

基本上,您有 3 个远程 Git 存储库,请考虑:

  • 本地:您工作站上当前的 git 存储库。
  • 来源:这是你的 Fabric 的分叉版本:cumulusware
  • 上游:bitprophet / Fabric,所有其他分叉存储库的起源

您可以将上游作为远程存储库添加到本地。

 git remote add upstream http://github.com/bitprophet/fabric.git

查看远程分支

 git branch -r 

并推送(删除)在原点存在但在上游不再存在的分支

 git push origin :anOldBranch

然后

 git remote prune origin

清除本地存储库上的分支(原点上不再存在,因为您刚刚删除了它们

)存在于原点和上游的分支也需要同步(在将工作推送到原点之前,在上游的分支之上重新调整本地分支可能是向上游发出非常简单的拉取请求的好方法:bitprophet 只会快进合并以包含您的工作)

我不知道您是否可以有一个更简单的过程/命令/脚本来同步两个远程存储库。

Basically, you have 3 remote Git repo ton consider:

  • local: your current git repo on your workstation.
  • origin: which is your forked version of fabric: cumulusware
  • upstream: bitprophet / fabric, the one at the origin of all the other forked repo

You could add upstream as a remote repo to your local.

 git remote add upstream http://github.com/bitprophet/fabric.git

look at the remote branches

 git branch -r 

and push (delete) the ones which exists at origin but no longer exist at upstream

 git push origin :anOldBranch

Then

 git remote prune origin

to clear the branches on your local repo (which do not exist anymore on origin, since you just deleted them)

The branches which do exist both in origin and upstream need to be synchronized as well (rebasing your local branches on top of those from upstream before pushing your work to origin can be a good way to make very easy pull request to upstream: bitprophet would only have fast-forward merge to do to include your work)

I do not know if you could have a more simple process/command/script to synchronize two distant repositories.

于我来说 2024-08-23 20:37:25

我在寻找如何干净利落地执行已接受答案中的场景 3 时遇到了这个答案。经过一番挖掘后,使用 git 1.8,您可以执行以下操作:

git fetch upstream                      ;make sure you have all the upstream changes
git checkout --no-track upstream/0.9    ;grab the new branch but don't track it
git branch --set-upstream-to=origin/0.9 ;set the upstream repository to your origin
git push                                ;push your new branch up to origin

I came across this answer while looking how to do Scenario 3 in the accepted answer cleanly. After some digging around, with git 1.8 you can do the following:

git fetch upstream                      ;make sure you have all the upstream changes
git checkout --no-track upstream/0.9    ;grab the new branch but don't track it
git branch --set-upstream-to=origin/0.9 ;set the upstream repository to your origin
git push                                ;push your new branch up to origin
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文