Onboarding GIT

Onboarding

Empezar

¿Qué es GIT?

Git es un sistema de control de versiones distribuido gratuito y de código abierto diseñado para manejar todo, desde proyectos pequeños hasta proyectos muy grandes con velocidad y eficiencia. Git es fácil de aprender y ocupa poco espacio con un rendimiento ultrarrápido . Supera a las herramientas SCM como Subversion, CVS, Perforce y ClearCase con características como ramificaciones locales económicas , áreas de preparación convenientes y múltiples flujos de trabajo.

web git

MANUAL GIT

Conocimientos básicos

Comprender los conceptos básicos de Git, como repositorio, rama, confirmación (commit), estado y ramificación.

Instalar Git y configurar su entorno de trabajo, incluyendo la configuración del nombre de usuario y correo electrónico.

Crear y clonar repositorios con Git.

Utilizar la línea de comandos de Git para realizar operaciones básicas.

Comprender el proceso de fusión (merge) y resolución de conflictos en Git.

COMANDOS BÁSICOS

COMANDOS

Inicializa un nuevo repositorio de Git en el directorio actual.

GIT INIT

Crea una copia local de un repositorio remoto. git add: Agrega archivos al área de preparación (staging) para que puedan ser confirmados.

GIT CLONE

Cambia a una rama diferente o recupera un archivo desde una confirmación anterior. Ejemplo: git checkout -b rama/nombre_de_rama

GIT CHECKOUT

Muestra el estado actual del repositorio, incluyendo los archivos que han sido modificados y los que están en el área de preparación.

GIT STATUS

Obtiene los cambios más recientes de un repositorio remoto y los fusiona con la rama actual.

GIT PULL

Confirma los cambios agregados al área de preparación y guarda una instantánea (snapshot) del repositorio.

GIT COMMIT

Muestra un registro de los commits realizados en el repositorio, incluyendo la información de fecha, autor y mensaje de confirmación.

GIT LOG

GIT PUSH

Envía los cambios locales a un repositorio remoto.

Veamos un ejemplo de como podemos ejecutar dichos comandos en la práctica

9. GIT PUSH

Envía los cambios locales a un repositorio remoto.

8. GIT LOG

Mostramos un registro de los commits que hemos hecho en el repositorio, incluyendo la información de fecha, autor y mensaje de confirmación.

1. GIT CLONE

Creamos una copia local del repositorio remoto.

7. GIT COMMIT

Realizamos cambios y los agregamos al área de preparación

6. GIT PUSH

Envía los cambios locales a un repositorio remoto.

6. GIT STATUS

Comprobamos que la rama actual es la que hemos creado

5. GIT CHECKOUT

new branch

Creamos una nueva rama de la rama principal con git checkout -b

4. GIT PULL

2. GIT CHECKOUT

Obtenemos los cambios más recientes del repositorio remoto y los fusionamos con la rama actual.

Cambiamos a la rama principal para crear una nueva rama

3. GIT STATUS

production

Comprobamos que la rama actual es la principal

GITMOJi

GITMOJI

Gitmoji es una iniciativa para estandarizar y explicar el uso de emojis en los commit, esto con la finalidad de identificar a simple vista la intención de dicho commit con el uso de los emojis.

GITMOJi

GITMOJI - PROYECTO

Si realizamos un cambio en un PROYECTO y agregamos una nueva característica, por ejemplo una tabla, escribiríamos un commit de la siguiente manera: Añadimos el nombre del proyecto seguido del emoji correspondiente y luego el mensaje descriptivo. Se pueden hacer de las dos siguientes formas, copiando y pegando el icono o mediante el uso de shortcut.

git commit -m "Anniversary ✨ Added Grid for Sales module"

git commit -m "Anniversary :sparkles: Added Grid for Sales module"

GITMOJi

GITMOJI - RAPTURE

