Git para contribuidores open source
Tags: opensource
Published: 2020-06-17 15:31:49


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í](https://dev.to/javleds/que-necesito-para-contribuir-al-codigo-open-source-2lag). 

## ¿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`.