确定章鱼合并期间冲突中的哪些分支

Kal*_*erg 8 git version-control merge process release-management

我们正在尝试使用git octopus合并来构建一个流程来整合常规版本的许多主题分支.当发生冲突时,似乎没有输出哪些分支发生冲突.在章鱼合并之后,有没有人知道确定冲突来自哪些分支的方法?

谢谢,-Kal

Von*_*onC 7

git merge手册页提到:

章鱼

这解决了具有两个以上磁头的情况,但拒绝执行需要手动解决的复杂合并.它主要用于将主题分支头捆绑在一起.这是拉动或合并多个分支时的默认合并策略.

这个线程确实说明:

章鱼策略不能进行需要手动解决的合并.或者说医生说.尝试与4 2 5合并后,Git告诉你:

Trying simple merge with 7ff9b5bd514cb600bac935ebd40eae366bba7d19
Trying simple merge with 6872cd350154743d59cb4d313cbdb122ac43e537
Simple merge did not work, trying automatic merge.
Auto-merging file.txt
ERROR: content conflict in file.txt
fatal: merge program failed
Automated merge did not work.
Should not be doing an Octopus.
Merge with strategy octopus failed.
Run Code Online (Sandbox Code Playgroud)

也就是说,它完全中止了合并.如果你"解决"它并提交它只是你做的提交.

  • @Kallin:我会在目标分支上一一执行合并,解决冲突,然后一旦所有合并完成(并在需要时解决),我会将 --soft HEAD 重置为初始提交,写`.git/MERGE_HEAD` 中的所有分支 SHA1(刺激章鱼合并)并提交。有关该技术的实际示例,请参阅 http://stackoverflow.com/questions/5203535/practical-uses-of-git-reset-soft/5203843#5203843。 (2认同)
  • 我可以看到非常有用的一件事是,如果章鱼合并可以被告知,当遇到冲突时,*跳过*合并,然后继续下一个.这将提供一种方法,定性地捆绑所有开发人员的工作,并告诉你需要修复哪些(或让他们修复).将"邪恶"拆分为单独的单一合并也可能是好的. (2认同)