El equipo de sistemas en GitHub trabaja para resolver errores complejos y cuellos de botella de rendimiento en los niveles más bajos de nuestra infraestructura. En los últimos dos años hemos llevado a cabo un importante proyecto para mejorar el rendimiento de las operaciones de red de Git (como clones o descargas) para los repositorios que alberga. Hace dos años, el clonado un gran repositorio desde cualquier servidor Git hacía que tuvieras que esperar a que empezase la descarga mientras el servidor indicaba “contando objetos”. Hoy en día […].

Hace 15 meses lanzamos GitLab 7.0. Desde entonces, para GitLab 8.0 hemos mejorado el rendimiento, hemos hecho que funcione con LDAP en la versión empresarial y hemos hecho posible que se pueda trabajar con archivos grandes en Git. Además de eso, también hemos mejorado la interfaz gráfica y hemos integrado GitLab CI.

Este ensayo explica cómo funciona Git y se enfoca en la infraestructura en forma de grafo con la que Git trabaja y la manera en que las propiedades del mismo dictan su comportamiento.

GitFlow es probablemente el modelo más popular de trabajo con Git hoy en día. Parece estar en todas partes. Sin duda, para mí personalmente está en todas partes —prácticamente todos los proyectos de mi trabajo actual lo usan y a menudo son los propios clientes los que lo eligen—. Recuerdo leer el artículo original GitFlow tiempo atrás cuando salió por primera vez y no quedé para nada impresionado. Pensé que era una solución extraña y sobredimensionada a un problema inexistente.

Cuando se trabaja con Git, lo más común a la hora de trabajar con commits es usar su hash SHA-1. El problema es que no tendemos a trabajar con hashes sino con fechas, por ejemplo, queremos saber qué cambios se han hecho ayer, la semana pasada, o entre el lunes y el martes. Por suerte, Git es capaz de entender este tipo de expresiones y de mostrar lo que pedimos.