Github rebase upstream/master 与 origin/master

Question

我是 github 社交编码的新手，在遵循 github 指南时遇到了问题。我将尝试描述发生的事情以及我想要实现的目标 - 希望更有经验的 git 向导可以帮助我找出实现目标所需的街机命令。

• 原始项目:https://github.com/phatboyg/MassTransit
• 我的 fork :https://github.com/davidcie/MassTransit
• 平台:Windows，Github for Windows + 它的PowerShell

发生了什么

1. 我在 2012 年 7 月 fork 了 MassTransit。当时它的 master 分支是 v2.1.1 版本，最后一次提交是在 2012 年 3 月 29 日。
2. 按照 github 的建议，我开始在主题分支上编写一些更改。
3. 几次提交后，当功能完成时，我将我的主题分支 merge 到我克隆的本地 master 中，然后将其推送到 github。
4. 自 2012 年 3 月 29 日以来，MassTransit 一直在其开发 分支上开发。构成 v2.6.0 的所有这些更改最近都与其master merge 。

我想做什么

我想获取所有 merge 到 upstream/master 中的更改。最好是他们各自的提交，而不是数百个文件的大规模提交。因为我在 former upstream/master(日期为 2012 年 3 月 29 日)上进行开发，所以我想实际上需要在最后一个 upstream/master 3 月 29 日的更改和我 8 月 8 日的第一次提交，然后在其之上添加那些后来发生的。 我该怎么做？

(我也不想在此过程中破坏我的提交/ fork ；-)

我尝试了什么

git checkout master
git remote add upstream git://github.com/phatboyg/MassTransit.git
git rebase upstream/master
git push

但是，它不会让我执行 git push，提示我的本地提示是原点后面的 10 次提交(可能是我在我的主题分支上所做的提交，后来 merge 到 起源/主人？)。

建议？

看来我可能是被推荐给坑了。例如。也许创建一个单独的分支会更好，例如。 local-master，并把它当成……好吧，我自己的主人。然后 master 只会在那里与 upstream/master 保持联系，我偶尔会 rebase origin/master 与 upstream/master 并与 origin/local-master merge ...

你们是如何管理 fork 的？

其他问题

我一直无法找到一种方法来可视化分支历史记录、哪个分支与另一个分支 merge 以及何时 merge 等。Github for Windows 仅显示当前所选分支的平面历史记录(此处为悲伤的表情)。该网站确实有 一些 网络可视化 ( here is one for MassTransit )，但这感觉比 graphs in TortoiseHg 提供的信息要少得多.我错过了一些明显的东西吗？其他人是否只记得 merge 的内容和时间？

编辑(8 月 31 日)

我正在分享 poor-man's visualization帮助解释发生了什么。

1. 当 C1 在 upstream/master 上最新时，我进行了 fork 。
2. 然后我在我的 origin/feature-1 上开发。
3. 功能完成后，我将其与我的origin/master merge 。
4. upstream/mega-feature 完成后，它与 upstream/master merge ，有效地复制了 C2 和 C3 到 upstream/master。 (或者 upstream/master rebased upstream/mega-feature？)
5. 我现在想将 C2、C3 和 C4 复制到我的 origin/master。

Answer 1

我假设您将要或已经为您的 fork 设置一个 origin 远程，并为 upstream 设置相同的远程(如所述)。

然后我会获取 upstream 以便您将它们的所有分支保存在本地。然后，您可以对存储库进行比较，看看在分歧日期或接近分歧日期时是否存在共同提交。

gitk --all 可视化在这里很有用。不要忘记，即使你做了一个 rebase ，旧的提交系列仍然存在，所以你可以给它一个名字

---

[编辑] 冗长的描述。

很明显， merge 提交正在“妨碍”，因此需要消除，以便重新同步 repo 协议(protocol)。

1. 在您当前的头部创建一个 temp 分支，这样就不会丢失任何内容。
2. 重置您的主分支回到您和上游之间的最后一次共同提交。
3. 将您的功能分支重置到 merge 之前。
4. checkout merge 提交以获得预期的工作树，然后
5. 切换到你的功能分支(不检查任何东西!)
6. commit 在您的 feature 分支上修复工作树(即不 merge )。

您现在在 master 上有一条干净的线，在 feature 上有一条干净但旧的线，在 temp 上有任何 merge 后的开发。如果 Happy，您应该能够强制将其推送到您的 origin。

1. pull 从上游 - 它(即 master 等)应该都快进。
2. rebase 那些从 temp 到 feature 的后期 merge 开发(如果需要)。
3. rebase feature 到您在 master 上熟悉的最后一次提交(应该相对容易)。
4. rebase feature(再次)到 master 上的最新提交，边走边修复(如果容易的话，与最后一步结合；-)。

这最终应该在 master 的领导下给你一个清晰的功能开发线，并且适合在没有任何冲突的情况下 pull 上游。