La idea de generar este post ayudar a todos aquellos que desean aprender como utilizar Git y **GitHub por lo cual para poder empezar a jugar con estos nuevos juguetes es necesario aprender algunas bases las cuales facilitaran el entendimiento de cómo trabajan.

Actualmente Git y GitHub forman parte importante en el día a día de un desarrollador especialmente cuando se trabaja en un equipo, dichas herramienta son utilizadas mucho en la industria del software, la primera pregunta qué tenemos que hacer es.

🤔 ¿Qué es un sistema de control de versiones?

Es un sistema que controla y organiza todos los cambios realizados en un archivo o conjunto de estos a lo largo del tiempo, de modo que facilita la recuperación de versiones especificas, de una manera mas fácil permite movernos en la linea de tiempo del archivo o conjunto.

Sistema de control de versiones también conocido como VCS del inglés Version Control System.

Este tipo de control es muy común en la industria informática para llevar el control del código fuente desarrollado lo cual da la pauta para los sistemas de control de código.

Sistema de control de versiones también conocido como SCM del inglés Source Code Management.

Fig 1. Ejemplo base de un sistema de control de código.

Como se puede ver en la Fig 1 se muestra el flujo de trabajo de un VCS

1. Se muestra la línea de tiempo del proyecto en el se marcan las fechas donde se generaron los cambios.

2. Se muestra el avance del proyecto conforme a la línea de tiempo.

3. Se muestra la manera en la que se lleva en el control de los cambios, donde se destaca el registro de actividades mediante una breve descripción del cambio y el registro de la actividad realizada.

Para poder llegar a lo que es un sistema de control de versiones como los conocemos hoy en día todo inicio con.

Control de versiones locales

Fig 2. Diagrama del Sistema de control de versiones locales

Como su nombre lo dice las versiones se manejan de manera local y en vez de mantener las versiones como archivos independientes se almacenaban en bases de datos (BullShit😱) por lo que cuando se necesitaba revisar una versión anterior del proyecto se usaba el *VSC *para acceder directamente al archivo, de esta manera solo se tenia una copia del proyecto lo cual elimina la posibilidad de confundir o eliminar versiones.

Hasta este o punto el control de versiones se llevaba en la computadora de cada uno de los desarrolladores por lo que no existía una manera eficiente de compartir código entre ellos.

Control de Versiones Centralizados

Fig 2. Diagrama del Sistema Control de Versiones Centralizados

Este sistema fue una gran evolución ya que proporcionan la facilidad de colaboración de múltiples desarrolladores en un solo proyectó, por lo que los cambios ya no se guardaban de manera local, con esta actualización los cambios se almacenan en un servidor central.

Aunque el avance contra los sistemas de versionado local fue muy grande. los sistemas centralizados trajeron consigo nuevos retos, ¿Cómo trabajaban múltiples usuarios en un mismo archivo al mismo tiempo?, lo cual era muy complejo ya que se presentaba la posibilidad de inhabilitar los cambios de otros, por lo que este tipo de sistema funcionaba muy bien donde el proyecto no sufre cambios de manera constante constantemente.

Hasta este punto el dios digital nos odiaba 🖕🏼.

Control de Versiones Distribuidos

Fig 3. Diagrama del Sistema Control de Versiones Distribuidos

En este punto bajo el diosito digital y dijo ya no existirá un solo repositorio centralizado por lo que cada miembro del equipo contara con una copia local de todo el proyecto, de esta manera se contara con una red distribuida de repositorios.

Al no contar con un repositorio centralizado, cada desarrollador puede trabajar a su propio ritmo y almacenar sus cambios de manera local por lo que al mezclar lo cambios de otros los conflictos que se presentan son menores, como cada desarrollador tiene una copia completa del proyecto los riesgos de caída del servidor, un repositorio dañado.

Si lo se la teoría es muy aburrida en ocaciones pero puede ser buena cuando queremos conseguir un entendimiento completo de lo que esta pasando.

🤯 Git y GitHub diferentes

Fig 4. Git y GitHub no es lo mismo

Si como lo acabas de leer son dos cosas completamente diferentes por lo que es importante entender las principales diferencias de estos.

Git es utilizado para trabajar de manera local pero cuando se desea colaborar con otras personas de manera remota, utilizar una interfaz web o publicar tus proyectos se utiliza Github es un sistema que guarda nuestro proyectó y los cambios de cada una de las versiones, Github es tan popular que es la red social del código(Como FaceBook o Twitter pero para programadores), es una hoja de vida (CV) que de muestra lo que sabes.

👨🏻‍💻 Jugando con la consola

