Un flux de travail Git est une recette ou une recommandation sur la façon d’utiliser Git pour accomplir un travail de manière cohérente et productive. Les workflows Git encouragent les utilisateurs à exploiter Git de manière efficace et cohérente. Git offre beaucoup de flexibilité dans la façon dont les utilisateurs gèrent les changements. Étant donné l’accent mis sur la flexibilité de Git, il n’existe pas de processus standardisé sur la façon d’interagir avec Git. Lorsque l’on travaille avec une équipe sur un projet géré par Git, il est important de s’assurer que l’équipe est d’accord sur la façon dont le flux de changements sera appliqué. Pour s’assurer que l’équipe est sur la même longueur d’onde, un flux de travail Git convenu doit être développé ou sélectionné. Il existe plusieurs flux de travail Git publiés qui peuvent convenir à votre équipe. Ici, nous allons discuter de certaines de ces options de flux de travail.

L’éventail des flux de travail possibles peut rendre difficile de savoir par où commencer lors de la mise en œuvre de Git sur le lieu de travail. Cette page fournit un point de départ en passant en revue les flux de travail Git les plus courants pour les équipes logicielles.

Au fil de votre lecture, rappelez-vous que ces flux de travail sont conçus pour être des lignes directrices plutôt que des règles concrètes. Nous voulons vous montrer ce qui est possible, afin que vous puissiez mélanger et assortir les aspects de différents flux de travail pour répondre à vos besoins individuels.

Qu’est-ce qu’un flux de travail Git réussi ?

Lorsque vous évaluez un flux de travail pour votre équipe, il est plus important que vous considériez la culture de votre équipe. Vous voulez que le flux de travail améliore l’efficacité de votre équipe et ne soit pas un fardeau qui limite la productivité. Voici quelques éléments à prendre en compte lors de l’évaluation d’un workflow Git :

• Ce workflow s’adapte-t-il à la taille de l’équipe ?
• Est-il facile de défaire les erreurs et les fautes avec ce workflow ?
• Ce workflow impose-t-il une nouvelle charge cognitive inutile à l’équipe ?

Flux centralisé

Le flux de travail centralisé est un excellent flux de travail Git pour les équipes en transition depuis SVN. Comme Subversion, le flux de travail centralisé utilise un référentiel central pour servir de point d’entrée unique pour toutes les modifications apportées au projet. Au lieu de trunk, la branche de développement par défaut s’appelle master et toutes les modifications sont commises dans cette branche. Ce flux de travail ne nécessite pas d’autres branches que master.

La transition vers un système de contrôle de version distribué peut sembler une tâche ardue, mais vous n’avez pas à modifier votre flux de travail existant pour tirer parti de Git. Votre équipe peut développer des projets exactement de la même manière qu’elle le fait avec Subversion.

Toutefois, l’utilisation de Git pour alimenter votre flux de développement présente quelques avantages par rapport à SVN. Premièrement, il donne à chaque développeur sa propre copie locale de l’ensemble du projet. Cet environnement isolé permet à chaque développeur de travailler indépendamment de toutes les autres modifications apportées à un projet – ils peuvent ajouter des commits à leur dépôt local et oublier complètement les développements en amont jusqu’à ce que cela leur convienne.

Deuxièmement, il vous donne accès au modèle de branchement et de fusion robuste de Git. Contrairement à SVN, les branches Git sont conçues pour être un mécanisme à sécurité intégrée pour l’intégration du code et le partage des modifications entre les dépôts. Le flux de travail centralisé est similaire aux autres flux de travail dans son utilisation d’un dépôt distant hébergé côté serveur que les développeurs poussent et tirent. Par rapport aux autres flux, le flux centralisé n’a pas de modèle défini de demande d’extraction ou de bifurcation. Un flux de travail centralisé est généralement mieux adapté aux équipes qui migrent de SVN vers Git et aux équipes de petite taille.

Comment ça marche

Les développeurs commencent par cloner le dépôt central. Dans leurs propres copies locales du projet, ils éditent les fichiers et livrent les modifications comme ils le feraient avec SVN ; cependant, ces nouveaux commits sont stockés localement – ils sont complètement isolés du dépôt central. Cela permet aux développeurs de différer la synchronisation en amont jusqu’à ce qu’ils se trouvent à un point de rupture commode.

Pour publier des changements dans le projet officiel, les développeurs « poussent » leur branche locale master vers le dépôt central. C’est l’équivalent de svn commit, sauf qu’il ajoute tous les commits locaux qui ne sont pas déjà dans la branche centrale master.

Initialiser le dépôt central

D’abord, quelqu’un doit créer le dépôt central sur un serveur. Si c’est un nouveau projet, vous pouvez initialiser un dépôt vide. Sinon, vous devrez importer un dépôt Git ou SVN existant.

