DEV Community: Fernando Ayon

☕ Git-Flow : premiers pas

Fernando Ayon — Mon, 08 Jun 2020 20:16:36 +0000

🇬🇧 English version
🇪🇸 Version en español

Tu as un nouveau job ou tu prévois de mettre en place Git-Flow dans tes projets, mais tu ne sais pas trop ce que c'est ? Tu es au bon endroit.

Dans cet article, je vais te l'expliquer, mais si tu connais déjà un peu le principe ou alors si tu veux uniquement des indications sur son utilisation, passe directement au tutoriel.

🧐 Le Contexte

En quelques mots, Git est un système de gestion de versions pour software, c'est un outil indispensable pour contrôler le cycle de vie du développement d'une application.

Jusqu'ici tout va bien, mais les problèmes commencent à apparaître lorsque l'on travaille en équipe : vous pouvez décider de travailler uniquement sur la branche principale du projet et de créer des branches secondaires lors d'occasions spéciales. Mais que se passe-t-il lorsqu'il y a beaucoup de travail ou lorsque plusieurs personnes doivent travailler sur la même chose en même temps ?

📓 Git-Flow

Dès que nous travaillons en équipe, il est nécessaire de définir des conventions ou des bonnes pratiques pour que nous puissions travailler ensemble. Git-Flow est l'un des nombreux outils que nous qualifions de workflows. C'est un moyen d'organiser les branches du projet, assez populaire de part sa praticité et son apprentissage relativement rapide.

Tu as probablement déjà vu cette image ou une image similaire lors d'une recherche du terme Git-Flow sur Internet:
Git-Flow

Cela semble et est compliqué à première vue, mais dès que nous connaissons les différentes branches utilisées et la raison de leur existence, tu verras que leur fonctionnement est assez logique.

🌳 Branches

Comme nous l'avons vu dans l'image, Git-Flow utilise plusieurs branches pour organiser le développement:

master
develop
feature
release
hotfix

🌴 master et develop

Si tu as déjà utilisé Git, tu connais forcément la branche master. Dans ce nouveau contexte, cette branche est "intouchable", aucun membre de l'équipe ne doit y apporter de modifications directement, ni en créer de nouvelles, à une exception que nous verrons plus tard.

Lors de la création d'un nouveau projet, ou lorsque tu commences à utiliser Git-Flow, la branche develop doit être créée à partir de master, et comme master, la branche develop ne sera jamais supprimée et vivra en parallèle.

Comme son nom l'indique, la branche develop sert de base au développement de toutes les nouvelles fonctionnalités et corrections du projet, c'est pourquoi elle est considérée comme la branche principale.

Une fois que toutes les nouvelles fonctions et corrections prévues du projet sont terminées et que develop est stable, on peut faire un merge de develop dans master.

La branche master doit toujours refléter un état 'en production', il est donc important de ne pas y apporter de modifications directement, car chaque fois qu'il y a un nouveau commit, on doit faire un tag pour définir la nouvelle version et la publier. C'est pourquoi on appellera la branche master comme la 'branche d'intégration'.

💯 feature

Les branches feature sont celles que nous devons consacrer entièrement au développement de chacune des nouvelles fonctionnalités du projet dans sa prochaine version. Elles partent toujours de develop et à la fin du développement on doit les merger de retour sur develop.

Si nous suivons les bonnes pratiques de Git-Flow, lors de la création d'une nouvelle branche feature, nous devons toujours ajouter le préfixe feature/*, de cette façon nous pouvons maintenir une bonne organisation et si nous regardons les branches actives nous pouvons rapidement identifier le travail en cours.

Il est très important de nommer les branches feature de manière descriptive pour identifier le but de la branche :

❌ feature/new-method
✔️ feature/add-support-for-json-parsing

Ce qu'il faut retenir est que les branches feature ne vivent que pendant le développement et qu'elles disparaissent une fois qu'on fait le merge du développement ou alors nous pouvons les supprimer si la fonction en développement n'est plus nécessaire, par exemple dans le cas des fonctions expérimentales.