En caso de ser en un RAPTURE escribiríamos un commit de la siguiente manera:Añadimos el código del Rapture seguido del emoji correspondiente y luego el mensaje descriptivo.

git commit -m "19234 ✨ Added Grid for Sales module"

git commit -m "19234 :sparkles: Added Grid for Sales module"

RAMAS - PROYECTO

Creamos una nueva rama dentro de la carpeta llamada 'base_login' de la siguiente manera: git checkout -b login_features/base_login

Para añadir funcionalidades creamos una carpeta llamada 'login_features'

Login base ✨ add a new ip service

login_features/base_login

Login sms 🔧 new cooldown typed config

login

El nombre del proyecto se pone en MINUSCULAS

El nombre del proyecto en el commit se pone la primera en MAYUSCULAS

Creamos la nueva rama desde production para un PROYECTO llamado 'login' con: git checkout -b login

Login 🎉 created login module

login

Realizamos un commit con el siguiente comando: git commit -m login 🎉 created login module

production

RAMAS - RAPTURE

feature/15744_qr_clean_command

19758 ✨ command to clean email queue

En caso de existir la rama de ese RAPTURE, no es necesario realizar la creación de la rama, simplemente nos movemos de rama con:git checkout feature/19758_clean_email_queue

Podemos realizar los commit necesarios para su gestión en sus respectivas ramas

15744 ✨ new controller to reset password

15744 🐛 fix order active issuance type from varchar to text

feature/15744_qr_clean_command

Si queremos crear una nueva rama para un RAPTURE que no esa creado, hacemos lo siguiente: git checkout -b feature/15744_qr_clean_command

Realizamos un commit de los cambios que se realicen con el siguiente comando: git commit -m 15744 🐛 fix order active issuance type from varchar to text

production

GIT FLOW

El flujo de trabajo se divide en tres partes, las cuales tienen sus propias metodologías. Trabajamos con 3 entornos diferentes:

PRO

QA

LOCAL

En nuestro local, nos dedicamos a desarrollar proyectos y atender todas las mejoras, peticiones o correcciones que surjan. En esta etapa, nos enfocamos en probar, modificar y ajustar las estructuras según sea necesario.

LOCAL

Comenzamos realizando pruebas exhaustivas para asegurarnos de que todo funcione correctamente. Estas pruebas nos permiten identificar posibles errores o deficiencias en el desarrollo. Si encontramos algún problema, procedemos a realizar las modificaciones correspondientes para corregirlo. Durante este proceso, también podemos hacer cambios en la arquitectura o estructura del proyecto según sea necesario.

En nuestro flujo de trabajo, optamos por crear ramas separadas para subir los desarrollos a QA, donde se realizarán pruebas exhaustivas para verificar que funcionen correctamente y no haya conflictos. Esta metodología nos permite mantener un entorno controlado y aislado para evaluar la calidad y estabilidad del código antes de su implementación final.

QA

Existen varios inconvenientes que justifican la necesidad de mantener el desarrollo en una rama separada durante esta etapa. En primer lugar, puede haber dependencias externas o terceros involucrados en el proceso, como proveedores de servicios o integraciones con sistemas externos. La espera de sus respuestas o entregables puede ralentizar el flujo de trabajo principal, por lo que es preferible mantener esos desarrollos en una rama aparte hasta tener todo lo necesario para una revisión completa en QA.

Una vez que hemos completado todas las pruebas y verificaciones en el entorno de QA y estamos seguros de que el desarrollo funciona correctamente y no hay conflictos, solicitamos la puesta en producción. Este paso es crucial para asegurar que el producto final esté listo para ser presentado a los clientes o administradores.

PRO

Una vez que hemos completado todas las pruebas y verificaciones en el entorno La solicitud de puesta en producción implica una serie de pasos adicionales antes de que el desarrollo pueda ser implementado en el entorno de producción. Esto puede incluir la revisión y aprobación del equipo de gestión del proyecto, así com o la coordinación con otros departamentos o equipos que puedan estar involucrados en el proceso.

