De git y sus buenas prácticas

El 7 de abril de 2005, Linus Torvalds realizaba el lanzamiento de un producto que años más tarde sigue siendo líder en la industria y revolucionaría la forma en que los equipos y los desarrolladores de software trabajaban.

Su sitio oficial lo define como “un sistema de control de versiones libre y open source diseñado para manejar todo desde pequeños a grandes proyectos con velocidad y eficiencia”, y quizás es la mejor definición que se pueda dar. Sin embargo, en este artículo exploraremos un poco más acerca de los diversos usos que hay para git (algunos más allá del desarrollo de software) y las algunas buenas prácticas que se deberían aplicar en su uso.

Buenas prácticas

Existen tantas formas de trabajar Git como repositorios hay en el mundo, sin embargo, al trabajar con diferentes equipos en diferentes escenarios, ciertos patrones empiezan a aparecer, como reglas no escritas que nos permiten comunicarnos y organizarnos mejor dentro de nuestros y equipos y con la comunidad.

Ramas

Las ramas son quizás la herramienta más útil que nos provee git, es una forma de trabajar en paralelo y poder divagar tanto como queramos pero con la seguridad de que partimos de la misma base y llegaremos al mismo destino al final. Sin embargo, el manejo de ramas no siempre es claro en algunos equipos, esto es más evidente al descubrir que no todas las ramas deberían usarse con el mismo propósito.
Todos sabemos que la versión final del producto que irá a producción está en master y que nuestra versión cambiante e inestable de desarrollo está en develop. Pero, no podemos trabajar directamente sobre estas ramas o venceríamos su propósito, esta es quizás la más importante de las buenas prácticas, evitar commits directos a las ramas principales.
Así es que creamos distintos tipos de ramas que según lo que contengan y la rama final a la cual apunten pueden tener diversas definiciones, así por ejemplo tenemos entre las más populares:

• feature, la vieja confiable, partimos esta rama normalmente desde develop y a esta misma la apuntamos, contiene cambios normalmente relacionados a un improvement o una mejora de lo que ya hay en develop.

• hotfix, aquella a la cual tememos y deseamos nunca llegar, hotfix es una rama que nace normalmente de master y que surge de una colosal equivocación que debemos arreglar cuanto antes.

• bugfix, la versión light de hotfix, es normalmente debido a algún bug que encontramos en nuestra fase de desarrollo de algo que ya se encuentra en develop y que debe ser arreglado con moderada urgencia.

• release, en algunos equipos es considerada buena práctica tener una rama intermedia entre master y develop, release sale como una versión lo suficientemente limpia de develop que aún está en su trayecto final de mergear a master y salir a producción.

Como mencionaba, existen diversas formas de manejo de ramas, sin embargo, estas cuatro pueden asegurarte la comodidad de trabajar en la mayoría de equipos y de proyectos que puedas encontrar.

¿Nuevo commit o ammend? ¿Rebase o Merge?

Al igual que algunos equipos prefieren manejar una mayor cantidad de ramas para mantener organizado el trabajo, mientras que otros prefieren reducirlas a su mínima expresión para mejorar la comprensibilidad del mismo; hay distintas preferencias respecto al manejo del historial de git.
Tratemos inicialmente la duda entre los commits y los ammends, a lo que me refiero en este caso es a la duda entre enviar varios cambios que están sobre la misma rama en diversos commits, uno tras el otro o hacer ammend sobre uno solo para simplificar la historia, bueno, veamos el escenario en que cada uno es mejor utilizado:

• ammend, es claro que si tenemos un solo feature en el cual estamos trabajando y olvidamos algún cambio al cual ya hicimos commit, no vamos a querer enviar otro commit, con otro mensaje diferente que pueda ensuciar la historia de git, es por eso que existe el comando ammend, para simplemente agregar cambios a un commit existente y como dice su traducción “enmendar” los errores, dejando el historial más limpio.

• Sin embargo, si tenemos un caso en el cual hay varias tareas siendo trabajadas sobre la misma rama, no deberíamos nunca sacrificar la claridad que ofrecen varios commits cortos sobre un solo commit parchado muchas veces.

