Git como registro notarial del desarrollo de software
Git no es simplemente una herramienta para programadores: es un sistema de registro que documenta, de forma automática y continua, cada modificación que se realiza en un proyecto de software. Cada vez que un desarrollador guarda un cambio (un commit), Git almacena cinco elementos fundamentales: el autor (nombre y correo electrónico configurados), la fecha y hora exactas del cambio, un hash SHA-1 que actúa como huella digital única, la referencia al commit anterior (el commit «padre») y el mensaje descriptivo que explica qué se modificó.
Lo que hace de Git una fuente de evidencia excepcional es que estos registros se generan de forma automática, sin intervención adicional del desarrollador. No hace falta «activar» ningún log ni configurar un sistema de auditoría: el propio flujo de trabajo normal produce un rastro completo y cronológicamente ordenado de toda la actividad del proyecto.
Además, la estructura de Git es criptográficamente encadenada. Cada commit incluye el hash del commit anterior en su propio cálculo de hash. Esto significa que alterar un commit antiguo cambiaría su hash, lo que a su vez invalidaría el hash de todos los commits posteriores. Es un principio similar al de la tecnología blockchain: la cadena de hashes hace que cualquier modificación retroactiva sea detectable.
Para un perito informático judicial, un repositorio Git bien conservado es una de las fuentes de evidencia más ricas y fiables que existen en el ámbito del desarrollo de software.
Qué puede demostrar un análisis forense de un repositorio Git
Un repositorio Git contiene información suficiente para responder a las preguntas clave en la mayoría de disputas sobre software. El perito puede extraer y documentar los siguientes elementos:
Autoría línea por línea. El comando git blame permite saber quién escribió cada línea de código de cada archivo del proyecto, cuándo lo hizo y en qué commit se introdujo. Esto es determinante en disputas de propiedad intelectual donde ambas partes reclaman la autoría de un módulo o funcionalidad. El perito documenta qué porcentaje del código corresponde a cada contribuidor y en qué periodo temporal.
Cronología de cambios. El historial de commits establece una línea temporal precisa de cuándo se implementó cada funcionalidad, cuándo se corrigieron errores y cuándo se realizaron las entregas. Si el contrato establece hitos de entrega, los commits, tags y merges a la rama principal permiten verificar si se cumplieron los plazos pactados.
Historial de entregas. Los tags (etiquetas de versión), los releases y los merges a la rama principal (main o master) documentan qué versiones se entregaron al cliente y qué contenía cada una. Si el proveedor afirma que entregó la funcionalidad X en la versión 2.0, el perito puede verificar si el código de esa funcionalidad existe realmente en el tag correspondiente.
Ramas eliminadas y force pushes. El reflog de Git registra operaciones que no aparecen en el historial «oficial»: ramas que fueron eliminadas, commits que fueron descartados y reescrituras del historial mediante force push. Estas operaciones son especialmente relevantes cuando una parte intenta ocultar actividad.
Diferencia entre lo comiteado y lo desplegado. Cruzando el historial de Git con los registros de los sistemas de despliegue (CI/CD, logs de servidor, registros de la plataforma de hosting), el perito puede determinar si lo que se subió al repositorio coincide con lo que realmente se puso en producción. Discrepancias aquí pueden indicar desde entregas incompletas hasta modificaciones no autorizadas en el entorno de producción.
Adquisición forense del repositorio: cómo se hace correctamente
La adquisición forense de un repositorio Git no es simplemente «descargar el código». Un clon estándar (git clone) obtiene el historial de commits pero omite información relevante para un peritaje: el reflog, las referencias internas, las ramas remotas no seguidas y ciertos metadatos de configuración del servidor.
El procedimiento correcto comienza con un clone mirror (git clone --mirror), que replica la totalidad del repositorio tal como existe en el servidor remoto, incluyendo todas las ramas, tags y referencias internas. A continuación, el perito calcula el hash SHA-256 del directorio .git completo para documentar la integridad de la copia. Este hash se incluye en el acta de adquisición junto con la fecha, hora y la URL del repositorio remoto.
Se debe documentar también la URL remota del repositorio y las credenciales utilizadas para el acceso (usuario, método de autenticación: SSH, token, OAuth), sin incluir las contraseñas en texto plano. Si existe reflog en el servidor (en plataformas autoalojadas como GitLab on-premise), se adquiere por separado, ya que el clone mirror no lo incluye.
La diferencia entre un clon regular y una adquisición forense es análoga a la diferencia entre fotocopiar un documento y hacer una imagen certificada: el resultado visible puede ser similar, pero la garantía de integridad y completitud es radicalmente distinta. El procedimiento debe seguir los mismos principios de cadena de custodia digital que cualquier otra evidencia informática.
Si el repositorio se aloja en plataformas como GitHub o GitLab, es recomendable complementar la adquisición con una exportación de los metadatos de la plataforma: pull requests, issues, comentarios en revisiones de código, registros de acceso y configuración de permisos. Estos datos no forman parte del repositorio Git en sí, pero aportan contexto valioso sobre el proceso de desarrollo.
Manipulación de historial Git: cómo detectarla
Git permite reescribir su propio historial. Esta es una característica legítima de la herramienta (usada habitualmente para limpiar ramas antes de integrarlas), pero en el contexto de un litigio, la reescritura puede constituir destrucción o alteración de evidencia. Las operaciones más habituales de manipulación son:
Force push (git push --force): sobrescribe el historial del repositorio remoto, sustituyendo commits existentes por otros nuevos. Los commits originales dejan de ser accesibles desde el historial «oficial», aunque pueden sobrevivir en clones locales de otros desarrolladores o en los logs de sistemas de CI/CD.
Rebase interactivo: permite reorganizar, fusionar, editar o eliminar commits. Un rebase genera commits con nuevos hashes SHA, rompiendo la cadena criptográfica original. Si alguien hace un rebase sobre una rama que ya fue compartida, está reescribiendo historia que otros pueden tener registrada en su versión original.
Amend de commits: el comando git commit --amend sustituye el último commit por uno nuevo. Cambia el hash y puede alterar fecha, autor y contenido. Es la forma más sencilla de manipulación y la más difícil de detectar si se hace antes de compartir el commit.
Filter-branch y BFG Repo-Cleaner: herramientas diseñadas para reescribir el historial completo del repositorio, eliminando archivos, cambiando autores o modificando mensajes de commit en masa. Se usan legítimamente para eliminar credenciales filtradas accidentalmente, pero también pueden emplearse para borrar rastros de actividad.
Un perito detecta estas manipulaciones mediante varias técnicas: análisis del reflog (que registra las operaciones originales en cada clon local), comparación entre distintos clones del mismo repositorio (si dos desarrolladores tienen clones con historiales diferentes, alguien reescribió), y cruce con logs de CI/CD que referencian los hashes originales de los commits que ya no existen en el repositorio actual. La discrepancia entre el hash registrado por Jenkins o GitHub Actions y el hash actual del commit es prueba directa de reescritura.
Presentar evidencia de Git ante un juez no técnico
Uno de los mayores retos del peritaje de repositorios Git no es el análisis técnico, sino la comunicación de los resultados a un tribunal compuesto por profesionales del derecho sin formación en desarrollo de software. La terminología de Git —commits, branches, merges, rebases, force pushes— resulta opaca para quien no la conoce, y un informe que no se entiende es un informe que no convence.
La estrategia que mejor resultado da en un procedimiento judicial es traducir los conceptos técnicos a analogías comprensibles. Los commits son «entradas de diario»: cada una registra qué se cambió, quién lo hizo y cuándo, como las anotaciones de un cuaderno de obra en construcción. Las ramas (branches) son «líneas de trabajo paralelas»: dos equipos trabajan simultáneamente en aspectos distintos del proyecto sin interferirse. Los merges son «puntos de integración»: el momento en que esas líneas paralelas se unen en el producto final. Los tags son «hitos de entrega»: una versión concreta del software que se entregó al cliente en una fecha determinada.
Además de las analogías, las líneas temporales visuales son herramientas de comunicación especialmente eficaces. Un gráfico que muestre en un eje horizontal las fechas y en un eje vertical las contribuciones de cada desarrollador permite al juez ver de un vistazo quién trabajó en qué periodo y cómo se relacionan los hitos del proyecto con los plazos contractuales.
El informe pericial debe incluir un resumen ejecutivo en lenguaje no técnico, seguido del análisis detallado con la evidencia completa. En la ratificación en sala, el perito debe estar preparado para responder preguntas como «¿puede alguien haber falsificado estas fechas?» o «¿cómo sabemos que fue esa persona y no otra?» con respuestas claras y verificables.
Casos prácticos: qué se ha resuelto con peritaje Git
Los siguientes casos, anonimizados, ilustran situaciones reales donde el análisis forense de un repositorio Git fue determinante para la resolución del conflicto:
Disputa por autoría de una funcionalidad clave
Dos empresas colaboraban en un proyecto SaaS. Al separarse, ambas reclamaban la autoría de un módulo de procesamiento de pagos. El análisis de git blame sobre los archivos del módulo demostró que el 94% de las líneas de código habían sido escritas por desarrolladores de una de las empresas, durante un periodo en el que existía un contrato de cesión vigente. El informe pericial, acompañado de una cronología visual de los commits, permitió resolver la disputa antes de llegar a juicio.
Desarrollador que eliminó una rama antes de irse
Un programador senior, antes de dejar la empresa, eliminó la rama de desarrollo donde se encontraba una funcionalidad en la que había trabajado durante meses. La empresa sospechaba que había copiado el código para usarlo en su nueva posición. Mediante el análisis del reflog del servidor y de los clones locales de otros compañeros, el perito recuperó los commits eliminados y pudo reconstruir el contenido íntegro de la rama. Se verificó además que el mismo código aparecía en un repositorio de la empresa competidora, con commits posteriores que intentaban disimular el origen reescribiendo mensajes y cambiando nombres de variables.
Empresa de outsourcing reutilizando código de cliente
Una empresa descubrió que su proveedor de desarrollo estaba reutilizando módulos de su software propietario en proyectos para otros clientes. La comparación de los repositorios de ambos proyectos reveló funciones idénticas, incluyendo comentarios internos y errores tipográficos en las variables, con una coincidencia que descartaba el desarrollo independiente. La cronología de los commits demostró que el código del cliente era anterior, estableciendo la dirección de la copia. El peritaje en conflictos de software documentó cada archivo copiado con sus fechas de origen y destino.
¿Necesitas analizar un repositorio Git para un caso judicial?
Autoría, cronología, entregas, manipulación de historial: analizo repositorios Git con rigor forense y presento los resultados de forma que un juez pueda valorarlos.
Preguntas frecuentes
Sí, técnicamente es posible. Git permite configurar manualmente las variables GIT_AUTHOR_DATE y GIT_COMMITTER_DATE para establecer cualquier fecha. Sin embargo, esta manipulación deja rastros: el reflog registra cuándo se creó realmente el commit en ese repositorio local, los servidores de CI/CD conservan logs con timestamps independientes y, si el commit se subió a una plataforma como GitHub o GitLab, la API registra la fecha de push real. Un perito cruza estas fuentes para detectar discrepancias entre la fecha declarada en el commit y la fecha real de creación.
El borrado de un repositorio en la plataforma no siempre es definitivo. Si existían forks, clones locales en equipos de desarrolladores, mirrors en sistemas de CI/CD o copias de seguridad del servidor, puede recuperarse el historial completo o parcial. Además, GitHub conserva datos internos durante un periodo tras el borrado. En un procedimiento judicial, se puede solicitar al juez que requiera a la plataforma la recuperación o la entrega de metadatos asociados. La destrucción deliberada de un repositorio cuando ya existe conflicto puede generar presunciones desfavorables para quien lo borró.
No. Un repositorio privado requiere autorización del titular o un requerimiento judicial. El perito puede solicitar al juez que ordene la exhibición del repositorio como parte de la prueba pericial. Si una de las partes tiene acceso legítimo (por ejemplo, era colaborador del proyecto), puede proporcionar un clon al perito siguiendo la cadena de custodia. El acceso no autorizado constituiría un delito y, además, la evidencia obtenida sería inadmisible.
Un rebase reescribe el historial de commits, generando nuevos hashes SHA y, potencialmente, alterando fechas y orden de los cambios. Esto no invalida automáticamente la prueba, pero el perito debe documentar que el historial fue reescrito, cuándo se hizo el rebase (visible en el reflog) y qué impacto tiene sobre las conclusiones. Si existe un clon anterior al rebase o logs de CI/CD que referencien los commits originales, se puede reconstruir el historial real y demostrar la reescritura.
El git log muestra el historial "oficial" de commits: lo que el repositorio quiere que veas. El git reflog muestra todos los movimientos del puntero HEAD en el repositorio local, incluyendo commits que fueron eliminados por un rebase, un reset --hard o un force push. Para el perito, el reflog es una fuente de evidencia crítica porque revela operaciones que alguien intentó ocultar. La limitación es que el reflog es local a cada clon y tiene una caducidad configurable (por defecto, 90 días).
Sí, aunque requiere trabajo adicional. El nombre y email en los commits de Git son configurables y no se verifican automáticamente. Pero el perito puede cruzar otras fuentes: la IP desde la que se hizo el push (logs del servidor Git), el usuario autenticado en la plataforma (GitHub/GitLab registran quién hizo el push, no solo quién aparece en el commit), las claves SSH o tokens de acceso utilizados, y la correlación temporal con la actividad conocida del sospechoso.
Depende del tamaño del repositorio, el número de contribuidores y la complejidad de las cuestiones planteadas. Un caso sencillo (verificar autoría de un módulo en un repositorio con historial limpio) puede resolverse en 2-3 días. Un caso complejo (reconstruir cronología tras múltiples rebases, comparar varios repositorios, detectar plagio) puede requerir 1-3 semanas. La elaboración del informe pericial y su adaptación para un juez no técnico añade tiempo adicional.
Sí. El perito puede comparar el código fuente de ambos repositorios línea a línea, analizar la estructura y nomenclatura utilizadas, buscar "huellas" como comentarios, errores tipográficos o patrones de código idénticos, y cruzar la cronología de los commits para determinar qué repositorio contiene el código original y cuál la copia. Herramientas de detección de similitud de código y el análisis del historial de Git (quién escribió primero cada función) complementan el análisis manual.