¿Qué es Git y por qué debería usar el control de versiones si es desarrollador?

Como desarrolladores web, muchas veces tendemos a trabajar en sitios de desarrollo local y luego cargamos todo cuando terminamos. Esto está bien cuando solo eres tú y los cambios son pequeños, pero cuando estás tratando con más de una persona trabajando en algo, o en un proyecto grande con muchos componentes complicados, eso simplemente no es factible. Ahí es cuando pasamos a algo llamado control de versiones.

Hoy hablaré sobre un software de control de versiones de código abierto llamado Git. Esto permite que más de una persona trabaje de manera segura en el mismo proyecto sin interferir entre sí, pero es mucho más que eso también.

Por qué usar el software de control de versiones?

En primer lugar, el nombre debe revelarlo. El software de control de versiones le permite tener “versiones” de un proyecto, que muestra los cambios que se realizaron en el código a lo largo del tiempo, y le permite retroceder si es necesario y deshacer esos cambios. Esta capacidad por sí sola, de poder comparar dos versiones o revertir los cambios, la hace bastante valiosa cuando se trabaja en proyectos más grandes..

Probablemente incluso haya hecho esto usted mismo en algún momento, guardando copias de un proyecto en diferentes puntos para tener una copia de seguridad. En un sistema de control de versiones, solo se guardarían los cambios, un archivo de parche que podría aplicarse a una versión, para que sea igual a la versión siguiente. Con un desarrollador, esto es suficiente.

Pero, ¿qué pasa si tienes más de un desarrollador trabajando en un proyecto? Es entonces cuando surge la idea de un servidor de control de versiones centralizado. Estos han sido el estándar durante mucho tiempo, por lo que todas las versiones se almacenan en un servidor central, y los desarrolladores individuales finalizan la compra y cargan los cambios en este servidor. Si alguna vez has mirado el historial de edición de una página de Wikipedia, tendrás una buena idea de cómo funciona esto en un escenario del mundo real:

Los beneficios de un sistema como este es que múltiples desarrolladores pueden hacer cambios, y cada cambio puede atribuirse a un desarrollador específico. En el lado negativo, el hecho de que todo esté almacenado en una base de datos remota significa que no se pueden hacer cambios cuando ese servidor se cae; y si se pierde la base de datos central, cada cliente solo tiene la versión actual de lo que sea que estén trabajando.

Eso nos lleva a Git, y otros llamados sistemas distribuidos de control de versiones. En estos sistemas, los clientes no solo revisan la versión actual de los archivos y trabajan a partir de ellos, sino que reflejan el historial completo de la versión. Cada desarrollador siempre tiene una copia completa de todo. Todavía se utiliza un servidor central, pero si ocurriera lo peor, entonces todo se puede restaurar desde cualquiera de los clientes que tienen las últimas versiones.

Git funciona específicamente tomando “instantáneas” de archivos; si los archivos permanecen sin cambios en una versión en particular, simplemente se vincula a los archivos anteriores, esto mantiene todo rápido y ajustado.

También podría interesarle saber que Git se usa para administrar y desarrollar el núcleo de Linux: el bloque de construcción base sobre el cual se construyen todas las distribuciones de Linux.

¿Qué es Github??

Aunque puede ejecutar su propio servidor Git localmente, Github es un servidor remoto, una comunidad de desarrolladores y una interfaz web gráfica para administrar su proyecto Git. Es de uso gratuito para hasta 5 repositorios públicos, es decir, cuando cualquiera puede ver o bifurcar su código, con planes de bajo costo para proyectos privados. Le sugiero que se registre para obtener una cuenta gratuita para que pueda comenzar a jugar con sus propios proyectos o bifurcar a alguien más..

Bifurcación y ramificación

Estos son conceptos básicos para la experiencia Git, así que tomemos un momento para explicar la diferencia..

Probablemente has escuchado el trabajo “tenedor” cuando se trata de distribuciones de linux. Si está familiarizado con la aplicación de centro multimedia Plex, sabrá que originalmente era una bifurcación de la fuente abierta similar Xbox Media Center Aeon Nox 3.5: tema hermoso y personalizable para XBMC Aeon Nox 3.5: tema hermoso y personalizable para XBMC Set instale su centro de medios exactamente como lo desea. Aeon Nox 3.5 es la versión más reciente de lo que quizás sea el mejor tema para XBMC, y es una combinación rara: hermosa ... Esto simplemente significa que en algún momento en el pasado, algunos desarrolladores tomaron el código de XBMC y decidieron seguir su propio camino; que se convirtió en Plex.

Por supuesto, esto está totalmente permitido cuando el proyecto es de código abierto: puede tomar el código, hacer lo que quiera con él. Con Git, si cree que sus cambios son lo suficientemente buenos como para volver a “dominar” proyecto, puedes hacer un “solicitud de extracción” al autor, pidiéndole que regrese sus cambios a su proyecto original. Esto le permite tener cientos de miles de desarrolladores trabajando en un proyecto en cualquier momento, ninguno de los cuales necesariamente debe ser aprobado para el acceso al código: simplemente copian el código, hacen cambios y solicitan que se vuelva al maestro. Por supuesto, depende del propietario del proyecto original si deciden aceptar sus cambios o no..

La ramificación es algo realizado internamente en un proyecto por los desarrolladores autorizados. Le permite separar fácilmente problemas o características específicas, y trabajar en ellos sin romper los archivos maestros. Una vez que esté satisfecho de que su sucursal se ha ocupado del problema, lo fusiona nuevamente en el maestro. En cualquier momento, puede haber tantas ramas como desee; No interfieren entre sí. También puede combinar cambios entre ramas sin tocar el maestro.

Aquí hay un gran diagrama de un flujo de trabajo de ejemplo de Vincent Driessen:

La próxima vez, veremos cómo configurar un ejemplo de Git que funcione y hacer cambios de código dentro de las ramas. El control de versiones es un gran tema. Solo he dado una breve descripción general aquí, pero como desarrollador que está acostumbrado a hacer cambios y deshacerlos si no funcionan, todo el concepto me ha sorprendido. Espero que también lo haga el suyo..

¿Eres un desarrollador experimentado con experiencia en Git? ¿Estás comenzando y crees que te gustaría intentarlo? Suena apagado en los comentarios!