何时应该使用主干开发而非多分支

我当前正在参与一个项目的早期开发，此时项目的架构都是不稳定的，并且我可能需要协同多个同事去完善某一个功能。在这种情况下，我试图进行常规的、Git 多分支的开发——也就是当我试图新增一个功能，我会创建一个 feature 分支。最后发现非常不便，这也使我意识到：

并不是所有的情况，都应该使用在大多数情况下被推崇的多分支开发，而我正面临着这种情况。

在项目的早期，目录结构、核心类、API 定义经常会有改动。如果使用多分支开发，在合并分支时很容易遭遇 Git 报告大量冲突的情况，导致合并过程变得异常棘手。

而使用单一分支并配合合理的提交频率，则可以让团队成员尽量保持在同一个架构版本上工作。

核心的痛点在于：大家都在开发，且工作相互关联。

使用主干开发 (Trunk Based Development)，能有效解决这个痛点，非常适合早期架构不稳定的情况。

我查看了资料，发现除了我这种情况，还有其他非常推荐、甚至是只能使用主干开发的情况：

如果团队将所有代码（前端、后端、工具库等）都存放在同一个 Git 仓库中，主干开发几乎是唯一的可行解。

这种情况下的痛点在于：如果你在 feature 分支中开发，而其他人修改了底层的公共对象，你很有可能是在错误（或过时）的基础上进行了大量开发。这与我面临的痛点相似，本质上都是因为多分支隔离导致无法及时跟进最新的代码变更。

这种情况实际上与我最初面临的情境类似：项目早期开发阶段，本质上可以看作是无时无刻都在进行重构。

采用主干开发，可以做到每次 commit 非常少量的代码（小步提交），从而确保功能的更新、回滚和修复都能迅速完成。