随着使用Git开发Java，我们经常会遇到不同人员在不同特性分支中更改相同类的问题，这会导致合并冲突。虽然这些问题在某些时候是不可避免的，但我们希望尽早发现这些问题，这样人们就可以谈论和调整。在Git特性分支中发生冲突，如何及早发现它们
我在这里看到两种可能的解决方案：最佳实践（如查看其他人的分支）和工具支持。如果我错过了一些最佳实践，请给我指向一些文档。如果有工具（如果可能发生冲突，则将分支添加到列表中并收到电子邮件），请告诉我。
这与持续集成相似。
您可以拥有任何用于持续集成的构建系统（teamcity，jenkins）尝试每天/每小时合并分支并在未能自动执行时发送电子邮件。
嗯，不完全是。在处理复杂的功能分支时，您会遇到不能编译和/或无法合并的中间状态。不过，你想知道潜在的问题。事实上，这样的“问题通知”在功能分支无法合并的时间越长时越有帮助。 –
一个解决方案可能是rebase您的分支机构频繁。
一旦另一个开发人员将他的分支合并到master（或另一个常见开发分支）中，则可以用master重新绑定当前分支，从而在此刻处理冲突。
另一个好的做法是让短暂的分支机构能够快速查看冲突。
您也可以让开发人员在他们的分支机构开始工作时立即打开合并请求，这样，其他开发人员就可以看到他们是否正在处理相同的文件并预测冲突。
我的观点是，分支机构之间的频繁冲突是由开发团队之间的单元模块化造成的 – Ferrybig
我承认，我们的代码是单片的，模块化程度不高，部分原因是它的遗留问题。重写不是一个选项。但是我们确实有一些分离，特别是在“基础设施”和“特定问题”部分之间。通常，人们必须改变基础设施以在某些方面获得更多精确度/信息。如果两个开发人员在同一个区域并行执行 - dang。 –
你可能应该考虑打破你的功能，以便功能分支只能活一两天。 – alextercete