Después de un poco de teoría creo que ya es bueno iniciar con le uso de comandos básicos en Git🙌 por lo que para iniciar seguiremos los pasos siguientes.

Paso 1: Descargar Git e Instalarlo, lo podemos descargar directamente de su sitio web(Descargar Git), para el caso de Windows y Mac se cuenta con un asistente de instalación por lo que no se tiene mayor problema para la instalación, para el caso de Linux se puede utilizar apt-get install git.

Paso 2: Para el caso de Linux y Mac podemos abrir la terminal propia del sistema, en el caso de Windows utilizaremos el GitBash(nos permite usar comandos de linux 🤯) que se instalo al realizar la instalación de git.

Paso 3: Al encontrarnos en la consola iniciaremos escribiremos los siguientes comandos.

Fig 5. Creando la estructura de carpetas

Paso 4: Procederemos a configurar nuestro nombre y email de manera global(para todos los repositorios) con los comandos.

Fig 6. Configurando nuestro nombre y e-mail

🔖 Nota: Si necesitaremos que cada repositorio tenga un nombre o correo diferente solo tenemos que cambiar — global por — local.

Paso 5: Para poder iniciar el uso de Git vasta con que ejecutemos el siguiente comando.

Fig 7. Iniciando nuestro primer repositorio

🔖 Nota: Se creara una carpeta oculta llamada .git esta es la que llevara el control de cambios.

Paso 6: Agregamos algo de contenido nuevo a nuestro repositorio esto lo lograremos utilizando los comandos.

Fig 8. Creamos un archivo

Paso 7: Para ver el estado del repositorio, o lo que es lo mismo un informe de los cambios realizados a archivos/directorios, vasta con que ejecutemos el siguiente comando.

Fig 8. Revisando el estado de nuestros cambios.

El comando anterior nos mostrara la información siguiente.
Rama en la que nos encontramos: Git promueve el uso de ramas, y en este punto nos indica en qué rama estamos.

Cambios que serán publicados: Los archivos que hemos modificado y serán enviados.

Cambios que no serán publicados: Si hemos hecho cambios a en un archivo pero no serán enviados.

Archivos a los que no se les esta haciendo seguimiento (untracked): Son los archivos que se encuentran presentes en el directorio, pero que aun no han sido añadidos a git para hacerles seguimiento. Inicialmente todos los archivos se encuentran de esta manera.

Paso 8: Procederemos a agregar nuestros cambios los cuales pasaran al apartado de los cambios que podrán ser enviados, , vasta con que ejecutemos el siguiente comando.

Fig 9. Preparando cambios que serán enviados.

🔖Nota: git add tiene variantes como
git add . o git add -A : Prepara todos los archivos que serán enviados.
git add ./[nombre]: Prepara solo el archivo que se le indique.

Paso 9: Mandaremos los cambios realizados a nuestro repositorio, vasta con que ejecutemos el siguiente comando.

Fig 10. Creando el primer commit.

🔖 Nota: el comando commit tiene un parámetro(-m) el cual indica que el mensaje que acompañara a los archivos enviados. Si se necesitara que un archivo no se encuentre en la área de espera se puede utilizar el comando git reset HEAD nombre_del_archivo de esta manera el archivo cambiara de posición.

Paso 10: Para poder dar seguimiento a los cambios que han sido enviados, vasta con que ejecutemos el siguiente comando.

Fig 11.Mostrando el listado de logs .

🔖 Nota: Este comando muestra información básica correspondiente al commit enviado.

Hasta este punto contamos con nuestro primer commit en nuestro repositorio local.

🌳 Manejo de Ramas

El uso de ramas es sencillo y poderoso en git, los comando que podemos utilizar son:

Fig 12.Listando ramas .

Fig 13. Creando una rama.

🔄 Combinar ramas

Para combinar una rama con otra, debemos primero pasarnos a la rama destino, y luego ejecutar el comando merge:

Fig 14. Mezclando ramas.

☠️ Eliminar una rama

Para eliminar una rama, existen dos métodos:

Fig 15. Borrando ramas de forma segura.

Fig 16. Borrando ramas.

Hasta este punto tenemos los conceptos básicos del manejo de Git y conocemos ls diferencias que tiene con GitHub ademas conocemos los diferentes tipos de VSC que existieron antes de llegar al control de versiones que conocemos hoy en día, en la segunda parte de este post veremos.

1. Como clono un repositorio existente.

2. Como se trabaja con múltiples usuarios.

3. Como subo mi repositorio a GitHub.

Espero les guste la entrada y recuerda dejar tus comentarios o de ser posible manda un email a jorge.mendez.ortega@gmail, no olvides dejar tus comentarios.