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

Considere los marcadores de conflicto. es decir:

<<<<<<< branch
blah blah this
=======
blah blah that
>>>>>>> HEAD

En el caso particular que me motivó a publicar esta pregunta, el miembro del equipo responsable acababa de completar una fusión de aguas arriba a nuestra sucursal, y en algunos casos los había dejado, como comentarios, como una especie de documentación sobre lo que acababa de ser resuelto. Lo dejó en un estado compilado, las pruebas pasan, por lo que no es tan malo como parece.

Sin embargo, instintivamente, realmente me opuse a esto, sin embargo, como los demonios se defienden de mí mismo, puedo ver por qué podría haberlo hecho:

• porque destaca a otros desarrolladores de equipos lo que ha cambiado como resultado de la fusión.
• porque aquellos que son más expertos en las piezas de código particulares pueden abordar las preocupaciones ilustradas por los comentarios para que no tenga que adivinar.
• debido a que la fusión ascendente es un dolor correcto y puede ser difícil justificar el tiempo para resolver todo bien y por completo, por lo que es necesario un aviso FIXME semi-completo, entonces, ¿por qué no usar el conflicto original como un comentario para documentar esto?

Mi objeción fue instintiva, pero me gustaría poder justificarla racionalmente, o ver mi posición más sabiamente. ¿Alguien puede darme algunos ejemplos o incluso experiencias en las que la gente haya tenido un mal momento con alguien más haciendo esto y / o las razones por las cuales es una mala práctica (o puede jugar al abogado del diablo y apoyarlo).

Mi propia preocupación inmediata era que claramente hubiera sido molesto si hubiera editado uno de los archivos en cuestión, hubiera sacado los cambios, hubiera conflictos reales, pero también hubiera sacado los comentarios. Entonces habría tenido un archivo muy desordenado de hecho. Afortunadamente eso no sucedió.

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 diff mostrar lo que ha cambiado como resultado de la fusión. Debería haber un comentario en el registro de confirmación, y tal vez en el código, explicando qué fue cambiado 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.

He tenido un problema similar con algún código ya sea comentado (que de alguna manera es similar a su caso) o movido a un método que en realidad no se llama a ninguna parte. Cuando se les preguntó por qué las personas hacen esto, la respuesta fue que se sienten un poco más seguras cuando todavía tienen algún bloque de código. El contraargumento más obvio es que es un trabajo de 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 este comentario lo desvíe. Definitivamente lo leerá y tal vez pase un tiempo para entender por qué está aquí y qué posible correlación 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 deberían referirse al código que está allí, no al código que ha estado allí en el pasado, ni a los eventos que le sucedieron en el pasado, ni al código que existía en un universo paralelo (otra rama) en el pasado. Dejar los marcadores como lo hizo el miembro de su equipo crea al menos tres problemas:

1. El código original probablemente era algo así blah blah null, y el informe de error decía "No se puede usar nulo allí, usar esto o aquello, o lo que sea". Entonces, dos personas solucionaron el error de forma independiente y cuando se fusionaron las soluciones, surgió el conflicto. Ahora el comentario no documenta cuál fue el problema ni cuál fue la solución, sino solo que hubo dos soluciones diferentes en algún momento en el pasado. Eso no es muy útil. Un comentario como //blah blah needs a non-null argumental 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 ni siquiera 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. es más fácil de asimilar si los aspectos más destacados de diff contienen las diferencias reales, y no los comentarios a su alrededor. Cada bit de cambio no funcional en el código hace que ese diff sea más difícil de leer.

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

Muy molesto