git合并压缩和反复冲突 [英] git merge squash and recurring conflicts

问题描述

我有一个包含 master 和 alt 分支的git仓库。 alt 分支包含 master 代码的修改版本，我试图合并来自 master的更改 to alt 是这样的：

  git合并--squash master 
  

合并结果有冲突：



 自动合并myproject / foo / bar 
 CONFLICT（内容）：在myproject / foo / bar中合并冲突
壁球提交 - 不更新HEAD 
自动合并失败;修复冲突，然后提交结果。 
  

在我解决冲突和提交更改后，一切看起来都很顺利，但是当我运行 git merge --squash master 再次（没有对任何分支做任何改变）我会得到相同的冲突错误。

为什么？我错过了什么？

解决方案

通过 squash 已经创建了一个提交，其效果是，但不是真正的合并。

也就是说，工作树有你期望的修改，但是元数据不：关键是，提交没有两个父母（一个在 master 和一个在 alt 上）因此后续的合并不能找出最后一个共同的祖先。

---

squash的有用用途

1. 将完全完成功能分支合并到 master 。我将积累任何有用的信息到压扁的提交中，但不希望此功能的增量开发历史会污染 master 提交时间表。


2. 将多个独立功能（或来自不同开发人员的功能）合并到同一个集成分支上，同样不会保留其增量历史记录。我可以将它们重新组合在一起，然后使用 rebase -i 压缩它们的提交，但这很容易





---





壁球的无用用途



任何想要保留历史和血统元数据的合并，例如任何时候您希望重复递归合并正确工作，特别是
良好的默认值，这就是为什么它不是默认值。



I have a git repository with master and alt branches. alt branch contains modified version of master code, and i am trying to merge changes from master to alt like this:

git merge --squash master

Merge results in conflict:

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.

After I resolve conflicts and commit changes everything seems fine, but when i run git merge --squash master again (without doing any changes on any branches) i will get same conflict error.

Why is that? What did i miss?

解决方案

By squashing the merge, you've created a commit which has the effect of, but is not really, a merge.

That is, the working tree has the modifications you'd expect, but the metadata doesn't: crucially, the commit doesn't have two parents (one on master and one on alt) and therefore subsequent merges can't figure out the last common ancestor.

---

Useful uses of squash

1. merging a completely finished feature branch onto master. I'll accumulate any useful information into the squashed commit, but specifically don't want this feature's incremental development history polluting the master commit timeline.
2. merging several independent features (or contributions from different developers) onto the same integration branch, again without preserving their incremental histories. I could rebase them all together, and then use rebase -i to squash their commits, but this is easier

---

Useless uses of squash

Any merge where you want to keep the history and ancestry metadata intact, such as any time you want repeated recursive merges to work correctly, specifically what the OP is trying to do.

squashjust isn't really a good default, which is why it isn't the default.

这篇关于git合并压缩和反复冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！