如何解决如何解决Monorepo中的合并冲突？
假定以下情况：
- monorepo在单独的文件夹中包含两个工件，例如前端和后端
- 前端开发人员无法解决后端代码中的合并冲突
- 后端开发人员无法解决前端代码中的合并冲突
- 基于功能分支的工作流，前端和后端开发人员在相同功能分支上并行工作
当对功能分支的更改（由单独的开发人员创建）在后端和前端代码中发生冲突时，就会出现此问题。单个开发人员（基于上述假设）无法自行进行更新合并。
解决跨越前端和后端代码的合并冲突的最佳实践是什么？如果基于垂直功能分支的工作流是根本问题，那么您在坚持前三个假设的情况下如何改进此设置？
解决方法
这是一种将合并冲突解决方案分为两个不同部分的直截了当的技术方法：
-
从
上的更改master分支创建两个伪提交，一个仅包含backend上的更改，另一个仅包含frontend -
有两个开发人员将每个分支合并到
feature -
将
feature合并到master
- 将更改分为两部分：
# starting situation :
*--X--*--*--Z <- master # X is the fork point
\ # Z is the tip of branch master
\
*--*--*--T <- feature # T is the tip of branch feature
运行以下命令：
# from master,create a phony branch for backend :
$ git checkout -b backend master
$ git checkout X -- frontend/ # reset the content of 'frontend/' to its state in commit X
$ git commit
# similarly for fontend :
$ git checkout -b frontend master
$ git checkout X -- backend/
$ git commit
您现在拥有：
*--X--*--*--Z------
\ \ \
\ B F # B: tip of backend,F: tip of frontend
\
*--*--*--T
- 合并
feature中的两个部分：
$ git checkout feature
# have one developper fix conflicts on :
$ git merge backend
# and a second one on :
$ git merge frontend
注意：合并可以以任何顺序进行。
现在的情况是：
*--X--*--*--Z------
\ \ \
\ B F
\ \ \
*--*--*--T--*--M <- feature
- 您现在可以将
feature合并到master
对于您的工作流程，如果应该分别处理backend和frontend上的工作，则需要制定一些规则，以在开发人员管理的分支机构中反映出来。
@ bk2204在他的回答中给出了实现此目标的一些指导：将后端工作与前端工作分开，并尽快合并。
,有两种解决此问题的典型方法：
- 经常合并更改并使用功能标记系统，以便可以集成新更改而不会激活它们。这样一来，各个开发人员就可以在功能的不同方面进行工作并逐步进行合并，因此，功能分支仅限于能够单独解决冲突的单个或少数开发人员。
- 使功能分支作为单个开发人员的功能分支的组合运行，并迫使开发人员各自基于自己的更改，解决冲突，然后将这些单个开发人员分支重新集成到功能分支中。
- 让各个领域的开发人员结伴在一起，共同解决冲突。
我个人经历过其中的第一和最后一步，我更喜欢前者，但是根据您的工作流程，可能无法实现。例如，如果您有多个开发线（例如，维护和开发分支），则第一个解决方案不能解决您所有的问题，但是可以减少它们。
通常，您可以设计的工作流程越多，以至于开发人员必须解决的冲突与他们自己正在处理的代码相关，您就越成功。即使同一区域中的其他开发人员能够在那里解决冲突，但使用一段代码的开发人员也可以更快地执行此操作，并且更有可能正确地执行此操作，因为他们目前在使用在那儿工作。
一种可能的技术方法是使用git imerge并将增量产品存储在某处作为参考，然后让每个开发人员恢复已隐匿的状态。尽管可能，但建议不要这样做。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。