为什么从一个分支到主分支的后续合并最终会发生冲突？答案

【问题标题】：Why do subsequent merges from one branch to master end up in conflicts?为什么从一个分支到主分支的后续合并最终会发生冲突？
【发布时间】：2023-03-09 23:25:01
【问题描述】：

我想要：

在develop 上工作并在那里进行所有更改（或在合并到develop 的其他功能分支中）
在我想释放时将 develop 合并到 master 中（自上次执行此操作以来压缩所有提交）

但是当我将 develop 合并到 master 时，我遇到了合并冲突。

这是我的工作流程的一个小例子，它重现了我遇到的问题：

创建空仓库，克隆它

bicou@dikkenek:/tmp$ mkdir repo.git
bicou@dikkenek:/tmp$ cd repo.git/
bicou@dikkenek:/tmp/repo.git$ git init --bare
Initialized empty Git repository in /tmp/repo.git/
bicou@dikkenek:/tmp/repo.git$ cd /tmp
bicou@dikkenek:/tmp$ git clone repo.git repo
Cloning into 'repo'...
warning: You appear to have cloned an empty repository.
done.
bicou@dikkenek:/tmp$ cd repo

现在向 master 提交一些代码：

bicou@dikkenek:/tmp/repo$ echo 'blah blah blah' > readme
bicou@dikkenek:/tmp/repo$ echo 'version: 1' >manifest
bicou@dikkenek:/tmp/repo$ git add manifest readme 
bicou@dikkenek:/tmp/repo$ git commit -m "initial commit"
[master (root-commit) 5c7f827] initial commit
 2 files changed, 2 insertions(+)
 create mode 100644 manifest
 create mode 100644 readme

现在分支develop

bicou@dikkenek:/tmp/repo$ git checkout -b develop
Switched to a new branch 'develop'
bicou@dikkenek:/tmp/repo$ echo "testing" >work
bicou@dikkenek:/tmp/repo$ git add work
bicou@dikkenek:/tmp/repo$ git commit -m "working on work"
[develop f22b31b] working on work
 1 file changed, 1 insertion(+)
 create mode 100644 work
bicou@dikkenek:/tmp/repo$ echo "more work" >>work 
bicou@dikkenek:/tmp/repo$ git commit -am "still work"
[develop 6a8981f] still work
 1 file changed, 1 insertion(+)

这是对已在 master 上跟踪的文件的修改：

bicou@dikkenek:/tmp/repo$ sed -i 's/version: 1/version: 2/' manifest 
bicou@dikkenek:/tmp/repo$ git commit -am "version bump"
[develop de2866b] version bump
 1 file changed, 1 insertion(+), 1 deletion(-)

回到master，合并develop中的所有提交并压缩它们：

bicou@dikkenek:/tmp/repo$ git checkout master
Switched to branch 'master'
bicou@dikkenek:/tmp/repo$ git merge develop --squash 
Updating 5c7f827..de2866b
Fast-forward
Squash commit -- not updating HEAD
 manifest | 2 +-
 work     | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)
 create mode 100644 work
bicou@dikkenek:/tmp/repo$ git commit 
[master 04528f9] Squashed commit of the following:     version bump     still work     working on work
 2 files changed, 3 insertions(+), 1 deletion(-)
 create mode 100644 work

现在重新开始工作：

bicou@dikkenek:/tmp/repo$ git checkout develop 
Switched to branch 'develop'
bicou@dikkenek:/tmp/repo$ echo "still working" >>work 
bicou@dikkenek:/tmp/repo$ git commit -am "continued work"
[develop 81e3d08] continued work
 1 file changed, 1 insertion(+)

那么在我看来应该没问题但会破坏事情的变化：

bicou@dikkenek:/tmp/repo$ sed -i 's/version: 2/version: 3/' manifest 
bicou@dikkenek:/tmp/repo$ git commit -am "version bump"
[develop 83b77fb] version bump
 1 file changed, 1 insertion(+), 1 deletion(-)

回到master，期待一个没有发生的愚蠢合并：

bicou@dikkenek:/tmp/repo$ git checkout master 
Switched to branch 'master'
bicou@dikkenek:/tmp/repo$ git merge develop --squash 
Auto-merging work
CONFLICT (add/add): Merge conflict in work
Auto-merging manifest
CONFLICT (content): Merge conflict in manifest
Squash commit -- not updating HEAD
Automatic merge failed; fix conflicts and then commit the result.