anniversary

PRODUCCIÓN: EL COMIENZO

Al desplegar una corrección, un nuevo proyecto o mejoras, es imprescindible contar con todas las dependencias actualizadas y las últimas versiones de los módulos y aplicaciones externas utilizadas.

login

La creación organizada de ramas es esencial para garantizar un desarrollo eficiente y sin contratiempos. En primer lugar, es crucial partir de una rama principal estable, como la denominada master, principal o producción en nuestro caso específico.

taquillas

notification

Esta rama principal estará actualizada con los últimos cambios implementados y las dependencias necesarias para el correcto funcionamiento del proyecto.

Esto asegura que nuestro desarrollo esté en línea con las últimas tecnologías y evita posibles conflictos o errores debido a versiones desactualizadas.

production

La creación de ramas separadas también brinda la flexibilidad de trabajar en múltiples características o correcciones simultáneamente sin interferir entre sí.

PRODUCCIÓN: DIVISIÓN DE RAMAS

¿Por qué trabajar con ramas?

anniversary/modal_title_scratch

Anniversary 🔨 refactor

anniversary/login_no_phone

Anniversary ✨ new field

Dividir el trabajo en ramas individuales permite un enfoque más claro y ordenado. Cada rama puede ser asignada a un desarrollador específico o a un equipo, lo que facilita la colaboración y la identificación de responsabilidades. Para evitar conflictos, cada desarrollador puede crear su propia rama aparte de la principal, realizar sus cambios y luego fusionarlos de manera segura y controlada.

anniversary/scratch_pro

Anniversary 🦫 add field

anniversary/ticket_participations

Anniversary ✨ add flag

Anniversary 🔧 new config

anniversary/new_history_phone

anniversary

Otro aspecto a considerar es la concurrencia. Al trabajar en equipo, es probable que varios desarrolladores estén trabajando en diferentes tareas al mismo tiempo.

MEZCLA DE RAMAS

🔀 Merge branch 'login' into production

production

En este punto, cuando se hayan hecho las pruebas y funcione correctamente en QA, se pasa a produccion la rama creada

Hacemos un Merge para mezclar la rama que hemos hecho con el commit en la rama de QA

qa

🔀 Merge branch 'login' into qa

login ✨ add new navigate menu

login

Realizamos el commit con el menú creado

Realizamos en este punto el desarrollo, por ejemplo de un menú de navegación

Creamos la nueva rama para un PROYECTO llamada 'login' con: git checkout -b login

login 🎉 created login module

login

Realizamos un commit con el siguiente comando: git commit -m login 🎉 created login module

production

🔀 Merge branch 'feature/15744_qr_clean_command' into production

Una vez que el Rapture se ha subido a la rama, se sube a QA donde se realizan pruebas, se comprueba que funcione correctamente y luego se pasa a producción para volver a comprobar que todo funcione.

🔀 Merge branch 'feature/15744_qr_clean_command' into qa

Realizamos un commit de los cambios que se realicen con el siguiente comando: git commit -m 15744 🐛 fix order active issuance type from varchar to text

feature/15744_qr_clean_command

15744 🐛 fix order active issuance type from varchar to text

Realizamos las tareas que sean necesarias

feature/15744_qr_clean_command

Creamos la rama con el comando siguiente: git checkout -b feature/15744_qr_clean_command El nombre de la rama debe almacenarse en feature y debe tener el numero de Rapture y una descripción del mismo

Si queremos crear una nueva rama para un RAPTURE, hacemos lo siguiente: Nos situamos en la rama principal del proyecto, production

production

gIT KRAKEN

GitKraken

Utilizamos como interfaz de GIT el software GitKraken.Es una herramienta multiplataforma que nos ayuda a manejar Git de manera sencilla. Con GitKraken podemos abrir fácilmente repositorios, organizar favoritos y organizar estos en grupos de proyectos entre otras cosas.