如何解决 monorepo 中的合并冲突?

How to resolve merge conflicts in a monorepo?

假设以下情况:

当后端和前端代码中功能分支的更改(由不同的开发人员创建)发生冲突时,就会出现问题。单个开发人员(给定上述假设)无法独自进行更新合并。

解决跨越前端 后端代码的合并冲突的最佳做法是什么?如果基于垂直特征分支的工作流是根本问题,您将如何在坚持前三个假设的同时改进此设置?

这个问题有几种典型的解决方法:

  • 经常合并更改并使用 feature-flagging 系统,以便可以在不激活的情况下集成新的更改。这使各个开发人员可以处理功能的不同方面并逐步合并它,因此功能分支仅限于能够单独解决冲突的单个或少数开发人员。
  • 使功能分支作为各个开发人员的功能分支的组合运行,并强制每个开发人员重新设置他们自己的更改,解决冲突,然后 re-integrate 那些单独的开发人员分支回到功能分支。
  • 让每个领域的开发人员结对解决冲突。

我亲身经历过第一个和最后一个,我更喜欢前者,但根据您的工作流程,这可能是不可能的。例如,如果你有多条开发线(例如,一个维护和一个开发分支),第一个解决方案不会解决你所有的问题,但它可能会减少它们。

一般来说,您设计的工作流程越多,使开发人员必须解决的冲突与他们自己正在处理的代码相关,您就越成功。即使同一领域的其他开发人员有能力 解决那里的冲突,处理一段代码的开发人员将能够更快地完成它并且更有可能正确地完成它,因为他们我目前在那里工作。

一种可能的技术方法是使用 git imerge 并将增量产品存储在某处作为引用,然后让每个开发人员恢复存储状态。不过,这可能会很棘手,虽然可能,但不推荐这样做。

这是一种将合并冲突解决方案分为两个不同部分的直截了当的技术方法:

  1. master 分支创建两个伪提交,一个仅包含 backend 上的更改,一个仅包含 frontend[ 上的更改=26=]

  2. 让两个开发人员将每个分支合并到 feature

  3. 合并featuremaster


  1. 将更改一分为二:
# 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
  1. 合并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
  1. 您现在可以将 feature 合并到 master

至于您的工作流程,如果 backendfrontend 上的工作应该分开处理,您需要有一些规则来在您的开发人员管理的分支中反映这一点。

@bk2204 在他的回答中给出了一些方向:将后端工作与前端工作分开,尽快合并。