Les dépôts centraux doivent toujours être des dépôts nus (ils ne doivent pas avoir de répertoire de travail), qui peuvent être créés comme suit :

ssh user@host git init --bare /path/to/repo.git

Veillez à utiliser un nom d’utilisateur SSH valide pour user, le domaine ou l’adresse IP de votre serveur pour host, et l’emplacement où vous souhaitez stocker votre repo pour /path/to/repo.git. Notez que l’extension .git est conventionnellement ajoutée au nom du dépôt pour indiquer qu’il s’agit d’un dépôt nu.

Dépôts centraux hébergés

Les dépôts centraux sont souvent créés via des services d’hébergement Git tiers comme Bitbucket Cloud ou Bitbucket Server. Le processus d’initialisation d’un dépôt nu discuté ci-dessus est géré pour vous par le service d’hébergement. Le service d’hébergement fournira ensuite une adresse pour le dépôt central à laquelle vous pourrez accéder depuis votre dépôt local.

Cloner le dépôt central

Puis, chaque développeur crée une copie locale de l’ensemble du projet. Ceci est accompli via la commande git clone:

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

Lorsque vous clonez un dépôt, Git ajoute automatiquement un raccourci appelé origin qui renvoie au dépôt « parent », en partant du principe que vous voudrez interagir avec lui plus tard sur la route.

Effectuer des modifications et commettre

Une fois que le dépôt est cloné localement, un développeur peut effectuer des modifications en utilisant le processus de commit standard de Git : modifier, mettre en scène et commiter. Si vous n’êtes pas familier avec la zone de staging, c’est un moyen de préparer un commit sans avoir à inclure chaque changement dans le répertoire de travail. Cela vous permet de créer des commits très ciblés, même si vous avez effectué de nombreuses modifications locales.

git status # View the state of the repo git add # Stage a file git commit # Commit a file

Rappellez-vous que puisque ces commandes créent des commits locaux, John peut répéter ce processus autant de fois qu’il le souhaite sans se soucier de ce qui se passe dans le référentiel central. Cela peut être très utile pour les grandes fonctionnalités qui doivent être décomposées en morceaux plus simples et plus atomiques.

Pousser les nouveaux commits vers le dépôt central

Une fois que le dépôt local a de nouveaux changements commis. Ces changements devront être poussés pour être partagés avec les autres développeurs du projet.

git push origin master

Cette commande poussera les nouveaux changements commis vers le dépôt central. Lors du push des changements vers le dépôt central, il est possible que des mises à jour d’un autre développeur aient été précédemment poussées et contiennent du code qui entre en conflit avec les mises à jour prévues par le push. Git produira un message indiquant ce conflit. Dans cette situation, git pull devra d’abord être exécuté. Ce scénario de conflit sera développé dans la section suivante.

Gestion des conflits

Le dépôt central représente le projet officiel, donc son historique de commit doit être traité comme sacré et immuable. Si les commits locaux d’un développeur divergent du dépôt central, Git refusera de pousser ses modifications car cela écraserait les commits officiels.

Avant que le développeur puisse publier sa fonctionnalité, il doit récupérer les commits centraux mis à jour et rebaser ses changements par-dessus. Cela revient à dire : « Je veux ajouter mes modifications à ce que tout le monde a déjà fait ». Le résultat est un historique parfaitement linéaire, tout comme dans les flux de travail SVN traditionnels.

Si les changements locaux entrent directement en conflit avec les commits amont, Git mettra en pause le processus de rebasement et vous donnera une chance de résoudre manuellement les conflits. Ce qui est bien avec Git, c’est qu’il utilise les mêmes git status et git add commandes à la fois pour générer des commits et pour résoudre les conflits de fusion. Cela permet aux nouveaux développeurs de gérer facilement leurs propres fusions. De plus, s’ils se retrouvent en difficulté, Git permet très facilement d’interrompre toute la rebase et de réessayer (ou d’aller chercher de l’aide).

Exemple

Prenons un exemple général de la façon dont une petite équipe typique collaborerait en utilisant ce flux de travail. Nous allons voir comment deux développeurs, John et Mary, peuvent travailler sur des fonctionnalités distinctes et partager leurs contributions via un référentiel centralisé.

John travaille sur sa fonctionnalité

Dans son dépôt local, John peut développer des fonctionnalités en utilisant le processus de commit Git standard : edit, stage et commit.

Rappellez-vous que, puisque ces commandes créent des commits locaux, John peut répéter ce processus autant de fois qu’il le souhaite sans se soucier de ce qui se passe dans le dépôt central.

Mary travaille sur sa fonctionnalité

