Idea principal

El estado actual de un repositorio dice lo que el producto hace hoy, y nada más. Un Product Manager que lee allí que un límite de exportación está fijado en cincuenta líneas obtiene el comportamiento, no su motivo: el código no guarda ninguna huella de que se probaron doscientas y luego se abandonaron por una cuestión de tiempos de respuesta.

Esa huella existe, sin embargo, un nivel más abajo. Los commits, las pull requests y las merge requests forman una capa temporal del mismo repositorio: dicen cómo se llegó al estado actual. Una discusión de revisión de código contiene la objeción de un desarrollador, la restricción técnica que forzó una desviación respecto a la petición inicial, el compromiso aceptado, la corrección hecha tres días después de la entrega porque había aparecido un caso límite.

La distinción útil no está, pues, entre el código y los documentos, sino entre dos lecturas del mismo repositorio. El estado responde a las preguntas de comportamiento: qué regla se aplica, dónde está el límite. El historial responde a las preguntas de motivo: por qué ese valor, por qué esa negativa, por qué ese comportamiento cambió entre marzo y junio. Son dos fuentes distintas que se consultan de forma diferente, y confundirlas lleva a buscar en el estado lo que nunca estuvo allí.

Por qué es importante

Esto recupera una parte de lo que creíamos perdido al designar el código como fuente de verdad. La objeción habitual —"el código dice qué, nunca por qué"— vale para su estado, no para su historia; parte del razonamiento de producto se escribió, simplemente no donde lo buscamos.

También cambia lo que esperamos de una revisión de código. Los comentarios de una merge request dejan de ser una conversación desechable entre dos desarrolladores: son el único lugar donde el arbitraje real quedó registrado en el momento en que se tomaba, sin pasar por un documento redactado a posteriori.

Matices y límites

El historial solo habla si alguien lo ha hecho hablar. Un repositorio cuyos mensajes de commit dicen "fix" y cuyas merge requests se fusionan sin un solo comentario no lleva ninguna intención: la capa existe y está vacía.

La localización también engaña. Las discusiones más ricas viven en la forja —GitHub, GitLab— y no en el repositorio clonado; una reescritura del historial aplastando los commits se lleva por delante lo que allí se había inscrito.

Por último, una intención recuperada tiene fecha. La razón de una decisión tomada hace tres años explica esa decisión; no justifica la regla actual, que ha podido reescribirse desde entonces por un motivo completamente distinto, sin que nada conecte los dos momentos.

Preguntas abiertas

• ¿En qué se reconoce que una discusión de merge request merece ser promovida a decisión de producto escrita, en lugar de dejarla donde quedó registrada?