Question

问题标题可能毫无意义，但我试过了。 :)

这是我的情况：

我有一个带有单个分支（master）的存储库。（从那个存储库，当我“发布”构建时，我在代表已发布的构建的提交处添加了一个标记，所以我可以回到它。）

如果我查看提交的时间表，让我们说它看起来像这样：

Start ----------> A --> HEAD

其中“A”是近期的一些提交，但在HEAD之前。我想“发布”一个省略了自A以来所有变化的构建。但我还想在发布之前对该版本的树进行一到两次调整。我在概念上要做的是回滚到A点，提交几个更改，然后在发送之后，重新应用所有来自A - ＆gt;的差异。 HEAD，它会让我重新回到最新状态，并包括我对A做的几个调整。

这就是我想在概念上做的事情。我不确定如何考虑使用git实现这一目标的最佳方法。有人可以在这里提供一些深思熟虑的指导吗？

谢谢！

Answer 1

你可以用git rebase -i完成你所要求的。提交您的新更改，然后使用rebase -i移动它们。

但是，如果您曾与任何人共享该树，最好不要替换这些中间版本，而是执行git checkout -b release_A A之类的操作，然后在该分支上进行更改。然后，您可以git merge或git cherry-pick将其重新发送给您的主人。

Answer 2

git checkout -b release_A A;会根据该版本为您提供一个分支机构。（假设它被标记为release_A - 您也可以使用sha1sums来引用特定的提交。）

Hack和git commit创建新提交。

git tag release_A_2所以你有这个版本的标签。

然后选择以下其中一项：

git rebase A master或git checkout master; git rebase A
git checkout master; git merge A

在任何一种情况下，您都可以选择使用git branch -d A来消除您不再使用的分支。

选择1将完全按照你的要求行事。但是，如果其他人使用此分支进行任何操作，通常是一个坏主意。根据您的设置，这可能是您想要的。

选择2实际上不会更改历史记录 - 所有提交都代表实际历史记录。相反，它会将该分支中的更改合并到master中。合并通常有痛苦的声誉，但这个git应该与案例1一样聪明。如果你在release_A之后标记或发布了任何东西，我强烈建议使用这种方法，因为它意味着那些仍然可以重现。

Git用法：在HEAD之前“插入”提交

2 个答案: