¿Hay justificación para dejar los marcadores de conflicto en el código registrado?

Esto está claramente mal. El trabajo del sistema de control de versiones es realizar un seguimiento de los cambios, y es el trabajo de las herramientas de diferencias mostrar qué ha cambiado como resultado de la combinación. Debería haber un comentario en el registro de confirmación, y tal vez en el código, que explique qué se cambió y por qué. Sin embargo, en mi humilde opinión, dejar los marcadores de conflicto como comentarios es lo mismo que dejar un código muerto alrededor.

He tenido un problema similar con algunos códigos, ya sea por comentarlos (lo que de alguna manera es similar a tu caso) o por ser movido a un método que no se llama en ningún lado. Cuando se les preguntó por qué las personas hacen esto, la respuesta fue que se sienten un poco más seguros cuando todavía tienen algunos bloques de código. El argumento contrario más obvio es que es un trabajo VCS y no el suyo. Sin embargo, también hay otro aspecto. Cuando alguien más está leyendo el código mientras aprende o hace cambios, es probable que ese comentario lo desvíe del tema. Definitivamente lo leerá y tal vez dedique algo de tiempo a comprender por qué está aquí y qué correlación posible tiene con su trabajo actual. Como un marcador de conflicto es un signo de un conflicto, que ya se ha resuelto, esto es sin duda una pérdida de tiempo.

Creo que los comentarios deben referirse al código que está allí, no al código que ha estado allí en el pasado, ni a los eventos que sucedieron al código en el pasado, ni al código que existió en un universo paralelo (otra rama ) en el pasado. Dejar los marcadores en la forma en que lo hizo el miembro de su equipo crea al menos tres problemas:

1. El código original probablemente era algo como blah blah null , y el informe del error decía "No se puede usar nulo allí, usar esto o aquello, o lo que sea". Así que dos personas corrigieron el error de forma independiente y, cuando se fusionaron las correcciones, surgió el conflicto. Ahora el comentario no documenta cuál fue el problema ni lo que reparó la solución, sino solo que hubo dos soluciones diferentes en algún momento en el pasado. Eso no es de mucha ayuda. Un comentario como //blah blah needs a non-null argument al menos daría una indicación de lo que cambió (e incluso esa información está más fácilmente disponible en el comentario de confirmación del sistema de control de versiones).
2. Es posible que la versión fusionada no parezca una de las líneas originales. Tal vez si quieres que bla bla tome esto y aquello, la forma correcta es blah blah (this,that) o incluso algo más complicado. En ese caso, dejar el mensaje de conflicto como un comentario seguramente confundirá a cualquiera que intente leer el código más adelante.
3. La mayoría de los sistemas de control de versiones le dan acceso al historial del proyecto. Por ejemplo, puedo hacer clic derecho en un archivo en eclipse (con svn), decir "Mostrar historial ..." y luego decir "Comparar actual con ..." y obtener una ventana de diferencias que resalta las diferencias. Esa información es la forma es más fácil de asimilar si los puntos destacados de diff contienen las diferencias reales, y no los comentarios que las rodean. Cada cambio no funcional en el código hace que sea más difícil leerlo.

  

¿Qué tan molestos son los marcadores de conflicto en el código registrado?

Muy molesto.