我们最近从 SVN 迁移到了 git。我们使用主要的“发布”分支（主），以及开发人员正在处理的每个功能的功能分支。在TeamCity中，我们为每个功能分支都有一个项目，当然还有一个主项目。
当我们使用 SVN 时，每当有人从 master 合并到他的特性分支或反之亦然时，TeamCity 将合并视为一次提交。现在，使用 git，每次合并都会导致 TeamCity 显示此合并附带的所有提交。
这会导致一些问题，例如当某人从 master 合并到他的功能分支时，现在他的 TeamCity 项目由于该合并而显示“283 个未决更改”，如果构建失败，这些更改的作者将被通知，就好像他们做了一样功能分支上的这些更改。
有没有办法告诉 TeamCity 将 git 合并视为单一提交？
我们可以使用压缩合并来解决它，但这是我们真正想要避免的事情。
我很确定这与我们几天前遇到的问题相同，反之亦然。我们将一个 dev 分支合并到 master 中，这导致 TC 尝试构建作为合并一部分的每个签入。显然不是我们想要的。
要修复它，请Trigger build on each check-in在Build Trigger.
您可以从源分支获取完整的更改历史记录，但 TeamCity 只会使用最新的合并代码构建目标分支。如果构建失败，合并应该是唯一通知的。
这是一个很长的镜头，您可能已经尝试过，但是将per check-in触发选项应用于 是否可行Include several check-ins in build if they are from the same committer？这可能足以诱使 TC 将提交构建为单个包。
这是两种可能的解决方案：
解决此问题的一种方法（尽管可能非常尴尬，取决于您的情况）是在构建配置级别通知用户，而不是通知谁提交/合并。为不同的主题分支创建单独的构建配置，并为每个构建配置配置通知，以便只通知主题分支的“所有者”。
不太确定，但值得一试：您可以为每个主题分支配置通知，例如通过分支路径上的通配符模式。这应该可以通过使用分支名称属性 teamcity.build.vcs.branch.<my_vcs_name>的 DYI自定义通知插件来实现。
TeamCity 电子邮件通知的一个特定限制（应该很容易支持）是您不能通过组合构建配置和“忽略不是由我的更改引起的失败”来过滤通知。然后至少您可以为主分支配置构建，以便通知提交者，并仅为主题分支项目创建特定设置。