3

所以我有一个 master 分支,我们称之为 foo,我已经使用了一段时间,在大约 50 次提交之后,我得到了一个相当复杂的合并历史,因为 foo 有自己的一些子分支。这里的历史对我来说并不重要,所以我决定通过重新设置每个分支并将所有提交压缩为一个来清理事情,这样我就只有一个提交代表 master 和那个分支之间的差异。

起初我以为我可以这样做:

git checkout foo
git rebase master

但这对我不起作用。该分支有超过 50 次提交,每次都涉及许多文件,并且每次提交都会遇到一堆冲突。

相反,我最终做的是:

git checkout foo
<copy all files to another folder>
git checkout master
git branch -D foo
git checkout -b foo
<overwrite all files with the copy I made earlier, and create a new commit>

这满足了我将合并的悠久历史转变为单个压扁的变基的需要,而无需处理沿途的所有冲突,但我只是想知道是否有一种更“git-friendly”的方式来做到这一点?

4

3 回答 3

3

在 git 中执行此操作的更友好的方法是创建第三个集成分支。当你开发 foo 时,合并 master 和 foo 。这将向 git 展示您如何处理同时更改的代码库。在您的配置中启用 rerere(重用记录的分辨率)非常重要。

现在,当您终于准备好将 foo 合并到 master 中时,git 将知道如何解决冲突,就像您一直告诉它如何做那样。

或者,在准备好后将该集成分支合并到 master 中。你应该没有冲突。这取决于您是否可以容忍历史记录中的所有这些测试合并。

这与我在 Branch per Feature 上的帖子有些相关:http: //dymitruk.com/blog/2012/02/05/branch-per-feature/

我不建议压缩提交,因为您会丢失有关文件如何处于它们所处状态的信息。git 必须处理的信息越多越好。

于 2012-11-28T17:44:38.160 回答
0

你有没有尝试过:

git merge --squash

这样做的目的是获取所有更改并将它们放入准备提交的索引中。您仍然会遇到合并冲突,但它们将在一个地方,您可以在提交一大块所述内容之前修复它们。

有关更详细的解释和图表,请查看

于 2012-11-28T17:44:53.300 回答
0

Git 的瓷器无法真正处理将所有合并步骤真正压缩为一个章鱼合并提交所需的扭曲。幸运的是,Git 公开了所需的管道,因此您可以使用一个命令完成此操作。请参阅我对章鱼合并的问题的答案

于 2015-03-23T17:58:21.223 回答