Pendant ce temps, Mary travaille sur sa propre fonctionnalité dans son propre dépôt local en utilisant le même processus edit/stage/commit. Comme John, elle ne se soucie pas de ce qui se passe dans le dépôt central, et elle ne se soucie pas vraiment de ce que John fait dans son dépôt local, puisque tous les dépôts locaux sont privés.

John publie sa fonctionnalité

Une fois que John a terminé sa fonctionnalité, il doit publier ses commits locaux dans le dépôt central afin que les autres membres de l’équipe puissent y accéder. Il peut le faire avec la commande git push, comme suit :

git push origin master

Rappelez-vous que origin est la connexion distante au dépôt central que Git a créée lorsque John l’a cloné. L’argument master indique à Git d’essayer de faire en sorte que la origin de master branche ressemble à sa master branche locale. Comme le dépôt central n’a pas été mis à jour depuis que Jean l’a cloné, cela n’entraînera aucun conflit et le push fonctionnera comme prévu.

Marie tente de publier sa fonctionnalité

Voyons ce qui se passe si Mary essaie de pousser sa fonctionnalité après que John ait publié avec succès ses modifications dans le dépôt central. Elle peut utiliser exactement la même commande push :

git push origin master

Mais, comme son historique local a divergé du dépôt central, Git refusera la requête avec un message d’erreur plutôt verbeux :

error: failed to push some refs to '/path/to/repo.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Cela empêche Mary d’écraser les commits officiels. Elle doit tirer les mises à jour de John dans son dépôt, les intégrer à ses modifications locales, puis réessayer.

Mary rebase par-dessus le(s) commit(s) de John

Mary peut utiliser git pull pour intégrer les modifications amont dans son dépôt. Cette commande est en quelque sorte svn update– elle tire l’ensemble de l’historique des commits amont dans le dépôt local de Mary et tente de l’intégrer à ses commits locaux :

git pull --rebase origin master

L’option --rebase indique à Git de déplacer tous les commits de Mary vers la pointe de la branche master après l’avoir synchronisée avec les changements du dépôt central, comme indiqué ci-dessous :

Le pull fonctionnerait toujours si vous oubliez cette option, mais vous vous retrouveriez avec un « merge commit » superflu chaque fois que quelqu’un aurait besoin de se synchroniser avec le dépôt central. Pour ce flux de travail, il est toujours préférable de rebaser au lieu de générer un merge commit.

Mary résout un conflit de fusion

Le rebasage fonctionne en transférant chaque commit local vers la branche mise à jour master un par un. Cela signifie que vous attrapez les conflits de fusion sur une base de commit par commit plutôt que de les résoudre tous en un seul commit de fusion massif. Cela permet de garder vos commits aussi concentrés que possible et de créer un historique de projet propre. À son tour, cela rend beaucoup plus facile de déterminer où les bogues ont été introduits et, si nécessaire, de rétablir les changements avec un impact minimal sur le projet.

Si Marie et Jean travaillent sur des fonctionnalités non liées, il est peu probable que le processus de rebasage génère des conflits. Mais si c’est le cas, Git mettra en pause le rebasement au niveau du commit actuel et produira le message suivant, accompagné de quelques instructions pertinentes :

CONFLICT (content): Merge conflict in 

Ce qui est formidable avec Git, c’est que tout le monde peut résoudre ses propres conflits de fusion. Dans notre exemple, Marie exécuterait simplement une git status pour voir où se trouve le problème. Les fichiers en conflit apparaîtront dans la section Chemins non fusionnés :

# Unmerged paths: # (use "git reset HEAD ..." to unstage) # (use "git add/rm ..." as appropriate to mark resolution) # # both modified: 

Puis, elle modifiera le ou les fichiers à sa guise. Une fois qu’elle est satisfaite du résultat, elle peut mettre en scène le(s) fichier(s) de la manière habituelle et laisser git rebase faire le reste :

git add git rebase --continue

Et c’est tout ce qu’il y a à faire. Git passera au commit suivant et répétera le processus pour tous les autres commits qui génèrent des conflits.

Si vous arrivez à ce point et que vous réalisez et que vous n’avez aucune idée de ce qui se passe, ne paniquez pas. Exécutez simplement la commande suivante et vous serez de retour à votre point de départ :

git rebase --abort

Mary publie avec succès sa fonctionnalité

Après avoir terminé la synchronisation avec le dépôt central, Mary pourra publier ses modifications avec succès :

git push origin master

Où aller d’ici

Comme vous pouvez le voir, il est possible de reproduire un environnement de développement Subversion traditionnel en utilisant seulement une poignée de commandes Git. C’est formidable pour assurer la transition des équipes hors de SVN, mais cela ne tire pas parti de la nature distribuée de Git.

