Git: flujo de trabajo ágil que admite modificaciones en las interfaces existentes

Tengo una pregunta sobre cómo usar Git de manera eficiente (o cualquier VCS, supongo) cuando estoy en el process de hacer modificaciones al código existente, particularmente las interfaces ya utilizadas.

En nuestro proyecto, que consiste en un equipo de siete, estamos teniendo dos twigs permanentes, maestra y dev . Además, contamos con sucursales de características, correcciones, etc., muy similares a esta metodología . Sin embargo, tenemos un problema, un problema que he tenido antes: ¿cómo hace uno, sin la menor molestia posible, hacer cambios en las interfaces que está siendo utilizado por el código que se trabaja en otras twigs? Para ilustrar, tenemos esto:

dev -> feat1 - Modified Interface.code due to architectural changes. - Modified Class.code due to the interface changing. feat2 - Modified Class.code due to changes in requirements or new features/fixes being introduced. 

Como puede ver, la twig feat1 modificó una interfaz y, por lo tanto, tuvo que modificar otro código con dependencies a los cambios. Esto es obviamente para mantener el código libre de errores cuando se fusiona la twig de nuevo en dev al finalizar la function, manteniendo una versión integrada de trabajo del software.

El problema es que el código que depende de la interfaz modificada también se modifica en otra twig para implementar las características / historias necesarias. Volver a fusionar esta function en dev más probablemente sea un process doloroso, por lo que me pregunto cómo proceder en estas situaciones.

En el proyecto real, tenemos un cambio arquitectónico en uno de nuestros cornetworkingores, y ese cambio tendrá repercusiones en todas las sucursales de características existentes que utilizan el intermediario, ya que se ramificaron de desarrollo antes de que decidiéramos realizar el cambio. Si bien podríamos esperar con la integración de los cambios del intermediario hasta que las otras características se fusionen de nuevo en dev, eso bloquearía partes del desarrollo y nos impediría entregar todas las historias para el final de la iteración.