Git para contribuidores open source

Si tu objetivo es lanzar un proyecto open source, contribuir en alguno o simplemente ampliar tu área de expertíz en el tema, uno de los requisitos indispensabes es el conocimiento y buen uso de git. En este post te proporcionaré una guía práctica para que te familiarices con los conceptos/herramientas más utilizados al participar en proyectos con otras personas.

Si tienes estás interesado en el proceso necesario para comenzar a contríbuir en proyectos open source, existe un post con los los tips necesarios para iniciar a ser parte de la comunidad, puedes verlo aquí.

¿Qué es git?

git es una herramienta que nos permite versionar proyectos, en palablras amigables, es una especie de bitacora en la que se van registrando todos los cambios que ha tenido un proyecto (también conocido como repositorio), cada entrada de la bitacora te permite saber qué persona agregó hizo ese cambio, cuándo lo hizo y qué información se modificó en el proyecto durante ese cambio.

Esto es muy útil para los proyectos open source, ya que si en algún momento el software deja de funcionar o presenta un error grave, rápidamente podemos buscar lá última entrada en la que el software funcionaba bien y sin mucha complicación podemos regresar el proyecto a ese punto.

git es una herramienta que va de la mano con la línea de comandos o terminal, aunque ya existen muchas aplicaciones visuales que te permiten utilizar esta herramienta.

git funciona perfectamente en ambientes locales (es decir, que no requieren internet), sin embargo, la magia comienza cuando subes tu proyecto a alguna plataforma de git, cómo GitLab, BitBucket o GitHub, de esta manera le das la oportunidad a todas las personas de que contribuyan o colaboren en tu proyecto.

Conceptos importantes

Puedes adentrarte en git leyendo un poco en la documentación oficial, sin embargo, te anexo una lista de los comandos/conceptos que debes conocer si deseas contribuir en algún proyecto o open source.

Con la palábra plataforma nos refierimos al sistema que gestiona nuestros proyecto git en internet, las plataformas más conocidas son GitLab, BitBucket o GitHub.

• Fork: Cuando una persona sube un proyecto a alguna plataforma, se crea un repositorio cuyo propietario es la persona que sube el proyecto por primera vez.

Si alguien diferente al propietario desea modificar ese proyecto para agregar una mejora o corregir algún error, tiene que hacer una copia del repositorio del peril del propietario en su propio perfil, esto se conoce como fork.

La forma de llevar a cabo un fork varía dependiendo de la plataforma que se uitlice.

• Clone: Una vez que tienes un fork del proyecto en tu perfil, debes descargarlo en tu computadora, esto se conoce como clone.

Una vez que el proyecto ya está en tu computadora, puedes comenzar a trabajar con la mejora o corrección que el proyecto requiera.

• Branches: Una rama o branch es una especie de borrador que te permite realizar uno o muchos cambios en el proyecto, sin afectar el código original, una vez que has terminado tu borrador, puedes hacer que los cambios se combinen sobre el código original.

Una ventaja de usar ramas, es que te permite trabajar de manera "aislada", en la que no te afectarían los cambios que sufra el proyecto hasta que hayas temrinado tus cambios y tengas que combinar los códigos.

Regularmente, las únicas personas que tiene permiso de combinar códigos son los propietarios y administradores de un repositorio.

Un repositorio debe tener al menos una rama, la rama principal suele llamarse master, pero eso puede cambiar si el propietario lo desea.

Es recomendable que cada funcionalidad nueva o mejora de código se trabaje en su propia rama.

• Commit: En la analogía de la bitacora, un commit es una entrada en la bitácora, como se mencionó anteriormente, una entrada se compone de un autor, un mensaje personalizado que indica qué cambios se hicieron y un histórico de los archivos que se cambiaron al realizar alguna mejora o corrección, a excepción del mensaje personalizado, el resto de información lo gestiona git por nosotros.

Nota: Un cambio o mejora puede estar compuesto de uno o muchos commits, en dónde cada commit debe contener un cambio o mejora muy específica. Los commits pertenecen forzosamente a una rama.

• Pull: (Opcional pero recomendado)
  Dado que los repositorios tienden ser actualizados constantemente, probablemente el proyecto que tu estas trabajando haya sido actualizado mientras tu realizabas tu mejora o corrección. Para obtener los últimos cambios del proyecto debes descargarlos en tu computadora, esto se logra con el comando pull .

• Rebase: (Opcional pero recomendado)
  Rebase es uno de los comandos más importantes de git, el objetivo inicial es manipular la forma en la que los commits de tu proyecto fueron creados. Esto es un arma de doble filo, pero usada de manera correcta nos permite subir código con el menor (o nulo) número de afectaciones.

Cuando has terminado de realizar alguna modicicación es recomendable haver pull y actualizar el orden de los commits de tal manera que tus cambios se registren como los cambios los más nuevos. De esta manera, si algo saliera mal, podríamos facilmente regresar al commit anterior para corregir nuestro error.

• Squash commits: (Optional)
  Los repositorios open source suelen tener una sección Contributing en el archivo README.md con las reglas para agregar código al proyecto, muchos proyectos suelen pedirte que cada cambio debe ser en un solo commit. Si el cambio que realizaste tiene más de un commit, no te preocupes, puedes hacer uso de rebase interactivo para "combinar" todos tus commits en uno solo, ésta técnica se conoce como squash commits.

• Push:
  Cuando has finalizado tu mejora o corrección, es momento de subir tus cambios locales al repositorio remoto o plataforma, esta acción es conocida como push.

• Pull Request:
  Una vez que tus cambios ya se encuentran reflejados en el fork de tu repositorio en la plataforma correspondiente, es tiempo de solicitarle al propietario del proyecto que revise y/o acepte tus cambios. Ésta acción se conoce como pull request (o PR).

• Code review:
  Una vez que se ha creado un PR es tiempo de que los propietarios del repositorio revisen si tu cámbio es válido, si funciona correctamente y si tiene y cumple con los estándares del proyecto. El propietario o administrador puede tomar 3 acciones respecto a tu PR:

1. Solicitar cambios: Cuando el propietario detecta alguna anomalía o posibilidad de mejora, podrá solicitarte que realices algunos cambios para poder integrar tu pull request sin complicaciones posteriores. Ten un poco de paciencia, en especiál si no tienes mucha experiencia, ya que pueden pedirte muchos cambios o si tu PR es muy extenso, llevará tiempo revisarlo.
2. Rechazar cambios: Si el propietario considera que tu solución no es correcta, o que probablemente alguien más ya la solucionó, es probable que rechace tu solucitud, éste es el peor escenario, si es tu caso, no te decepciones por ello, los propietarios suelen dejar un muy buen comentario índicando la razón de rechazo.
3. Aceptar cambios: Si el código que propones cumple con las reglas del proyecto, incluye buenas prácticas y a demás soluciona algún problema o aporta alguna mejora, el propietario puede integrar tus cambios en el proyecto, inclusive si el propietario detecta algo que es muy sencillo de modifica, el tiene el poder para hacerlo, sin tener que pedirte cambios. Si llegas a éste punto, ¡felicidades!, muy pronto otras personas estarán disrutando de tus mejoras.

Conclusión

Saber usar git es el primer paso para adentrarte a participar el la construcción proyectos masivos, por ello es muy importante que le dediques un tiempo para aprender git. Te invito a que instales git en tu computadora (instrucciones en página oficial ) y pongas a prueba lo aprendido en éste blog. Puedes crear una cuenta totalmente gratuita en cualquiera de las plataformas mencionadas GitHub, BitBucket o GitLab y comenzar a hacer forks y pull requests.