Le flux de travail centralisé est idéal pour les petites équipes. Le processus de résolution des conflits détaillé ci-dessus peut former un goulot d’étranglement lorsque votre équipe évolue en taille. Si votre équipe est à l’aise avec le Workflow centralisé, mais qu’elle souhaite rationaliser ses efforts de collaboration, il vaut vraiment la peine d’explorer les avantages du Workflow de branche de fonctionnalité. En dédiant une branche isolée à chaque fonctionnalité, il est possible d’initier des discussions approfondies autour des nouveaux ajouts avant de les intégrer au projet officiel.

Autres flux de travail courants

Le flux de travail centralisé est essentiellement un bloc de construction pour d’autres flux de travail Git. La plupart des flux de travail Git populaires auront une sorte de repo centralisé à partir duquel les développeurs individuels pousseront et tireront. Nous aborderons brièvement ci-dessous d’autres flux de travail Git populaires. Ces workflows étendus offrent des modèles plus spécialisés en ce qui concerne la gestion des branches pour le développement de fonctionnalités, les correctifs à chaud et la libération éventuelle.

Branchement de fonctionnalités

Le branchement de fonctionnalités est une extension logique du flux de travail centralisé. L’idée centrale du Workflow de branchement des fonctionnalités est que tout le développement des fonctionnalités doit avoir lieu dans une branche dédiée au lieu de la branche master. Cette encapsulation permet à plusieurs développeurs de travailler facilement sur une fonctionnalité particulière sans perturber la base de code principale. Cela signifie également que la branche master ne devrait jamais contenir de code cassé, ce qui est un énorme avantage pour les environnements d’intégration continue.

Le Gitflow Workflow

Le Gitflow Workflow a été publié pour la première fois dans un billet de blog très apprécié de 2010 de Vincent Driessen chez nvie. Le Gitflow Workflow définit un modèle de branchement strict conçu autour de la version du projet. Ce flux de travail n’ajoute pas de nouveaux concepts ou commandes au-delà de ce qui est requis pour le flux de travail Feature Branch. Au lieu de cela, il attribue des rôles très spécifiques aux différentes branches et définit comment et quand elles doivent interagir.

Forking Workflow

Le Forking Workflow est fondamentalement différent des autres workflows abordés dans ce tutoriel. Au lieu d’utiliser un seul dépôt côté serveur pour faire office de base de code « centrale », il donne à chaque développeur un dépôt côté serveur. Cela signifie que chaque contributeur n’a pas un, mais deux dépôts Git : un dépôt local privé et un dépôt public côté serveur.

Lignes directrices

Il n’existe pas de workflow Git à taille unique. Comme indiqué précédemment, il est important de développer un workflow Git qui soit une amélioration de la productivité pour votre équipe. En plus de la culture d’équipe, un workflow doit également compléter la culture d’entreprise. Les fonctionnalités de Git telles que les branches et les balises doivent compléter le calendrier de publication de votre entreprise. Si votre équipe utilise un logiciel de gestion de projet de suivi des tâches, vous voudrez peut-être utiliser des branches qui correspondent aux tâches en cours. En outre, voici quelques directives à prendre en compte pour décider d’un flux de travail :

Branches à courte durée de vie

Plus une branche vit longtemps séparée de la branche de production, plus le risque de conflits de fusion et de défis de déploiement est élevé. Les branches à courte durée de vie favorisent des fusions et des déploiements plus propres.

Minimiser et simplifier les reverts

Il est important d’avoir un workflow qui aide à prévenir de manière proactive les fusions qui devront être reverties. Un workflow qui teste une branche avant de l’autoriser à être fusionnée dans la branche master en est un exemple. Cependant, des accidents peuvent se produire. Cela étant dit, il est bénéfique d’avoir un flux de travail qui permet des retours en arrière faciles qui ne perturberont pas le flux des autres membres de l’équipe.

Correspondre à un calendrier de publication

Un flux de travail devrait compléter le cycle de publication du développement logiciel de votre entreprise. Si vous prévoyez de publier plusieurs fois par jour, vous voudrez garder votre master branche stable. Si votre calendrier de publication est moins fréquent, vous pouvez envisager d’utiliser les balises Git pour marquer une branche à une version.

Résumé

Dans ce document, nous avons abordé les flux de travail Git. Nous avons examiné en profondeur un flux de travail centralisé avec des exemples pratiques. En développant le flux de travail centralisé, nous avons discuté d’autres flux de travail spécialisés. Voici quelques éléments clés à retenir de ce document :

• Il n’existe pas de flux de travail Git à taille unique
• Un flux de travail doit être simple et améliorer la productivité de votre équipe
• Vos exigences commerciales doivent aider à façonner votre flux de travail Git

Pour en savoir plus sur le prochain flux de travail Git, consultez notre analyse complète du flux de travail de la branche de fonctionnalité.