Tiempo de lectura: 15 minutos promedio.
Mi interés por Git empezó desde mis estudios en la Universidad; en ese momento estaba precisamente buscando una manera de trabajar colaborativamente con mis compañeros, hasta que uno de ellos mencionó la dichosa herramienta. Algo transversal, versátil, que se puede utilizar no solo en el área de desarrollo de software y en otras áreas aledañas a la Ingeniería de Software, sino que también tiene la virtud de poder ser utilizado en cualquier área que sea necesaria, ya que su función y el problema que facilita es bastante genérico y adaptable, no solo para versionar código.
¿Qué es Git?
Es como una máquina del tiempo donde puedes guardar los cambios de tu código, volver atrás, colaborar con otros y no perder nunca el progreso. Es parecido a escribir un libro con varias personas sin pisarse. Git registra cada palabra que cambian, quién la cambió y cuándo.
¿Por qué Git y qué alternativas tengo?
Su principal ventaja es la comunidad y la adopción que ha tenido la herramienta a nivel mundial. Si bien grandes empresas han tratado de imponer o patrocinar otras, al final podríamos decir que el mercado, los usuarios, se han inclinado por Git.
Alternativas, existen algunas interesantes como:
- Mercurial: es distribuido al igual que Git, algunos dicen que más simple. Ideal cuando buscas algo menos complejo que Git.
- Subversion: es centralizado, flujos lineales, control fuerte y simple.
- Perforce: también centralizado/distribuido; ideal para grandes repos, archivos binarios, empresas.
- Fossil: distribuido, todo en uno; ideal para proyectos pequeños con gestión integrada.
- Darcs / Pijul: distribuido, experimental; si estás interesado en modelos distintos de los clásicos.
La Certificación de Git
En la búsqueda de masterizar la herramienta, estuve interesado en mi camino de formación por las certificaciones, dichosos papeles o, en este caso, binarios digitales que te dan un gran boost para poder justificar y acentuar tus oportunidades laborales, y en el transcurso, aprendiendo sobre lo que te gusta.
Encontré, por comentarios de un amigo, la Linux Foundation, donde él había completado exitosamente las certificaciones de NodeJS que la misma ofrece también. Verifiqué y validé que la de Git estaba disponible, cuáles eran los tópicos a estudiar, en qué consistía, cuánto costaba para mi región y todas las reglas de lugar que a continuación te explico.
SC-102
Link directo del portal para todos los detalles:
Es la certificación de Git que, dentro de mis investigaciones, pude encontrar de la Linux Foundation, la cual me otorga el reconocimiento de que puedo dominar la herramienta y sus principales usos para trabajar con repositorios, ramas, así como inspeccionarlos, actualizarlos, realizar merges y rebases con el contenido y ramas de estos.
Algo a destacar es que es una credencial sin vencimiento.
¿Cuánto me costó?
De momento, la plataforma oficial te exige US$ 79.00 dólares americanos mediante el pago de esta.
Una vez hecho el pago, incluye elegibilidad para examen de 12 meses.
¿Cuáles son los tópicos a estudiar/masterizar en la certificación?
Como la herramienta es vasta y aún hoy en día continúa evolucionando, la certificación cubre los temas más transversales que no varían tanto en el tiempo, pero manteniéndose adaptada a la realidad:
- Clonar e inicializar repos
- Usar el stage y capturar cambios
- Manejar ramas y tags en repos
- Resolver conflictos
- Inspeccionar y comparar commits
- Trabajar con repositorios remotos
- Deshacer cambios y modificar commits
- Utilizar commits temporales
Modalidad del examen
El equipo de Linux Foundation, desde mi perspectiva, ha hecho un gran trabajo correspondiente al desarrollo de la plataforma para tomar el examen, así como el contenido del mismo.
Una vez iniciado el examen, no dependen de una persona que previamente se encuentre allí contigo durante la sesión para validar que tus condiciones para tomar el examen sean óptimas (no ruido, no más personas en la habitación, entre otros), como en diversas certificaciones de otras empresas de renombre; se apoyan de la AI mediante cámara y micrófono encendidos, buscando mitigar cualquier burla que desee realizar algún aplicante.
Es un examen de alrededor, en mi caso, 9 preguntas, donde predomina el uso de la terminal y debes ir ejecutando los comandos necesarios para poder llegar a la carpeta o repo mencionado, verificar qué tienes allí disponible y ejecutar los comandos necesarios para completar la asignación.
Es un examen de opción múltiple y basado en desempeño de los comandos que ejecutes y cómo realices la asignación.
En mi experiencia, al ser solamente alrededor de 9-10 preguntas, como podrás deducir, es fácil fallar y quedar por debajo de la puntuación requerida para pasar (mínimo 70 puntos), por lo que hay que tomarlo en cuenta; puedes terminar rápido, pero también fallar rápido.
Nivel de dificultad
No he tomado otro tipo de certificaciones de esta índole, pero por experiencia de otras personas cercanas a mí, esta fue bastante fácil cuando ya conoces la modalidad del examen, conoces y trabajas con la herramienta en tu día a día.
Duración tope del examen: 45 minutos.
Mi recorrido para dominar la herramienta (Git) y tomar el examen
Primero, apoyándome de la AI, procedí a usar ChatGPT como compañero de estudio y herramienta aliada para crear un programa de estudio basado en los temas que especificaba el portal oficial.
Creé un prompt bastante detallado con lo que requería, donde le solicité, en base a la certificación, la empresa que la ofrece, los tópicos que hay que estudiar que ellos recomiendan (pero que no se limite solo a estos, sino que abarque cualquier otro tema de Git que sea bueno masterizar para entender la herramienta en su plenitud y a nivel laboral desempeñarse correctamente), le solicité un programa de estudios con el objetivo de separar los temas e ir estudiándolos paso a paso durante algunas semanas.
Temas que estudié, más allá de los recomendados por la Linux Foundation:
- Referencias relativas y navegación de commits
- Reset vs Restore
- Configuración global y local del sistema
- Manejo del Stash
Apoyándome de un repositorio en Github que creé para poner en práctica todo lo que iba realizando y dejar transparencia en el proceso:
Segundo, luego de haber finalizado dicho material y aún no sentirme preparado, decidí retomar una herramienta de estudio de Git que completé en mis años de la Universidad, la cual es online, no depende de IDE ni de conocimientos previos (aunque tenerlos te da un plus o al menos para repasar); la misma es Learn Git Branching. Tiene como objetivo enseñarte a trabajar colaborativamente de manera local y remota en Git, que en pocas palabras es lo que necesitas, pero ellos van desde cómo clonar un repo hasta realizar resolución de conflictos en remote y local con múltiples alternativas de comandos avanzados.
En realidad me gustó realizar el refrescamiento, ya que me dio más confianza.
Me ayudó bastante a completar la confianza en mí mismo y reforzar temas que tenía poco claros que en ninguno de los dos pasos anteriores había estudiado (los tópicos que estudié personalmente están actualizados con los que también luego estudié de este curso).
Nota importante: Todos estos materiales para mí fueron necesarios, ya que si quiero masterizar y aprender algo de verdad, me gusta conocerlo en su mayor amplitud posible y dominar sus profundidades, por lo que mi preparación luego comprendí que pudo ser más corta y fue más allá de los requerimientos del examen. Me sirve como parte integral de entender la herramienta a un nivel superior, ya que varias lecciones que aprendí he podido aplicarlas en mi carrera profesional, por lo que tanta preparación fue una decisión propia y personal.
Git en el Ciclo de Vida del Desarrollo de Software (SDLC)
Usar la herramienta en el mundo real, desde mi perspectiva en el desarrollo de software como software engineer, es bastante interesante, ya que con patrones como GitFlow flexibilizado, de ser necesario, a tus condiciones particulares, puede llegar a ser un gran aliado.
Te comentaré cómo utilizamos Git y el flujo de trabajo del mismo en la empresa en que laboro actualmente y el equipo con el que me desempeño, que a partir de la necesidad y problemas que nos hemos encontrado, hemos creado nuestro propio flujo de trabajo. Si te funciona y sirve, adelante, toma lo bueno; si no, está bien, ya que cada flujo o equipo se adapta a sus necesidades.
Contexto
En una empresa que no se especializa en el desarrollo de software como su modelo de negocio primario, tiene el área de TIC en procesos de maduración continua y con buena base; utilizamos la metodología Scrum o, al menos, un intento de la misma, específicamente en el departamento al que pertenezco, la célula en la que me encuentro como Líder Técnico.
Hemos establecido una serie de estándares para manejar las demandas del negocio y cómo tradujimos esto del lado técnico para la gestión de los features, ramas, etc.
Caso de Uso
Tenemos distintos departamentos de negocio que exigen funcionalidades a inicio de año y a lo largo del mismo.
Nuestro foco es una plataforma móvil y stack tecnológico basado en bare react-native.
Es una aplicación, podríamos decir, administrativa, donde tiene un gran número de funcionalidades para las cuales se aplican mejoras, refactorizaciones o creación de nuevas de ellas.
Aplicamos y creamos el concepto de Ramas Madres, donde cada nuevo feature o conjunto de requerimientos nace desde develop, que siempre se encuentra actualizado con los últimos cambios lanzados a producción.
Luego, iniciando el desarrollo de dicho feature, cada developer involucrado tiene un conjunto de items o Historias de Usuario que debe trabajar relacionadas al mismo; crea sus ramas a partir de la rama madre con la nomenclatura de feature/PBI-xxxxx, mediante la cual va trabajando todo lo relacionado a la misma.
Así todos los demás developers, una vez cada uno va finalizando su trabajo, realiza los PR's necesarios a la rama madre nuevamente, y cada developer notifica; los demás bajan dichos cambios y se actualizan con lo que hizo el colega.
Hasta que paulatinamente todo se encuentre en la rama madre y tengamos, dependiendo de lo acordado con el PO, un MVP (Minimal Viable Product), con el objetivo de que desde dicha rama madre generar las versiones vía local o CI/CD al ambiente de staging/QA (no la rama).
Así podríamos tener varios features con distintos avances y progreso a lo largo de los meses, que son pausados o no finalizan del todo por nuevas mejoras, requerimientos agregados, impedimentos o pendientes de insumos de los otros equipos como Backend, Base de Datos, entre otros, ya que se puede ir avanzando hasta con solamente el UI (maquetado).
Si surge algún hotfix necesario en producción, se realiza un switch; el developer encargado de turno del soporte a PROD, desde develop, saca una rama con la nomenclatura de hotfix/ID-XXXX con el objetivo de poder resolver el mismo con los cambios más cercanos a prod y tratar de replicar lo que hizo el usuario, validar logs y demás. Una vez finalizado el hotfix, se crea la rama release/x.xx.x_vx según sea la versión y se generan las versiones a QA para pruebas de regresión y luego a producción, y se crean los PR's a develop para mantenerlo actualizado y luego a la rama staging, donde su único propósito es para correr mediante CI/CD el análisis estático de código mediante la herramienta de SonarQube.
Luego se crea un último PR desde develop a master, donde la misma no se toca ni para tomar una rama.
¿Por qué entonces usamos la rama de develop como maestra principal? Debido a que, como tal, ya por particularidades de la empresa, aún no tenemos un ambiente transversal completo expuesto para Desarrollo.
¿Por qué no usamos la rama staging como maestra para generar versiones de QA? Debido a que la licencia de SonarQube que tenemos hasta el momento no nos permite poder especificar distintas ramas (que debería ser la que cada developer vaya trabajando en el día a día) corriendo constantemente cada vez que se realiza un push a remote, el análisis de código.
Nuevamente, podemos tener constantes y varios features (ramas madres) siendo trabajadas a lo largo del año que pueden tener avances más que otros y pueden salir a PROD más rápido que otros, por lo que también, debido a la particularidad de una AppMóvil, pues decidimos hacerlo de esta manera.
¿Manejo de las versiones? Utilizamos el estándar de SemVer SemVer, adaptado con el uso de OTA en app móviles mediante lo que era la herramienta en su pasado de CodePush de AppCenter.
Ramas que utilizamos y tenemos:
- master
- staging (SonarQube) - develop (comodín para releases y nuevos features)
- release/X.X.X_vX
- hotfix/ID-xxxxxx
- ramas madres (funcionalidad-nueva)
- feature/PBI-xxxxx
- bugFix/ID-xxxxxx
Conclusiones:
Git es una herramienta poderosa que vale la pena el tiempo dedicado a estudiarla para automatizar y mejorar flujos de trabajos en lo profesional. La travesía para tomar la certificación rindió sus frutos y fue satisfactoria.
Animo a todo interesado o a quienes la usan constantemente en su día a día a tomar dicha certificación, ya que es una herramienta de uso transversal y que puede ser de gran apoyo para nuevas oportunidades laborales y desarrollarse en las tareas diarias.
Gracias por tomarse el tiempo de leer esta experiencia.
Top comments (0)