11

我对 github 社交编码比较陌生，并且在遵循 github 指南时遇到了麻烦。我将尝试描述发生的事情以及我想要实现的目标——希望更有经验的 git 向导可以帮助我弄清楚到达那里所需的街机命令。

发生了什么

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

我想做的事

我想获得合并到upstream/master的所有更改。最好作为他们各自的提交，而不是数百个文件的大规模提交。因为我在前 上游/主服务器上进行开发（日期为 2012 年 3 月 29 日），我想实际上需要在 3 月 29 日的最后一次上游/主服务器更改和我 8 月 8 日的第一次提交之间“插入”一些提交，并且然后在此之上添加后来发生的那些。我怎么做？

（我也不想在这个过程中破坏我的提交/分叉；-）

我试过的

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

但是，它不会让我这样做git push，抱怨我的本地提示是 10 次提交落后于原点（可能是我在我的主题分支上所做的提交，后来合并到origin/master？）。

建议？

看来我可能被建议咬了。例如。也许创建一个单独的分支会更好，例如。local-master，并将其视为......好吧，我自己的主人。那么master只会在那里与upstream/master保持联系，我偶尔会将origin/master重新设置为upstream/master并与origin/local-master合并...

你们是如何管理你的叉子的？

其他问题

我一直无法找到一种方法来可视化分支历史、哪个分支与另一个分支以及何时合并等等。Github for Windows 仅显示当前所选分支的平面历史记录（这里是悲伤的脸）。该网站确实有一些网络可视化（这里是 MassTransit 的一个），但这感觉比TortoiseHg 中的图表提供的信息要少得多。我错过了一些明显的东西吗？其他人是否只记得什么与什么以及何时合并？

编辑（8 月 31 日）

我正在分享一个穷人的可视化来帮助解释发生了什么。

  1. 当C1在upstream/master上最新时，我分叉了。
  2. 然后我在我的origin/feature-1上开发。
  3. 其中一项功能已完成，我将其与我的origin/master合并。
  4. 当upstream/mega-feature完成后，它与upstream/master合并，有效地将C2和C3复制到upstream/master。（或者也许upstream/master是用upstream /mega-feature重新定位的？）
  5. 我现在想将C2、C3和C4复制到我的origin/master。
4

2 回答 2

6

我假设您将或已经origin为您的 fork 设置了一个遥控器，并且upstream（如前所述）同样如此。

然后我会做一个提取，upstream这样你就可以将他们的所有分支机构都放在本地。然后，您可以在 repos 之间进行比较，看看在分歧日期或附近是否有共同的提交。

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

[编辑] 冗长的描述。

显然，合并提交正在“妨碍”，因此需要进行按摩，以便可以再次使存储库同步。

  1. 在您当前的头部创建一个temp分支，因此不会丢失任何内容。
  2. reset你的主分支回到你和上游之间的最后一个共同提交。
  3. reset您的功能分支到合并之前。
  4. checkout合并提交以获得您期望的工作树，然后
  5. 切换到您的功能分支（无需检查任何内容！）
  6. commit您feature分支上的固定工作树（即没有合并）。

您现在有一条干净的线路master，一条干净但旧的线路feature，以及任何合并后的开发temp。如果 Happy，您应该可以将其强制推送到您的origin.

  1. pull从上游 - 它（即master等）应该都快进。
  2. rebase那些后合并开发从temp到feature（如果需要）。
  3. rebase feature到您在 master 上熟悉的最后一次提交（应该相对容易）。
  4. rebase feature（再次）到 master 上的最新提交，随时修复（如果很容易，请结合最后一步；-）。

这应该最终为您提供了一个清晰的功能开发路线，并且适合在没有任何冲突的情况下向上游拉动。

于 2012-08-30T22:43:03.213 回答
2

这里有一些想法。

樱桃采摘方法：

git checkout master
git cherry-pick C2..C4

新的分支变基方法：

git checkout upstream/master
git branch new-master
git rebase master
# new-master should now look like what you want, once you confirm this
git branch -m master old-master
git branch -m new-master master

Rebase --onto 方法（让你选择你想要的提交范围）：

git checkout master
git rebase --onto master C2 C4 # puts you into a detached HEAD
git branch new-master
# rename branch as above if it is correct
于 2012-08-31T10:29:46.410 回答