GIT REMOTE
$git init¡Bienvenido a tu repositorio! Ahora creemos el primer archivo en nuestro repositorio, siéntete libre de crearlo manualmente o aprovecha tu consola de git bash para usar el comando:
$touch archivo.extensionEscribimos algo en el archivo , guardamos y a partir de este momento empezaremos un proceso al que vamos a hacer referencia como flujo básico.
Comandos mágicos del flujo básico:
$git statusGit status presenta el estado actual del repositorio, los archivos que git no está rastreando o que han sido modificados se presentan de color rojo, los archivos que git ya rastrea se presentan en verde, para empezar a rastrear archivos podemos usar el siguiente comando:
$git add -AGit add permite añadir archivos a git, a continuación de este comando podemos indicar manualmente que archivo añadir, o podemos indicarle que añada todos los archivos del repositorio usando la bandera -A , si estamos en un directorio podemos jugar con los path relativos para reemplazar esta bandera:
Podemos verificar nuevamente en git status como git nos indica que los archivos han sido añadidos ¿Pero a que han sido añadidos? Git guarda en un área temporal conocida como Staging Area a la espera de confirmar el envío al repositorio.
El archivo ya está siendo visto por git, ubicado en nuestra Staging Area, pero aún no está oficialmente en el repositorio, para lograr esto el siguiente comando mágico que deberías aprender es:
$git commit -m “Aquí va un mensaje para describir el commit”Git commit nos envía al repositorio los archivos en el Staging Area, lo acompañamos con un mensaje indicado mediante la bandera -m, a continuación debería añadirse un mensaje que acompañará el commit y como buena práctica este mensaje debe ser muy descriptivo con los archivos añadidos o los cambios realizados.
Una de las ventajas de git es que nos permite ver los cambios realizados en nuestro código en cada commit, puedes ver este historial utilizando el comando:
$git log
Y aquí damos por finalizado un flujo básico de git, tus primeros archivos han sido cargados a tu repositorio local, si te sientes perdido puedes observar la imagen que añadimos a continuación con los comandos utilizados, si hacemos git status podremos observar que git nos está indicando que no hay archivos o cambios por subir al repositorio.
Adicionalmente, es posible ignorar archivos para que git no los añada al repositorio, mediante un archivo conocido como .gitignore (https://git-scm.com/docs/gitignore).
Todo este procedimiento se hace en nuestro computador, haremos referencia a este como repositorio local. Pero … ¿Cómo sería si quisiera realizar un trabajo colaborativo?
Repositorio remoto — Github
Aquí entran a funcionar los repositorios remotos, por ser el más común utilizaremos github, sin embargo los comandos no distan mucho de otras plataformas como GitLab , Azure Devops, CodeCommit (AWS) , entre otros.
Una vez creamos un repositorio, Github nos indica como conectar nuestro repositorio local a este, con seguir las indicaciones fácilmente conectaremos nuestros repositorios, en caso de perderte te resumimos:
$git remote #Trae la información sobre los repositorios remotos
$git remote add origin git@github.com:url #Añadir repositorio remotoIndicamos que conectaremos a un repositorio al cual llamaremos origin, a continuación debemos incluir la conexión que indica nuestra pestaña de clone (Recuerda que puedes usar el protocolo SSH para clonar repositorios).
Finalmente, usaremos un comando que veremos muy seguido:
$git pushEn resumen, este comando envía información del repositorio local al repositorio remoto. En nuestra terminal deberíamos ver algo similar a lo presentado a continuación:
Y en nuestro Github deberíamos empezar a ver el archivo que teníamos en nuestra máquina:
¡Ta dá! Tu repositorio, el que tenías en tu computador ahora está siendo alojado en github, sin embargo aún no estamos hablando de un trabajo colaborativo, en esta ocasión añadiremos colaboradores a nuestro repositorio.
Configurando colaborador
Una de las formas de trabajar colaborativo en un proyecto consiste en añadir colaboradores al proyecto, para lograrlo en nuestro repositorio nos dirigimos a settings > manage access > add people y añadimos el correo o el usuario de la persona que queremos que colabore en nuestro proyecto:
Para nuestro ejemplo, Sebastian será añadido y tendrá acceso como colaborador al repositorio de Laura, con esto él debería repetir el proceso de clonar el repositorio en su máquina local y ya podría realizar un flujo básico de git en su máquina local.
Creación de ramas
Hasta el momento nuestro repositorio está descargado en nuestros computadores y como podemos observar si usamos el comando $git branch existirá una única rama (master/main), procedemos a crear una nueva rama (Laura), en esta crearemos una carpeta y dentro de la carpeta un archivo de texto en el que escribiremos algo y realizaremos un push a nuestro repositorio en github.
Esta vez notemos que el comando $git push tiene un argumento adicional, le indicaremos la rama en local que queremos enviar y la rama en github a la que queremos enviar (esta se creará si no existe) , para evitar confusiones esta rama puede ser nombrada de la misma forma que en local (ramaLocal:ramaRemoto):
Sebastián realizará el mismo procedimiento, notemos que no hay diferencias, simplemente él crea una rama con su nombre y un archivo de texto llamado igual:
El resultado después de realizar push desde el punto de vista en github es el siguiente:
Notemos como en github existen ahora las ramas (main), (Laura) y (Sebastian) , sin embargo los archivos creados solo existen en sus respectivas ramas, por eso, github nos indicará acerca de la opción de hacer un Pull Request:
Si esta opción no aparece debemos darle a la pestaña de pull request y crearlo manualmente , veamos que esta forma es idéntica para ambos:
Cosas importantes para destacar:
- A Github debemos indicarle la rama a la cual realizaremos el Pull Request y la rama que queremos enviarle, en caso de olvidar la flecha nos indica este proceso.
- Debemos poner un título al Pull Request.
- Podemos añadir un comentario sobre el Pull Request, aquí deberíamos ser bastante explícitos y explicar qué cambios realizaremos en (main) con nuestro Pull Request.
Adicional, notemos como Github nos pone un mensaje “Able to merge” , es decir no existen conflictos entre las ramas para poder realizar este procedimiento.
Sin embargo ¿Quién aprueba estos cambios? Una buena práctica sería definir una cantidad mínima de personas para aprobar el Pull Request, o determinar personas en específico, este proceso deberá decidirlo el equipo de trabajo, para efectos prácticos ambos podemos aceptar el Pull Request dando clic en Merge Pull Request:
Si volvemos a la pestaña de código después de aceptar el Pull Request, observemos como en (main) aparecen las carpetas y archivos creados por ambos en nuestras respectivas ramas:
Pero estos cambios existen solamente en Github, por esto debemos realizar un proceso de actualización de nuestros repositorios en local, trayendo la información actualizada de nuestra rama (main).
El primer paso para llevar a cabo este proceso es cambiar nuevamente en local a nuestra rama (main), a continuación ejecutaremos el comando $git fetch origin (Origin es el nombre que le asignamos en git al repositorio remoto, podemos verificar con el comando $git remote -v) , este comando detecta los cambios en el repositorio remoto:
Una vez detectados estos cambios, los traemos con el comando $git pull origin main , indicando que de nuestro repositorio remoto origin traeremos los cambios únicamente de la rama (main):
Pero como regla establecida para realizar trabajo colaborativo, nunca trabajaremos en nuestra rama (main) , motivo por el cual cambiaremos nuevamente a nuestra rama para trabajar y le añadiremos los cambios con $git merge main , observemos como git nos indica la creación de estos archivos e igualmente podemos verificar con el comando $ls
Hasta el momento todo se encuentra en perfecto estado, pero la pregunta es…
¿Qué pasa cuando ambos trabajamos en el mismo archivo?
Aprovechemos el primer archivo creado con el repositorio, ambos realizaremos un cambio en este, llevaremos los cambios a github y procederemos a crear un Pull Request, en esta ocasión Laura fue más rápida que Sebastián y realizó el proceso como fue explicado anteriormente:
Sin embargo, Sebastián por lento, cuando vamos a aceptar el Pull Request nos encontramos con un mensaje de advertencia, Github nos avisa de que archivo presenta conflictos y nos permite hacer un comentario indicando que por favor corrija el conflicto:
Aquí deberíamos ser muy descriptivos con el mensaje para que Sebastián pueda solucionar los conflictos:
Una notificación llegará al Github de Sebastián, donde se puede observar claramente en el conflicto la presencia de las líneas agregadas por Laura en su Pull Request, entonces ¿Cómo debería Sebastián solucionar el conflicto?
Primero, debe actualizar y traer toda la información de la rama (main), llevamos los cambios a nuestra rama de desarrollo (Sebastian) y nos encontramos con un mensaje de git al realizar merge, indicándonos que existen conflictos para realizar este proceso:
Importante: existen múltiples formas de realizar la solución al conflicto, por facilidad aprovecharemos Visual Studio Code por tener una herramienta muy visual para facilitar la solución de conflictos como puede ser visto a continuación:
Tenemos tres opciones, aceptar ambos cambios, solo nuestros cambios o solo los cambios provenientes de github para este caso, aceptamos ambos cambios, arreglamos el orden de líneas, guardamos y procedemos nuevamente a realizar el flujo básico para finalmente subir los cambios a remoto.
Notemos que desaparece MERGING del nombre de la rama, indicando el fin de los conflictos.
Finalmente Laura puede aceptar el Pull Request y el resultado visto en la pestaña de código es el siguiente:
Facilito! Si llegaste hasta acá siéntete orgulloso, aprendiste de un extenso tutorial en el que abordamos:
- Creación de repositorio
- Flujo básico para guardar cambios en un repositorio
- Creación de un repositorio remoto y enviar nuestros archivos en local
- Crear un repositorio colaborativo
- Solucionar conflictos de un repositorio colaborativo
Esto es todo lo básico que debes saber de git, y aunque existen metodologías para abordar un trabajo colaborativo a un nivel más profesional (Como Gitflow), si lograste entender lo descrito en este blog te será mucho más fácil entender estas metodologías de trabajo.
Existen comandos más avanzados en git para trabajar en tus proyectos, algunos te permiten volver a una versión anterior de los commit que has realizado, guardar cambios rápidos y modificar el commit más reciente, entre otros. Puedes ir a la documentación oficial de git o utilizar algunos recursos que dejaremos al final.
Bonus
Si te sientes abrumado con la cantidad de comandos utilizados, aquí te dejamos una tabla de resumen:
Recursos:
Esta publicación la hicimos en compañía de Sebastián Pastrana, Data Analyst Jr, 99% Electronic Engineering. Music lover, data fanatic & other geeks hobbies. Pueden encontrarlo en redes como @sebastianpasar
Gracias por leernos.
Hecho con ❤
