2

我有一个小项目，用 Git 维护它的版本控制。术语版本控制在这里指的是您可以想象的最简单的形式：仅在主分支上一个接一个地生成提交，并在一天结束时将所有提交推送到远程。到目前为止，一切都很好。仅拥有一个主分支就足够了，因为始终需要应用程序的最新状态。

然后采购员告诉我他们需要v1.1和v1.2。问题是最新的主提交包含 v1.1 的所有内容和 v1.2 的一些未完成的内容。

我的第一个意图是找到两个“功能包”不同的基本提交。我从该提交中创建了两个分支，并开始一一挑选基础之上的提交。幸运的是，他们并没有太多。这导致两个分支（v1.1 和 v1.2）保留了适当的东西，除了我必须将 v1.2 重新定位到 v1.1 上，因为 v1.1 中的功能在 v1.2 中也需要

毕竟，我有以下历史：

在此处输入图像描述

正如你所看到的，我有一个“悬空”分支，它实际上是主分支，但我不需要这些提交，因为它们都被精心挑选到了正确的位置。

问题很简单：如何优雅地处理这种情况（基本上删除那些不必要的提交）而不造成任何伤害，或者是否有任何其他方式可以实现相同的结果？

4

3 回答 3

1

今年在 ThatConference 上有一个非常好的演讲（幻灯片可在链接中找到）： http ://www.thatconference.com/sessions/speaker_188 演示者正好遇到了这个问题，并描述了她是如何用 git 解决的。

基本上，你真的不应该按照你描述的工作流程来实现你想要的。更好的方法是让存储库中的每个分支都代表单独的功能。然后，您将这些功能捆绑在一起，合并提交到主分支或合并分支，并用您的版本号标记。

尽管这听起来无济于事（显然您已经使用当前的工作流程创建了历史记录），但它可能对未来有用。

于 2013-09-24T21:59:56.670 回答
1

我认为最好的解决方案，我希望我能正确理解它是git rebase

以下是一些关于rebase分支的信息。

获得工作流程的另一个很酷的解决方案，您应该看看gitflow。

于 2013-09-24T22:00:18.780 回答
0

听起来您发现这不是一个理想的情况。不过不用担心 - 解决方案非常简单。

如果能够拿出一把斧头，然后开始砍掉 master 上的那一大串不同的提交，然后将你的工作合并回 master，那就太好了。不幸的是，我怀疑这是否会与任何同事相处得很好，因为当他们尝试将更改合并到主分支时，这会导致冲突（甚至可能是字面冲突）。因此，与其重写历史记录，不如进行新的提交。

  1. 首先通过运行移动到主分支git checkout master。
  2. 然后，从项目的根目录运行git checkout -f <commit> .where<commit>表示提交的 SHA 哈希，并显示消息“测量列表单元格渲染器中的活动 pst 颜色已更改”（例如，看起来类似于：的内容7cd052c）。请注意末尾的点，它表示从指定的提交中检查当前目录的版本。
  3. 最后一步更改了工作目录中的文件，以反映它们在分歧开始的共同祖先处的状态。现在，让我们用git commit -a.
  4. 此时，您应该能够合并回 master 而不会发生任何冲突：git merge v12.

从现在开始，您可以将所做的任何其他更改合并到主分支中！

于 2013-10-15T07:43:21.007 回答