我们的团队使用 Git 工作流程,我们从“master”分支到功能分支(例如“F-1234”),完成我们的工作,然后将我们的功能分支合并回“集成”。
合并到集成时偶尔会出现合并冲突。我们希望在我们的功能分支中解决这些冲突,但我们不允许将“集成”合并回我们的功能分支。我们必须找到另一个功能分支(例如“F-4567”)并合并该分支。
我的问题:如何回顾集成并找出导致问题的其他功能分支?
我们的团队使用 Git 工作流程,我们从“master”分支到功能分支(例如“F-1234”),完成我们的工作,然后将我们的功能分支合并回“集成”。
合并到集成时偶尔会出现合并冲突。我们希望在我们的功能分支中解决这些冲突,但我们不允许将“集成”合并回我们的功能分支。我们必须找到另一个功能分支(例如“F-4567”)并合并该分支。
我的问题:如何回顾集成并找出导致问题的其他功能分支?
告诉“他们”,“他们的”过程使开发人员的工作变得比实际需要的更难。
同时,对于有冲突的给定文件(例如foobar.c
),您可以从以下内容开始来识别潜在的冲突来源:
git log --all --merges integration -- foobar.c
这应该显示在集成分支上引入了对该文件的更改的所有合并提交。希望在常见情况下,只有一个分支修改了该文件,但在某些情况下您可能需要检查多个分支。
有一个名为“git-imerge”的工具,基本上,它在两个分支之间执行所有可能的合并组合。最后,您将只保留您想要的样式(变基或合并等)。
该工具的优点之一是它可以准确地识别出哪两个提交冲突,并让您在出现问题的最小提交对上解决问题。然后,您可以向前传播分辨率。这是一个非常漂亮的工具(当它工作时!我确实遇到了一些问题)。