这是一个冲突：

bicou@dikkenek:/tmp/repo$ cat manifest 
<<<<<<< HEAD
version: 2
=======
version: 3
>>>>>>> develop

所以我的问题/反思：

为什么不快进？
我知道我可以强制与 git merge develop --squash -s recursive -Xtheirs 合并，但我是否需要这样做每次我会将develop 合并到master 中？
我的工作流程有问题吗？
将develop 合并到master 后，我是否应该将master 合并回develop？这不是无限循环吗？
为什么第 5 步中的合并有效而第 8 步中的合并无效？这只是 1 -> 2 (OK) 然后 2 -> 3 (KO) 的变化。我应该没问题！
是否有任何合并策略或任何其他选项可以让我得到我想要的？

额外问题：
squashing 时，git 足以在提交 squash 之前编译所有提交消息。但这包含了自分支分叉以来的所有提交消息（例如上面的第 3 步）。
如何只获取自我上次合并 develop 到 master 以来的提交消息？（例如上面的第 5 步） )

注意：merging using a temporary branch 可以在没有冲突的情况下进行合并，但这并不意味着我没有将所有提交消息压缩为一个。

【问题讨论】：

在第 1 步？实际上我不知道，我通常将 repo 存储在其他地方并通过 SSH 克隆，所以我复制了它。但这不是重点。
This may not seem like a duplicate，我的答案很长，但是你应该阅读整个答案然后考虑是否要继续使用壁球，这不是合并。如果您确实想继续使用 squash，那么您可能希望在每个分支被压扁后放弃它。（扔掉旧的，开始新的，甚至可能同名。）
我已经读过了。但是您评论的结尾暗示了这里的问题：如果每次都从 master 干净地重新分支 develop ，我无法连续多次合并 develop 到 master （压缩提交）。（例如，扔掉旧的并开始一个新的，可能同名）。这告诉我出了点问题，这可能是我的工作流程。 :(
不同之处在于，通过适当的合并提交，git 已经记录了您已经合并了这些更改。如果您正在执行 rebase/squash，而是再次应用相同的更改，现在的不同之处在于您已经在 master 中进行了一些更改，因此您会遇到冲突。简而言之，如果您在 rebase/squash 时不打算放弃分支，请不要 rebase/squash 它。
git `merge --squash` does not add "Merge" header to commit的可能重复

标签： git merge merge-conflict-resolution

【解决方案1】：

正如 torek 和 Lasse 在 cmets 中指出的那样，我做了一些错误的假设：

合并时压缩提交不会创建合并提交。这是我猜的主要问题
在合并期间压缩提交时，之后的预期行为是转储提供提交的分支
当并行处理两个分支并定期将一个分支合并到另一个分支时，应创建提交合并

上面的 cmets 中链接的所有信息都有很大帮助，但 this answer 特别适合我的需要。

我想要的是：

并行工作
合并，创建合并提交（因此没有 squash）
在合并提交中包含所有提交消息（而不是愚蠢的Merge branch xxx）：这是使用prepare-commit-message 挂钩解决的

这是一个虚拟回购的结果，正是我想要的工作流程：

bicou@dikkenek:/tmp/repo$ git log --decorate --oneline --graph
*   182fb11 (HEAD, master) Merge details:
|\  
| * 1cdba95 (develop) version bump v4
| * d12d9ce work on v4 another feature
| * 70bb9f6 work on v4
* |   ee715de Merge details:
|\ \  
| |/  
| * 965356c work again on v3
| * 3f12856 work on dev v3
* |   37649d4 Merge branch 'develop'
|\ \  
| |/  
| * 0ef71dd work work on v2
| * 84b5069 continued work on v2
* |   5522eae Merge branch 'develop'
|\ \  
| |/  
| * b3e545e work again on develop
| * 0960273 work on develop 1
|/  
* 6515de5 initial commit

master 中的每次提交：

是一个合并提交
commit message 是自上次合并以来develop 中的commit message 列表，我可以在vim 中运行git commit 时自定义它。

（Merge branch 'develop' 提交是在我使用钩子之前创建的，Merge details 提交是使用简单的 git m develop + git commit 钩子创建的，这很棒）

如果 torek 或 Lasse 想发布他们自己的答案并从中获得荣誉，他们绝对应该这样做！

【讨论】：