2

我正在从其他人的存储库中提取更改（出于宣泄的原因，我们称它们为“gitnoob”），其中所有内容都混合在一起。他们最初显然是在他们的主要分支中工作，然后才了解分支。它看起来有点像这样：

                  d - f <--- stuff
                 /   /
A - b - 1 - c - 2 - E <--- dev

这些数字是应该在另一个分支中的提交，如果我将它们合并到我自己的dev分支中，可能会破坏事情。（我将在稍后将它们拉出来upstream/dev——upstream作为我们共享的父存储库——一旦它们被合并到那里。）小写字母是应该是一部分的提交，stuff大写字母是合法合并到的提交dev。

理想情况下，我想在我的最后清理这个 - 在本地有这样的东西：

  b - c - d - f <--- stuff
 /           /
A --------- E <--- dev

现在，无论如何都会发生stuff所有与stuff- 相关的更改，因为gitnoob/stuff还将包括upstream/dev与gitnoob/dev该点之间的所有差异（并且合法dev的差异已经在我的dev分支中）。问题是，这意味着stuff也会有提交1和2，这很可能会破坏事情。

我需要能够在gitnoob/stuff没有大量麻烦的情况下进行更改（并且，如果可能的话，不要让 1 和 2 回到那里直到它们出现在上游），并让他们从我这里拉出更改，而他们最终没有得到任何东西还原或删除。

我该怎么做呢？还是我只是坚持使用 1 和 2 in stuff？

4

2 回答 2

1

在这种情况下，我建议保留过去并尝试在未来做得更好。

b取出和c取出dev并只放入它们有什么好处stuff？由于是在之后stuff分支的，因此无论如何都包含提交。devcstuff

我也很想偶尔做这样的事情，但通常我最终会想那又怎样？当我学习 Git 并从 SVN 切换到这些提交时，情况尤其如此。出问题了。好的。但它有效。所以不要碰它。

版本控制本身是一种工具，而不是目的。你在你的仓库里放了一些代码。那是珍贵的东西。不是——也许——回购的混合历史。

您可以在本地修复分支，但是当涉及从上游合并内容或将更改推送到那里时，您会遇到麻烦。

于 2012-08-23T18:39:47.497 回答
1

所以基本上，你想要一个私人版本的stuff恢复1和2，但你自己的公共版本stuff仍然包含它，以便 gitnoob 从中提取。没有无缝的方法可以做到这一点，但实现它的一种方法是引入几个新分支：

...d-f <---stuff-upstream
      \
       g <---reverted-stuff
        \
         h <---my-stuff

您所做的是创建一个reverted-stuff恢复1和2. 当您想要进行与 gitnoob 共享的更改时，您可以从reverted-stuffmake分支my-stuff。在my-stuff. 您也应该能够合并您dev的my-stuff。

当您准备好共享更改时，请my-stuff重新stuff-upstream使用git rebase --onto stuff-upstream reverted-stuff my-stuff. 这将删除您的还原g并使其看起来像是my-stuff直接从 分支出来的stuff-upstream，从而使 gitnoob 可以毫无恐惧地拉动。

当你从 gitnoob 拉取时，拉入stuff-upstream，然后将其合并到reverted-stuff. 该合并将自动重新应用g，您恢复1和2。然后你可以分支一个新my-stuff的reverted-stuff.

话虽这么说，如果1真的2像你说的那样有问题，你也会帮 gitnoob 帮个忙，把它从他的分支中拿出来。如果不是那么糟糕，那真的没有理由经历这一切。

于 2012-08-23T20:03:09.550 回答