Finalmente, consideremos el dilema de trabajar los cambios entre ramas con un rebase o con un merge, dejando claro que esta decisión depende del equipo y de las condiciones en que se esté desarrollando el proyecto, estas son los procesos y los pro y contra de cada uno:
rebase, un rebase desde la rama A hacia la rama B consiste en traer todos los cambios que habían en la rama A como si hubieran sido hechos directamente en la rama B, no queda un registro de que se hubiera hecho un merge.
merge, un merge desde la rama B hacia la rama A consiste en enviar los cambios que hay en la rama B a la rama A, pero dejando una constancia (en forma de commit) de que esos cambios se trajeron producto de un merge, es decir, desde una rama externa.

Sin embargo, esta pregunta puede que no sea tan sencilla de responder, o quizás sí, si la evitamos del todo.

“Usa rebase si tu feature está por detrás de develop, usa merge al haber terminado de hacer tus cambios y quieres enviarlos a develop”
-Algún tipo simpático en StackOverflow

Siendo así, puedes usar un rebase cuando sabes que alguien ha enviado sus cambios a develop y quieres incorporarlos a tu propia rama de feature, y cuando finalmente termines, puedes enviar tus cambios a develop mediante un merge, que es como lo hacen los pull-requests.

Y hablando de pull-requests…

Pull Requests

Los pull-requests o merge requests como son llamados en GitLab (con más precisión en mi opinión) son una solicitud que hace el desarrollador al dueño del repositorio (o a quien sea que posea los permisos) de mezclar lo que tenga en su rama con otra, normalmente master o develop. Este mecanismo permite no solo crear una mayor organización dentro del repositorio sino que adicionalmente da un nivel de seguridad y de calidad al mismo, puesto que los cambios deben sufrir un proceso de revisión y aprobación antes de pasar a hacer parte íntegra del código de la aplicación.

El caso de los pull requests es más sencillo y la buena práctica aquí consiste simplemente en usarlos, en lo posible poniendo reglas para su aprobación como que x cantidad de contribuyentes lo aprueben o que lo haga uno con y rango dentro del proyecto.

Algunas celebridades del mundo de git

Los repositorios más populares de la comunidad open source suelen estar hospedados en GitHub, por algo llegó a llamarse la red social de los programadores, así que, para cerrar este artículo, quiero traer algunos de mis repositorios favoritos de git, para que puedas ojear y aprender una cosa o dos de cómo manejan sus proyectos.

React

El niño consentido de Facebook, React es uno de los frameworks más populares del momento, con un total (al momento de esta publicación) de 49 ramas activas, React es una muestra de que permitir que la comunidad construya lo que va a consumir, creando sus propias mejores, apuntando sus propias incidencias y corrigiéndolas; todo esto cobijado por el gigante tecnológico que es Facebook, es el camino correcto.

Oh My Zsh

Oh My Zsh es un framework para poder personalizar nuestra terminal a niveles bastante interesantes. Con más de 1500 contribuyentes y más de 5000 commits, Oh My Zsh no solo hospeda el código fuente de este framework sino que tiene además una guía básica de uso y los enlaces a varias herramientas complementarios creadas y mantenidas por la comunidad.

RoadMaps

Acá empezamos a adentrarnos en territorios más interesantes, algunas personas cayeron en cuenta de que GitHub, al tener el público que tiene, puede hospedar más que proyectos dedicados y código spaghetti por todos lados (JK, of course). Este es el caso de RoadMaps, una serie de proyectos que sirven como una clase de infografía/guía para desarrolladores novatos en diversos temas, tanto de desarrollo, como de lenguajes específicos, como de DevOps, etc.

Repositorios de la Ciudad de Chicago

Así es, la ciudad de Chicago hizo su propio perfil de GitHub junto a varios repositorios de su autoría, principalmente orientado a Big Data e información que ellos pueden considerar útil para el público que esperan obtener de GitHub. Este caso es quizás el más interesante, puesto que un organismo público, que no tiene nada per sé que lo ligue al mundo del software, descubrió que puede alcanzar un gran público mediante Github, y no se equivocó, como pueden señalar algunos de sus proyectos con varios cientos de estrellas.

En conclusión

Git es una herramienta que nos permite una inmensa cantidad de posibilidades, no sólo a nivel de desarrollo como ya hemos observado, y que por ende debería ser manejada correctamente, así que te invito a aplicar alguna de estas prácticas, si es que no las aplicabas ya, y a buscar nuevas de ellas en diversos repositorios que alberga internet y puede que encuentres más de un tesoro escondido por allí.