NOTE: le préfixe feature/* est la pratique par défaut, mais si ton équipe et toi le jugent nécessaire, vous pouvez adapter le préfixe à une autre chose, par exemple : fonction/*

⭐ release

Les branches release sont utilisées pour regrouper les fonctionnalités et les corrections apportées pour préparer la sortie de la version en développement. Elles partent de develop et le merge doit se faire à la fois dans develop et dans master.

Le moment idéal pour créer les branches release est lorsque la branche develop est aussi similaire que possible à ce que nous voulons avoir en production, c'est un moyen de faire des petites corrections oubliées de dernière minute, ou de faire des méta-changements au projet qui n'ont pas lieu sur une branche feature, par exemple, pour augmenter le numéro de version.

Si nous suivons les bonnes pratiques de Git-Flow, les branches release ont également un préfixe, release/* ou release-*, généralement suivi du numéro de version ou du nom qu'elles représentent, par exemple, release/1.2.0 ou release/5.0 ou encore release/1.0.0-rc.1+build.123.

L'avantage des branches release est que le travail peut se poursuivre sur la branche develop et d'autres nouvelles features, car le travail prévu pour la nouvelle version est déjà présent dans la branche release et n'aura pas de changements majeurs.

🛠️ hotfix

Les branches hotfix partent de master et nous devons faire le merge de retour dans master et develop. Elles sont utilisées pour apporter des corrections rapides au projet, afin de publier une nouvelle version dès que possible.

NOTE: Si nous créons une branche hotfix mais qu'il y a déjà une branche release, au lieu de faire le merge dans develop, nous devons le faire dans master et dans la release.

⚔️ hotfix vs bugfix

Dans certains projets, tu pourras trouver qu'en plus des branches hotfix, il y en a parfois quelques-unes avec le préfixe bugfix. La différence entre ces deux types de branches est que les bugfix se comportent comme les branches feature et les hotfix se comportent comme les branches release.

Autrement dit, tu peux utiliser les bugfix pour apporter des corrections de bugs mineurs qui peuvent attendre la sortie de la version en développement, tandis que les hotfix ne peuvent pas attendre et doivent être publiées dès que le développement soit approuvé.

✔️ bugfix/fix-some-thingy-that-almost-nobody-uses-and-its-not-really-important
✔️ hotfix/fix-clic-on-top-right-corner-of-login-button-sets-the-users-computer-on-fire

✏️ Tutoriel

Pour ce tuto et afin de le simplifier au maximum, j'utiliserai le plugin de console Git-Flow de Peter van der Does, mais je te laisse ici les commandes Git classiques équivalentes aux commandes Git-Flow.

Activer Git-Flow sur le projet

# Cette commande active Git sur le projet, elle crée aussi la branche develop et 
# permet de configurer les préfixes des autres branches.
# Enfin, elle fait un check out de la branche develop
git flow init

Commencer à travailler sur une nouvelle fonctionnalité
```
# Cette commande crée une nouvelle branche feature/* et fait un check out sur la branche
git flow feature start <feature-name>
```
Tu peux voir comment la console nous indique les actions effectuées et que nous pouvons commencer à travailler sur la nouvelle branche.

Terminer une fonctionnalité

 # Le nom de la feature est optionnel, il n'est pas nécessaire de le préciser si
 # on est déjà positionnés sur la branche.
 # La commande fait un check out de develop et fait un merge vers develop
 # Enfin, elle supprime la branche feature
 git flow feature finish <feature-name>

NOTE: Toutes ces actions sont effectuées dans votre dépôt local, rien n'est fait dans le dépôt distant, sauf si tu fais un push. Alors n'oublie pas de faire un push lors de la finalisation de ton travail local sur tes features, pour mettre à jour develop.

Préparation de la nouvelle version
```
# Cette commande crée une nouvelle branche release/* à partir de develop et fait un check out de la branche.
git flow release start <version-name>
```
NOTE: Le moment parfait pour publier la branche release dans le dépôt distant c'est juste après la mise à jour du numéro de version de ton projet (et la validation du code, évidemment).

Finaliser la version

# Cette commande fait un check out de la branche master
# Ensuite, fait un merge de la branche release
# Elle crée le tag de la version sur master avec le nom de la branche release
# Elle fait un check out de la branche develop
# Ensuite un merge de la release sur develop
# Enfin, la branche release est supprimée
git flow release finish

# N'oublie pas d'envoyer ces derniers changements vers le dépôt distant avec les commandes classiques de Git :
git push origin master
git push origin develop
git push --tags
git push origin :release/<version> (seulement si la release existait déjà dans le dépôt distant)

Création d'un hotfix

# Cette branche peut être créée à partir d'un commit spécifique ou alors du dernier commit.
# Cette commande crée une branche hotfix et fait un check out sur la nouvelle branche
git flow hotfix start <hotfix-name> [<commit>]

Finalisation d'un hotfix

# Cette commande effectue les mêmes actions que pour une release
# N'oublie pas de spécifier l'option -T ou --tagname
# pour créer un tag correctement si le nom de ta
# branche hotfix n'est pas un numéro de version.
git flow hotfix finish [<-T version-name>]

Et pour la suite...

Dans un prochain article, nous parlerons d'autres stratégies, mais si tu veux approfondir le sujet de Git-Flow, voici quelques sources que j'ai utilisées pour cet article.

A successul Git branching model: L'article d'origine de Git-Flow
Git-Flow cheat sheet: Un coup d’œil sur les commandes Git-Flow.
GitFlow considered harmful: Une alternative plus simple à Git-Flow et un avant-goût du sujet de mon prochain article.

☕ Git-Flow: an introduction

Fernando Ayon — Mon, 08 Jun 2020 16:53:52 +0000

🇪🇸 Version en español
🇫🇷 Version française

Got a new job or in your current one they are planning to implement Git-Flow and you don't know what the fuss is all about?

You've come to the right place. In this post I'll break it down for you, however, if you already know it and just want to tinker around with it, you can just skip to the tutorial.

🧐 The Context

In a few words, Git is a version control system, an essential tool to handle the life cycle of the development of an application.

So far so good, classic Git, but problems start showing up when handling teamwork: you and your team might decide to just work on the main branch of the project and create some secondary branches on special occasions, but what happens when there is a lot of work or several people must work in the same function at the same time?

📓 Git-Flow

When working as a team, it is necessary to define conventions or good practices so that everyone knows how to work together. Git-Flow is one of many so-called workflows, quite popular for its practicality and relatively quick learning, it is a way to organize the branches of the project repository.

You have probably already seen this image or a similar one when searching the term Git-Flow on the Internet:
A picture is worth a thousand words, or in this case a couple thousand more

It seems and is complicated at first glance, but when you know the different branches used and the reason for their existence, you will see that the handling is quite logical.

🌳 Branches

As we saw in the image, Git-Flow uses several branches to organize the development:

master
develop
feature
release
hotfix

🌴 master & develop

If you have used Git before, you will be familiar with the master branch. In this new context, this branch is "untouchable", no one from the team should make any changes directly to it, nor create new branches from it, with one exception that we will review later.

When creating a new project, or when starting to use Git-Flow, the develop branch must be created frommaster, and like master, it will be a "long-lived branch", that is, it will never be deleted and will be parallel to master.

As its name implies, the develop branch serves as the basis for working on all new project features and fixes, which is why it is considered the main branch.

Once all the new project functions & bugfixes have been completed and develop is on a rather 'stable' state, we should merge develop in master.

The master branch should always reflect an 'production' state, so it is important that we do not make changes directly to it, since every time there is a new commit, we should tag it to define the new version and publish it. In this context the master branch is sometimes referred to as the 'integration' branch.

💯 feature

The feature branches are those that we dedicate completely to the development of each of the new planned functions to be added to the project in the next version. They come always from develop and we must merge 'em back to develop.

Following Git-Flow best practices, when creating a new feature branch, we must always add the prefix feature/, in this way we can maintain a good organization and just by looking at the active branches we can quickly identify the work in progress.

At the same time, it is important to name the feature branches in a descriptive way to identify the purpose of the branch:

❌ feature/new-method
✔️ feature/add-support-for-json-parsing

The important thing about feature branches is that they only live during development and that they should disappear once we have done the merge in develop or that they are discarded if the function is no longer necessary.

NOTE: the prefix feature/* is the default, but if you or your team deem it necessary, you can adapt the prefix to anything else, for example function/*

⭐ release

The release branch is used to regroup the functionalities and corrections made, to prepare for the release of the version in development. This branch starts from develop and must be merged in both develop and master.

The perfect time to create a release branch is when the develop branch looks as much as possible to what we want to have in production, it provides then a moment to make last minute corrections that we may have forgotten, or to make changes of the project that do not necessarily need a whole branch to be carried out, for example to increase the version number.

Following Git-Flow, release branches also have a prefix, release/* or release-*, usually followed by the version number or name they represent, for example: release/1.2.0 or release/5.0 or release/1.0.0-rc.1+build.123.

The advantage of having a release branch is that work can continue in develop and we can create other new feature branches, since the planned work is already in the release one and will ~~should~~ not have major changes.

🛠️ hotfix

The hotfix branches come from master and must be merged back in master and develop. They are used to make quick or critical corrections to the project, in order to publish a new version as soon as possible.

NOTE: If you create a hotfix branch but there is already a release branch, instead of doing the merge in develop, it must be merged in master and release instead.

⚔️ hotfix vs bugfix

In some projects we can see that in addition to the hotfix branches, sometimes we have some branches with the bugfix prefix. The difference between these two types of branches is that the bugfix ones behave like features and the hotfix ones behave like releases.

In other words, we can use the bugfixes to make minor bug fixes that can wait for the release of the development version, while the hotfixes cannot wait and should be published as soon as the development has been approved.

✔️ bugfix/fix-some-thingy-that-almost-nobody-uses-and-its-not-really-important
✔️ hotfix/fix-clic-on-top-right-corner-of-login-button-sets-the-users-computer-on-fire

✏️ Tutorial

For this tutorial and in order to simplify it, I will use the Git-Flow console plugin of Peter van der Does, but you can also see the equivalent classic Git commands to Git-Flow commands.

Initialize Git-Flow in the project

# Initialize Git in the project, create the develop branch and
# configure the prefixes of the other branches.
# Then, switch to the develop branch
git flow init

Starting to work on a new feature
```
# Creates a new feature/* branch and starts pointing to it
git flow feature start <feature-name>
```
We can see how the console tells us the actions performed and that we can start working on the new branch.

Finish a feature

# The name of the feature is optional, not really necessary if
# you are already on the branch.
# Changes to develop, performs a merge of the feature to develop
# And deletes the feature branch
git flow feature finish <feature-name>

NOTE: All these actions are performed in your local repository, nothing is done in the distant one, unless you push the branches. Always remember to push when you finish your features, to update develop.

Prepare for the new version
```
# Creates a new release/* branch from develop y change the pointer to it
git flow release start <version-name>
```
NOTE: Right after updating the version number of your project it is a good time to publish the release branch in origin.

Finishing the release

# Checks out the master branch
# Merges the release in master
# Creates the version tag using the name of the release branch
# Checks out the develop branch
# Merges the release in develop
# Deletes the release branch
git flow release finish

# Don't forget to push!
git push origin master
git push origin develop
git push --tags
git push origin :release/1.2.0 (if the release was in the distant repo)

Creating a hotfix

# A hotfix branch may be created from a specific commit or from the last commit if not specified.
# Creates a hotfix branch and checks it out
git flow hotfix start <hotfix-name> [<commit>]

Finish a hotfix

# Same behavior as the release branches
# You can also specify the option -T or --tagname
# to create the tag correctly if the name of your
# hotfix branch is not a version number.
git flow hotfix finish [<-T version-name>]

Next steps

For the next article, we will talk about other strategies, but if you want to learn more about Git-Flow at the moment, here are some sources that I used for this article.

A successul Git branching model: The original article from the author of Git-Flow
Git-Flow cheat sheet: The essential Git-Flow cheat sheet
GitFlow considered harmful: A simpler alternative to Git-Flow and the subject of my next article.

☕ Git-Flow: Lo Esencial

Fernando Ayon — Mon, 08 Jun 2020 09:47:40 +0000

🇬🇧 English version
🇫🇷 Version française

¿Tienes un nuevo empleo o en tu trabajo actual están planeando implementar Git-Flow y no sabes de qué se trata?

Has venido al lugar indicado. En este post te lo explico, pero si ya lo conoces un poco y solo quieres indicaciones sobre su uso, salta al tutorial.

🧐 Contexto

En pocas palabras, Git es un sistema de gestión de versiones, es una herramienta indispensable para controlar el ciclo de vida del desarrollo de una aplicación.

Hasta aquí todo bien, pero los problemas empiezan a aparecer cuando se trabaja en equipo: tú y tu equipo podrían decidir de simplemente trabajar en la rama principal del proyecto y crear algunas ramas secundarias en ocasiones especiales, pero ¿qué pasa cuando hay mucho trabajo o varias personas deben trabajar en la misma función al mismo tiempo?

📓 Git-Flow

Al trabajar en equipo, es necesario definir convenciones o buenas practicas para que todos sepan como trabajar juntos. Git-Flow es uno de muchos de los llamados flujos de trabajo, bastante popular por su practicidad y aprendizaje relativamente rápido, es una manera de organizar las ramas del repositorio del proyecto.

Probablemente ya has visto esta imagen o una parecida al buscar el término Git-Flow en Internet:
Git-Flow en una imagen

Parece y es complicado a primera vista, pero al conocer las diferentes ramas utilizadas y el por qué de su existencia veras que su funcionamiento es bastante lógico.

🌳 Ramas

Como ya vimos en la imagen, Git-Flow utiliza varias ramas para organizar el desarrollo:

master
develop
feature
release
hotfix

🌴 master y develop

Si ya has utilizado Git antes, estarás familiarizado con la rama master. En este nuevo contexto, esta rama es "intocable", nadie del equipo debe hacer ningún cambio directamente en ella, ni crear nuevas ramas a partir de ella, con una excepción que veremos más adelante.

Al crear un nuevo proyecto, o al momento de comenzar a utilizar Git-Flow, la rama develop debe ser creada a partir de master, y al igual que master, sera una rama de "larga duración de vida", es decir, nunca sera borrada y vivirá paralelamente a master.

Como su nombre lo indica, la rama develop sirve como base para desarrollar todas las nuevas funciones y correcciones del proyecto, por eso es considerada como la rama principal.

Una vez que todas las nuevas funciones del proyecto han sido completadas y develop es estable, debemos hacer un merge de develop en master.

La rama master debe reflejar siempre un estado 'en producción', por eso es importante que no realicemos cambios directamente en ella, ya que cada vez que hay un nuevo commit, deberíamos hacer un tag para definir la nueva versión y publicarla.

💯 feature

Las ramas feature son aquellas que dedicamos completamente al desarrollo de cada una de las nuevas funciones que agregaremos al proyecto en la versión siguiente. Siempre parten de develop y debemos hacer el merge de regreso a develop.

Si seguimos las buenas practicas de Git-Flow, al crear una nueva rama feature, siempre debemos agregar el prefijo feature/, de esta manera podemos mantener una buena organización y al ver las ramas activas podremos identificar rápidamente el trabajo en curso.

Al mismo tiempo, es importante nombrar las ramas feature de una forma descriptiva que permita identificar la finalidad de la rama:

❌ feature/new-method
✔️ feature/add-support-for-json-parsing

Lo importante de las ramas feature es que vivan solamente durante el desarrollo y que desaparezcan una vez que hayamos realizado el merge en develop o que sean descartadas si la función ya no es necesaria.

NOTA: el prefijo feature/* es la practica por defecto, pero si tu o tu equipo lo estiman necesario, pueden adaptar el prefijo a cualquier otra cosa, por ejemplo funcionalidad/...

⭐ release

La rama release sirve para reagrupar las funcionalidades y correcciones efectuadas para poder preparar el lanzamiento de la versión en desarrollo. Esta rama parte de develop y el merge se hace tanto en develop como en master.

El momento perfecto para crear las ramas release es cuando la rama develop se asemeja lo mas posible a lo que queremos tener en producción, es una manera para poder hacer las correcciones de ultimo minuto que pudimos haber olvidado, o para realizar cambios del proyecto que no necesariamente necesitan toda una rama para ser realizados, por ejemplo para aumentar el numero de versión.

Siguiendo las practicas de Git-Flow, las ramas release también tienen un prefijo, release/* o release-*, normalmente seguido del numero o nombre de la versión que representan, por ejemplo: release/1.2.0 o release/5.0 o release/1.0.0-rc.1+build.123.

La ventaja de tener una rama release es que el trabajo puede continuar en develop y otras nuevas ramas feature, ya que el trabajo planeado ya se encuentra en la release y no va a tener cambios importantes.

🛠️ hotfix

Las ramas hotfix parten de master y debemos realizar el merge de vuelta en master y develop. Son utilizadas para realizar correcciones rápidas al proyecto, para poder publicar una nueva version lo antes posible.

NOTA: Si creamos una rama hotfix pero ya existe una rama release, en lugar de hacer el merge en develop, debemos hacer el merge en master y release.

⚔️ hotfix vs bugfix

En algunos proyectos podemos ver que ademas de las ramas hotfix, a veces tenemos algunas con el prefijo bugfix. La diferencia entre estos dos tipos de ramas es que las bugfix se comportan como las feature y las hotfix se comportan como las release.

Visto de otra manera, podemos utilizar las bugfix para realizar correcciones de bugs no muy importantes que pueden esperar al lanzamiento de la versión en desarrollo, mientras que las hotfix no pueden esperar y deben ser publicadas en cuanto el desarrollo haya sido aprobado.

✔️ bugfix/fix-some-thingy-that-almost-nobody-uses-and-its-not-really-important
✔️ hotfix/fix-clic-on-top-right-corner-of-login-button-sets-the-users-computer-on-fire

✏️ Tutorial

Para este tutorial y con el fin de simplificarlo al maximo, utilizaré el plugin para consola de Git-Flow de Peter van der Does, pero aquí te dejo los comandos clásicos Git equivalentes a los comandos de Git-Flow.

Habilitar Git-Flow en el proyecto

# Inicia Git en el proyecto, crea la rama develop y 
# configura los prefijos de las otras ramas.
# Finalmente, cambia a la rama develop
git flow init

Comenzar a trabajar en una nueva funcionalidad
```
# Crear una nueva rama feature/* y cambiarse a ella
git flow feature start <feature-name>
```
Podemos ver como la consola nos dice las acciones efectuadas y que podemos comenzar a trabajar en la nueva rama.

Terminar una funcionalidad

# El nombre de la feature es opcional, no es necesario si
# ya nos encontramos en la rama.
# Cambia a develop, hace un merge de la feature hacia develop
# Y elimina la rama feature
git flow feature finish <feature-name>

NOTA: Todas estas acciones son realizadas en tu repositorio local, nada en el distante, a menos que realices un push. Recuerda hacerlo al terminar tus features, para actualizar develop.

Preparar la nueva versión
```
# Crea una nueva rama release/* desde develop y cambia a ella.
git flow release start <version-name>
```
NOTA: Justo después de actualizar el numero de versión de tu proyecto es un buen momento para publicar la rama release en origin.

Terminar la versión

# Cambia a la rama master
# Hace un merge de la release
# Crea el tag de la versión utilizando el nombre de la rama
# Cambia a la rama develop
# Hace un merge de la release
# Elimina la rama release
git flow release finish

# No olvides enviar los últimos cambios a `origin` utilizando los comandos clásicos de Git
git push origin master
git push origin develop
git push --tags
git push origin :release/1.2.0 (si la release estaba en el repo distante)

Crear un hotfix

# Puede ser creada a partir de un commit específico o simplemente del ultimo existente.
# Crea una rama hotfix y cambia a ella
git flow hotfix start <hotfix-name> [<commit>]

Finalizar un hotfix

# Ocurre lo mismo que en una release
# No olvides especificar el argumento -T o --tagname
# para crear un tag correctamente si el nombre de tu
# rama hotfix no es un numero de versión.
git flow hotfix finish [<-T version-name>]

Siguientes pasos

En un siguiente articulo, hablaremos de otras estrategias, pero si por el momento quieres aprender mas sobre Git-Flow, aquí te dejo algunas fuentes que utilicé para este articulo.

A successul Git branching model: El articulo original del creador de Git-Flow
Git-Flow cheat sheet: Un vistazo rápido sobre los comandos de Git-Flow
GitFlow considered harmful: Una alternativa mas simple a Git-Flow y una probada de lo que vamos a ver en el próximo articulo.