我们使用数据传输对象（DTO）来确保使用TypeScript跨多个服务的一致接口。
我们目前正在使用git子树，以确保每个存储库都具有最新的DTO依赖关系。这些DTO每隔半更改一次。
最具挑战性的部分是，对于大多数开发人员而言，子树提取/子树推送不在传统的git流程之外。
问题：人们发现什么样的流程模式可以很好地确保每个相关存储库子树在每次推送/拉取时都是最新的？发布提交挂钩？ CI脚本？等等？
#1 楼
GIT挂钩可以工作，但是麻烦的是，当开发人员提取工作区时，它们不会自动安装。这意味着它们可能最终会被正确安装/使用。不可靠。CI脚本也可以正常工作，但是它是反应性的，仅表示出了点问题，在大多数情况下，人类仍然需要找出罪魁祸首（这可能是由不正确的DTO子树引起的）或其他方法）并解决问题。
如果您希望您的开发人员正确提取其子树-为他们提供脚本化包装器即可-只需将精力放在该脚本中即可，使用和健壮/良好地工作，以便有效地简化开发人员的工作流程。如果您能够做到这一点（大多数），开发人员将看到好处并会使用它。
对于推送方面-您需要考虑到推送错误会发生（即使例如，如果不是所有开发人员都在使用上述脚本）。每个人都会犯错误。
我个人比较喜欢防止开发人员直接将其更改推入集成分支，从而阻止可能的错误影响集成分支。
我本来应该所有候选更改（即，推入单独的分支或作为差异）都通过强制性集中式预提交验证系统进行了汇总。当然，通过适当的git子树实现自动化，使该自动化管理变得可靠。如果更改符合质量检查条件，则仅由该系统自动将更改提交/合并到集成分支中。
这种方法适用于任何可能引起回归的错误，而不仅是不正确的DTO子树。这种方法的一个示例是OpenStack上基于Gerrit的开发。
评论
为什么要使用DTO？您使用哪种编程语言？您能举例说明这样的DTO吗？
martinfowler.com/eaaCatalog/dataTransferObject.html
我不知道什么是DTO，但是我建议您，如果您要开发人员将子树视为只读克隆以外的其他东西，则可能会带来麻烦。如果开发人员经常需要直接在子树中编辑文件，或者需要使用git子模块更新以外的其他方式更新文件，人们可能会发现它们很难使用。
@larsks我认为您可以将此评论作为答案。