Después de esta lección, serás capaz de:
- Entender qué es un Distributed Version Control System (DVCS).
- Entender cómo funciona un DVCS.
- Entender porqué un DVCS es muy importante en desarrollo.
- Entender qué es una Plataforma de Alojamiento de Código.
- Entender qué es Git.
- Entender qué es GitHub.
- Entender la relación entre Git y Guthub.
Un DVCS o Sistema de Control de Versiones es un sistema que graba los cambios en un archivo o un conjunto de archivos en el tiempo para que tu puedas retomarlo en una versión específica más adelante.
Estos sistemas te permiten tener diferentes versiones de cada archivo que compone tu proyecto, así puedes recuperar versiones anteriores en caso de que cometas un error (es muy común).
El DVCS trabaja normalmente con una plataforma que aloja código, donde tu equipo puede guardar el código del proyecto para compartirlo con el resto del equipo.
En programación, la combinación de un DVCS con una plataforma que aloja códgo ayudan a que puedas rabajar con tu equipo. Esta es la herramienta más poderosa que usarás para reunir el código creado por todos los miembros del equipo.
Cuándo dos miembros del equipo trabajan en el mismo archivo, el DVCS va a ayudarlos combinar su código y elegir qué código se quedará cuando ambos editaron el mismo código.
Tener diferentes versiones del mismo archivo te da un gran poder sobre tu código. Como se dijo anteriormente, si falla algo en la última versión del código, podrá recuperar la versión correcta anterior de su código.
También es muy útil cuando combinas código de diferentes desarrolladores en un solo archivo, o incluso archivos diferentes en un proyecto (no te preocupes si no entiendes esto ahora, lo aprenderás en profundidad más adelante).
Otra buena característica que te ofrece es la posibilidad de ver quién ha escrito cada código. Permite mostrar cuántas horas has estado trabajando, por supuesto, pero es más divertido usarlo para descubrir quién ha estropeado el código.
Asignemos cada componente de la ecuación en su posición, y luego veamos un ejemplo para comprender el panorama general de cómo funcionan ambos elementos juntos.
Git es un DVCS gratuito y abierto diseñado para manejar proyectos de programación de computadoras con velocidad y eficiencia. Es fácil de aprender y tiene un rendimiento muy alto.
Git corre a nivel local. ¿Qué significa eso? Te permite usar el Sistema de control de versiones en tu computadora. Significa que tendrás en tu propia computadora un Sistema de control de versiones, para recuperar todo el código, ver qué cambios ha realizado, etc.
Comprenderás por qué necesitas usar Git en tu computadora en un minuto. Antes de entender eso, debes aprender qué es GitHub.
GitHub es una plataforma de alojamiento de código para control de revisión y colaboración. Te permite a ti y a otros trabajar juntos en proyectos desde cualquier lugar. Con github, puedes hacer muchas cosas para colaborar en un proyecto de código:
- Controla diferentes versiones del código.
- Creación de ramas.
- Forkear repositorios.
- Hacer Pull Requests.
- Ver proyectos de otras personas y aprender cómo codifican.
- Comentar el código de otras personas.
Todos estos conceptos se tratarán más adelante en el pre-work, ahora mismo solo tienes que entender lo básico: GitHub es una plataforma de alojamiento de código para el control de revisiones y la colaboración.
En este punto, es posible que hayas notado cómo se relacionan git y github. Git te permite controlar tu código en tu máquina local, mientras que GitHub te permite colaborar con tus compañeros de equipo haciendo pull y push del código en el que has estado trabajando.
Puede entender que git es tu sistema de control de versiones en local, mientras que GitHub es tu sistema de control de versiones del equipo. Veamos un ejemplo para comprender mejor cómo funciona en un entorno de dos desarrolladores.
Si necesitas un mejor ejemplo para entenderlo, piensa en el correo electrónico y GMail. El correo electrónico es un protocolo que se usa para enviar / recibir correos electrónicos entre los usuarios, mientras que GMail es una interfaz visual que usas para enviar / recibir correos electrónicos.
El correo electrónico existe independientemente de GMail, todos pueden instalarlo en su servidor, pero GMail agrega características adicionales y proporciona el servicio.
Lo mismo ocurre con Git y GitHub. Git es un servicio que se puedes instalar en un servidor, mientras que GitHub es un servicio adicional que te permite usar las versiones de control de Git y agrega la característica adicional de las colaboraciones del equipo, implementando una interfaz visual para git.
En el cuadro a continuación, puedes ver un escenario típico en el que dos desarrolladores diferentes trabajan en un archivo de forma colaborativa. Aquí hay dos desarrolladores involucrados, Mary que creará el archivo y lo enviará a GitHub, y Bob que extraerá este archivo, hará algunos cambios y lo enviará de regreso a GitHub para compartir estos cambios con Mary:
Sin entrar en cómo exactamente se ejecuta el proceso, y cuáles son los comandos, echemos un vistazo a una perspectiva de alto nivel de cómo dos desarrolladores pueden colaborar en un proyecto.
Creación de archivos
Antes que nada, Mary crea un archivo, llamado archivo.txt. Una vez que se crea el archivo, agrega algo de contenido. Supongamos que agrega ¡Hola, mundo! Y guarda los cambios. En este punto, ni Git ni GitHub han estado involucrados en el flujo de trabajo.
Agrega el archivo a Git
Una vez que el archivo está listo para compartir, Mary debe hacer un commit con Git. Aprenderás cómo agregar y enviar archivos a Git en futuras lecciones del pre-work. El punto más importante aquí es que una vez que el archivo se agrega y se compromete en Git, Git genera la primera versión del archivo.
En este paso del proceso, tenemos un archivo.txt en nuestra máquina local y tenemos la v1 de este archivo almacenada en el Git de Mary localmente, en su máquina.
Push/Pull en GitHub
Una vez que Mary tenga el archivo en su repositorio local de Git, está listo para enviar este archivo a GitHub. Nuevamente, aprenderás cómo enviar un archivo a GitHub más adelante en el pre-work. Al hacer esto, Mary le permite a su compañero de equipo, Bob, la oportunidad de obtener este archivo y hacer algunos cambios.
Para hacerlo, Bob tiene que traer los cambios de GitHub(pull) a su propia computadora. Cuando Bob hace pull de los cambios de GitHub, suceden dos cosas:
- El
archivo.txtse agrega al repositorio de Bob, en su máquina local. - Automáticamente, aparece una versión del archivo en el proyecto de Bob, también localmente.
Actualizar el archivo
Una vez que Bob tiene el archivo en su computadora, cambia el contenido y agrega lo siguiente:
Hola, Mundo!
Hola, Mary! Gracias por compartir este archivo! :)
De nuevo, como lo hizo Mary anteriormente, Bob tiene que agregar y enviar los archivos a su repositorio de Git antes de poder enviarlos a GitHub. Cuando Bob confirma los cambios de archivos en su repositorio de Git, Git crea la versión 2 del archivo.
Estado actual
En esta etapa, antes de que Bob suva los cambios a GitHub(push), Mary tiene la versión 1 del archivo, mientras que Bob tiene la versión 2 del mismo archivo.
Una vez que Bob haya enviado los archivos a su repositorio de Git, puede enviarlos a GitHub haciendo push de todos los cambios.
Obteniendo los últimos cambios
Finalmente, Mary puede hacer pull del archivo de GitHub a su computadora. De nuevo, esto significa que la versión del archivo se agregará a su repositorio local de Git, y el archivo en su proyecto se actualizará automáticamente.
Controlando las versiones
Ahora, ambos desarrolladores tienen ambas versiones del archivo en sus repositorios Git y la última versión del archivo en su carpeta de proyectos. Eso significa que pueden consultar la versión 1 o 2 cuando lo deseen, para ver quién hizo qué cambios y qué cambios se incluyen en cada versión.
En esta lección, has aprendido qué es un Sistema de control de versiones distribuidas. También has visto lo que son Git y GitHub, y has entendido la gran imagen de cómo dos desarrolladores pueden colaborar utilizando Git y GitHub como equipo.
