Github使用origin / master对上游/ master进行rebase

时间：2012-08-30 14:54:46

标签： git github git-rebase github-for-windows

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

发生了什么

  1. 我在 2012年7月中分享了MassTransit。当时 master 分支的版本为v2.1.1，最后一次提交在 2012年3月29日。
  2. 根据github的建议，我开始编写主题分支的一些更改。
  3. 稍后提交一些提交，当该功能完成后，我将我的主题分支合并到我的克隆本地主中，然后将其推送到github。
  4. 自 2012年3月29日以来，MassTransit正在其 develop 分支上开发。所有这些变化，组成v2.6.0，最近都与其 master 合并。

    5. 我想做什么

    我希望获得合并到上游/主机的所有更改。最好是各自的提交，而不是数百个文件的大量提交。因为我在前 上游/主人（日期为2012年3月29日）进行开发，我想有效地需要＆＃34;插入＆＃34;一些提交在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 < / EM>？）。

    推荐？

    似乎我可能被建议所困扰。例如。或许最好创建一个单独的分支，例如。 local-master ，并把它视为......好吧，我自己的主人。那么 master 只会与上游/主保持联系，我偶尔会使用上游/ 来源/主 master 并与 origin / local-master ...

    合并

    你们如何管理你的货叉？

    其他问题

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

    编辑（8月31日）

    我正在分享poor-man's visualization来帮助解释发生的事情。

    1. 当 C1 最新上游/主人时，我分道扬。
    2. 然后我在我的 origin / feature-1 上开发。
    3. 其中一项功能已完成，我将其与 origin / master 合并。
    4. 上游/超级功能完成后，它与上游/主机合并，有效地历史上复制 C2 和 C3 到上游/主人。 （或者上游/主人 重新 上游/超级功能？）
    5. 我现在想将 C2 ， C3 和 C4 复制到我的 origin / master 。

2 个答案:

答案 0 :(得分：6)

我假设你将会或者已经为你的前叉设置origin遥控器，upstream也是如此（如上所述）。

然后我会取一下upstream，这样你就可以在本地保存所有分支。然后，您可以在回购之间进行比较，看看在分歧日期或附近是否存在共同提交。

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

[编辑]一个罗嗦的描述。

显然，合并提交正在“阻碍”，因此需要按摩远，以便可以使回购再次同步。

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

    7. 现在master上有一条简洁的线，feature上的一条干净但旧的线，以及temp上的所有合并后发展。如果快乐，你应该强行推送到origin。

      来自上游的
    1. pull - 它（即master等）都应该快进。
    2. rebase将temp合并后的发展合并到feature（如果需要）。
    3. rebase feature到你在master上熟悉的最后一次提交（应该相对简单）。
    4. rebase feature（再次）关于master的最新提交，随时修复（如果容易的话，结合最后一步; - ）。

      5. 这应该最终为您提供一个完整的功能开发线，并且适合在没有任何冲突的情况下上游。

答案 1 :(得分：2)

以下是一些想法。

Cherry pick方法：

git checkout master
git cherry-pick C2..C4

新分支rebase方法：

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
相关问题
最新问题