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

Anuncio

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 lidiando con más de uno persona trabajando en algo, o en un proyecto grande con muchos componentes complicados, eso simplemente no 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 también es mucho más que eso.

¿Por qué usar el software de control de versiones?

En primer lugar, el nombre debería revelarlo. El software de control de versiones le permite tener "versiones" de un proyecto, que muestran 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 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 se podría aplicar 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, mediante el cual todas las versiones se almacenan en un servidor central, y los desarrolladores individuales revisan y cargan los cambios en este servidor. Si alguna vez has visto 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 todo el historial de versiones. Cada desarrollador siempre tiene una copia completa de todo. Todavía se utiliza un servidor central, pero en el peor de los casos, todo se puede restaurar desde cualquiera de los clientes que tienen las últimas versiones.

Git funciona específicamente tomando "instantáneas" de los 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 ágil.

También podría interesarle saber que Git se utiliza para administrar y desarrollar el núcleo de linux kernel - 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 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 de Git, así que tomemos un momento para explicar la diferencia.

Probablemente haya escuchado el trabajo "fork" 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 código abierto similar Xbox Media Center Aeon Nox 3.5: tema hermoso y personalizable para XBMCConfigure 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 ... Lee mas . 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; eso 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 al proyecto "maestro", usted puede hacer una "solicitud de extracción" al autor, pidiéndole que retire sus cambios a su estado original proyecto. Esto le permite tener cientos de miles de desarrolladores trabajando en un proyecto en cualquier momento, ninguno de los cuales debe necesariamente se aprueba para el acceso al código: solo copian el código, hacen cambios y solicitan que se vuelva a colocar en el 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 por 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 sucursales. El control de versiones es un gran tema. Aquí solo he dado una breve descripción general, 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!