git merge squash and recurring conflicts
我有一个master和alt分支的git存储库。 alt分支包含master代码的修改版本,并且我试图像这样合并从master到alt的更改:
1
| git merge --squash master |
合并导致冲突:
1 2 3 4
| Auto-merging myproject/foo/bar
CONFLICT (content): Merge conflict in myproject/foo/bar
Squash commit -- not updating HEAD
Automatic merge failed; fix conflicts and then commit the result. |
解决冲突并提交更改后,一切似乎都很好,但是当我再次运行git merge --squash master(不对任何分支进行任何更改)时,我也会遇到相同的冲突错误。
这是为什么? 我错过了什么?
-
--squash不会真正合并分支,但会根据分支创建一个提交(然后合并)。 阅读联机帮助页还建议在git merge --squash之后不进行任何提交
通过squash合并,您已经创建了一个提交,该提交具有但实际上不是合并的作用。
也就是说,工作树具有您期望的修改,但是元数据却没有:至关重要的是,提交没有两个父项(一个在master上,一个在alt上),因此后续合并可以' t找出最后一个共同祖先。
squash的有用用途
将完全完成的功能分支合并到master。我将在压缩的提交中累积任何有用的信息,但是特别是不希望此功能的增量开发历史污染master提交时间轴。
将几个独立的功能(或来自不同开发人员的贡献)合并到同一集成分支中,而又不保留其增量历史。我可以将它们重新组合在一起,然后使用rebase -i压缩它们的提交,但这更容易
squash的无用用法
您希望保留历史记录和祖先元数据完整的任何合并,例如您希望重复递归合并正确进行的任何时间,特别是OP尝试执行的操作。
squash并不是一个很好的默认值,这就是为什么它不是默认值的原因。
-
--squash选项似乎毫无用处。
-
但是说真的,--squash的意义是什么?如果您从master获得更改,但不知道它,则以后的合并将再次获得相同的更改,复制第一次调用合并时从主服务器获取的内容,不是吗?
-
仅仅因为squash不能满足OP的要求,并不意味着它没有任何用处。如果您从已完成的功能分支一次性完成合并回到master,并且从不希望再次使用该功能分支(并且对保留该功能的增量开发历史感兴趣),则非常好
-
我不您可能会认为功能分支已经完成,但是总会有一个小错误或需要一个小的修复程序。我不明白的是,你为什么不想要历史?承载历史的合并节点是否在以任何方式伤害任何人?
-
如果您不喜欢它,请不要使用它。我已经看到了很多功能分支,但我希望减少对真实更改的干扰。变基是一种方法(将数十个微小的提交压缩成一个值得一读)。请注意,我不在乎其他人是否出于考古目的保留其旧功能分支,但将它们吸入共享的master时间轴中并不会给我带来任何好处。
-
我想说的是,最好使git的历史与您的操作的历史相同。如果合并,请让git也知道,否则将来您或git都会感到困惑。由于相同的原因(重写历史记录),我也不喜欢git rebase。
-
是的,我想我不会全都使用它。无论如何,您的回答很有趣,我学到了一些东西:)
-
一旦进入这种状态(已经被压制了),恢复正常的正确方法是什么?
-
理想情况下,停止处理其祖先/合并元数据已被破坏的分支,并基于压缩的提交(或之后)来处理新的分支。
-
谁问为什么不愿意保留每个功能分支的完整提交历史,谁可能从来没有与20个以上活跃的开发人员一起进行回购工作。如果您尝试在该提交历史记录中找到某些内容,则可能要花一些时间。如果您使用票证编号前缀对每个功能都进行一次提交,则更容易理解更改。
-
为什么到底会有多少开发人员推动他们在每个功能分支上进行的每个本地更改?您可以将每个完整的写入/测试/查看/重构复合体压缩为单个提交,然后再压入第一位。他们可以居住在本地(以及在您的评论/ CI /请求系统中),直到可以共享为止。