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.

Hacer un seguimiento de los cambios en una base de datos no es una tarea sencilla. Los esquemas de las bases de datos tienden a ser incompatibles entre diferentes entornos o puede que se pierda alguna pieza importante de los datos al hacer el cambio. Este tipo de eventos suele ser bastante irritante, sobre todo cuando es en producción. Así que, aquí tenéis una lista de buenas prácticas a la hora de tratar con los cambios en bases de datos.

Una de las características más útiles de cualquier sistema de control de versiones es la posibilidad de “deshacer” los errores. En Git, “deshacer” puede significar muchas cosas ligeramente diferentes. Cuando haces un nuevo commit, Git almacena una instantánea del repositorio en ese momento específico en el tiempo; más adelante, se puede usar Git para volver a una versión anterior del proyecto. En esta entrada se verán varios escenarios con sus ejemplos donde es necesario deshacer cosas en un repositorio de Git.

Muchos usuarios han abrazado Git por su flexibilidad como un sistema de control de versiones distribuido, sobre todo gracias a la gestión de ramas. Si bien esta flexibilidad funciona para la mayoría de los casos de uso, algunos no se manejan con tanta elegancia. Uno de estos casos de uso es el uso de Git con repositorios monolíticas grandes o monorepos. Este artículo contesta varias cuestiones relacionadas con monorepos cuando se utiliza Git y ofrece consejos para mitigar los problemas relacionados.

Una pequeña historia acerca de Git, el sistema de control de versiones creado originalmente por Linus Torvalds. [Usar las flechas del teclado para avanzar y/o retroceder]

Si tu propósito para nuevo año era actualizar Git, tenemos buenas noticias. La comunidad de Git acaba de lanzar Git 2.7.0 y a nosotros nos gustaría compartir algunas de sus novedades contigo.

GitHub almacena más de 35 millones de repositorios de Git y más de 30 millones de Gists (pequeños trozos de código) en cientos de servidores. Durante el pasado año, hemos estado construyendo DGit (Distributed Git), un nuevo sistema de almacenamiento distribuido que mejora de forma dramática la disponibilidad, la confiabilidad y el rendimiento del almacenamiento y el servicio de contenidos almacenados con Git.

Mucha gente nos ha hecho preguntas sobre cómo es la infraestructura interna de GitLab.com. Desde Twitter muestran sus dudas para saber cuántos servidores usamos, así que, dado este número de cuestiones, hemos querido ir un poco más allá y ofrecer una mirada a nuestra infraestructura. En esta entrada no sólo encontraréis cuántos servidores usamos, sino también una perspectiva de para qué se usa cada uno de ellos.

Se ha lanzado la versión 2.9 del sistema de control de versiones Git. En esta versión se incluyen tanto corrección de errores como nuevas características, entre las que se incluyen: gestión de submódulos más rápida y flexible; mejora en la visualización de diffs; chequeo de commits al hacer rebase; mejora en la presentación de los mensajes de log; etc.

Git tiene un fuerte compromiso con la compatibilidad hacia atrás, por eso muchas características están ocultas en opciones en lugar de puestas como el comportamiento predeterminado. Por suerte, Git soporta alias, por lo que se pueden crear comandos propios para hacer todo tipo de magia con Git, como se muestra en la siguiente lista.

Esto de tener un repositorio en GitHub, o incluso en GitLab, por no decir, en cualquier otro de los servicios que hay disponibles, es algo que ha pasado de ser extraño a estar a la orden del día. No solo se utiliza para el trabajo colaborativo en el desarrollo de software, sino que también se usa para multitud de otras actividades: desde guardar tus archivos de configuración hasta para escribir libros, ya sea solo o de forma colaborativa. Lo cierto es que es posible que guardes información sensible. En este sentido la solución es el cifrado de repositorios Git.

Durante años hemos estado observando y esperando mientras Google desarrollaba gradualmente su sistema operativo Fuchsia desde cero. Ahora ha aparecido evidencia que apunta a que el sistema operativo Fuchsia de Google ya tiene preparada su primera (y segunda) versión disponible, aunque es probable que inicialmente sea sólo para desarrolladores.