Mejores Prácticas de Github

En este artículo te enseño las mejores prácticas utilizadas en el estandar internacional de las empresas más grandes del mundo como Microsoft. Si sigues estas recomendaciones tendrás la más alta calidad de repositorios posible.

Crea una branch complemento al Master desde el principio

git branch develop

git push -u origin develop

La rama develop contendrá el historial completo del proyecto, mientras que la rama master tendrá una versión resumida.

Los demás desarrolladores ahora deben clonar el repositorio central y crear una rama de seguimiento para develop:

git clone ssh://user@host/path/to/repo.git

git checkout -b develop origin/develop

Todos ahora tienen una copia local configurada con las ramas históricas.

Ejemlo de la vida real

En un escenario con dos desarrolladores trabajando en funciones separadas, ambos deben crear ramas distintas para sus respectivas funciones. En lugar de basarlas en master, ambos deben basar sus ramas de funcionalidades en develop:

git checkout -b some-feature develop

# Optionally, push branch to origin:
git push -u origin some-feature

Ambos agregan commits a su rama de funcionalidad de la manera habitual: editar, preparar (stage), y confirmar (commit):

git status

git add some-file

git commit

1era Feature completada

Después de agregar algunos commits, el Desarrollador #1 decide que su funcionalidad está lista. Si su equipo utiliza pull requests, este sería un buen momento para abrir uno solicitando fusionar su rama de funcionalidad con develop.

De lo contrario, puede fusionarla con su rama develop local y luego subir los cambios al repositorio central, de la siguiente manera:

# Make sure the develop branch is up to date
# Before trying to merge in the feature
git pull origin develop

git checkout develop

git merge --no-ff some-feature

git push origin develop

git branch -d some-feature

# If you pushed branch to origin:
git push origin --delete some-feature

Ten en cuenta que las funcionalidades nunca deben fusionarse directamente en la rama master.

1er Release

Mientras el Desarrollador # 2 sigue trabajando en su funcionalidad, el Desarrollador # 1 comienza a preparar la primera versión oficial del proyecto.Para ello, crea una nueva rama que encapsula los preparativos de la versión.

En este paso también se define el número de versión de la entrega, y el Desarrollador # 1 sigue la recomendación de SemVer para una versión inicial: v0.1.0.

git checkout -b release-0.1.0 develop

# Optional: Bump version number, commit
# Prepare release, commit

Esta rama sirve como un espacio para pulir la versión: hacer pruebas, actualizar la documentación y realizar cualquier otra preparación necesaria antes del lanzamiento. Es como una rama de funcionalidad, pero dedicada exclusivamente a perfeccionar la versión.

En cuanto el Desarrollador # 1 crea esta rama y la sube al repositorio central, la versión queda congelada en cuanto a funcionalidades.Cualquier nueva funcionalidad que no esté ya en develop se pospone para el siguiente ciclo de lanzamiento.

1er Release Fin de Fase

Una vez que la versión está lista para ser publicada, el Desarrollador # 1 la fusiona tanto en master como en develop, y luego elimina la rama de lanzamiento (release).

Es importante fusionar también en develop porque podrían haberse realizado actualizaciones críticas en la rama de lanzamiento que deben estar disponibles para el desarrollo de nuevas funcionalidades.

Nuevamente, si la organización del Desarrollador # 1 da prioridad a la revisión de código (code review), este sería un momento ideal para crear un pull request.

# Merges into Master
git checkout master

git merge --no-ff release-0.1.0

git push

# Merges into Develop
git checkout develop

git merge --no-ff release-0.1.0

git push

# Deletes the Release Branch
git branch -d release-0.1.0

# If you pushed branch to origin:
git push origin --delete release-0.1.0

Las ramas de lanzamiento (release branches) actúan como un búfer entre el desarrollo de funcionalidades (develop) y las versiones públicas (master).

Siempre que fusiones algo en master, debes etiquetar el commit correspondiente para facilitar su referencia.

git tag -a v0.1.0 master

git push --tags

---

Pro Tip: Git incluye varios hooks, que son scripts que se ejecutan automáticamente cuando ocurre un evento específico dentro de un repositorio.

Es posible configurar un hook para que construya automáticamente una versión pública cada vez que haces push a la rama master o cuando se sube una etiqueta (tag) al repositorio central.

Por ejemplo, puedes usar el hook post-receive en el servidor para detectar estos eventos y lanzar un proceso de build o despliegue. También puedes integrarlo con herramientas como Jenkins, GitHub Actions o GitLab CI/CD para automatizar completamente la publicación.

El usuario final Descubre un Bug

Después de publicar la versión, el Desarrollador # 1 vuelve al desarrollo de nuevas funcionalidades junto con el Desarrollador # 2 para la siguiente versión.

Pero entonces, un usuario final abre un ticket reportando un bug en la versión actual.

Para resolverlo, el Desarrollador # 1 (o el Desarrollador # 2) crea una rama de mantenimiento a partir de master, corrige el problema con los commits necesarios, y luego fusiona directamente esa rama de mantenimiento de vuelta en master.

git checkout -b hotfix-0.1.1 master

# Optional: Bump version number, commit
# Fix the bug, commit

git checkout master

git merge --no-ff hotfix-0.1.1

git push

Al igual que las ramas de lanzamiento, las ramas de mantenimiento contienen actualizaciones importantes que deben incluirse en develop, por lo que el Desarrollador # 1 también debe realizar esa fusión. Luego, es libre de eliminar la rama.

git checkout develop

git merge --no-ff hotfix-0.1.1

git push

git branch -d hotfix-0.1.1

Al igual que en la rama de lanzamiento, el Desarrollador # 1 ha fusionado en master, por lo que necesita etiquetar el commit en la rama master. Al incrementar el número de parche (patch), indica que se trata de una versión de mantenimiento sin cambios incompatibles.

git tag -a v0.1.1 master

git push --tags

README.md Labels

Una vez que subas un proyecto, debes establecer etiquetas relacionadas con las versiones, tecnologías y lenguajes que utilizaste en tu proyecto. Por lo tanto, debes ingresar a la siguiente página:

🔗 https://shields.io/

Luego, navega hacia la mitad de la página y escribe la etiqueta, la versión y el color de tu ícono de la siguiente manera:

Luego haz clic en "Make Badge", para obtener la etiqueta, y copia la URL que shields.io generó.

Ve a tu archivo README.md y pégalo de esta manera.

![Java Script ES6](https://img.shields.io/badge/Java%20Script-ES6-red)

Guárdalo y ¡voilá! se mostrará una bonita etiqueta.

Redactado por Jackson Grim

Investigador de tecnología, privacidad y vigilancia digital

📩 jackson.grim@redboyconsulting.com