Le workflow Simple Git est simple

Nicola Paolucci
Nicola Paolucci
Retour à la liste

De nombreuses équipes ont déjà adopté Git et beaucoup d'autres sont en cours de migration. Outre la formation individuelle des développeurs et la désignation de Champions pour faciliter l'adoption, il est essentiel de choisir une pratique de collaboration autour du code qui ne complique pas trop les choses. Avec Git, vous pouvez traiter des workflows très compliqués, j'en suis témoin.

Git ne comporte pas de manuel préinstallé sur les workflows. Pourtant, nombreux sont les utilisateurs à poser des questions sur le sujet. La bonne nouvelle, c'est que nous travaillons dur pour fournir une documentation utile.

Webinaires récents et guides sur les workflows

Si vous préférez la lecture et les belles images, l'une des sections les plus populaires de notre guide Git en ligne est la partie sur les workflows.

Mais avant de partir, continuez à lire, parce que j'ai quelque chose de vraiment cool à partager.

J'aimerais vous fournir une description concise, mais détaillée, d'un workflow simple destiné à une livraison continue. Cela exige que votre équipe et vous-même vous familiarisiez un minimum avec git et que vous ayez une bonne connaissance de la commande rebase dans ces deux formes (interactive ou non).

Un workflow de branching élémentaire pour une livraison continue

Le workflow simple que je souhaite décrire s'articule autour de deux principes directeurs :

  • master sera toujours associé à la production et déployable à tout moment.
  • rebase pendant le développement d'une fonctionnalité ; merge explicite (sans fast-forward) une fois la tâche accomplie.

Lorsque vous faites un pull des changements au moyen de rebase, l'historique de la branche sur laquelle vous travaillez est réécrit et les changements sont placés au-dessus.

Workflow Git simple

Le rebase dont vous avez besoin pour ce workflow est représenté sur l'image de droite.

En s'appuyant sur ces principes directeurs, récapitulons les sept étapes :

1. Commencez par faire un pull des derniers changements à partir de master.

Pour ce faire, utilisez simplement les commandes Git classiques :

git checkout master
git fetch origin
git merge master

Privilégiant une approche plus explicite, j'utilise fetch/merge, mais ces deux commandes équivalent à : git pull origin master.

2. Créez une branche pour isoler la fonctionnalité ou la correction de bug.

Maintenant, créez une branche pour la fonctionnalité ou la résolution de bug :

git checkout -b PRJ-123-awesome-feature

La structure du nom de branche que je présente ici est simplement celle que nous utilisons, mais vous pouvez choisir n'importe quelle convention de votre choix.

3. À présent, vous pouvez travailler sur la fonctionnalité

Peaufinez la fonctionnalité aussi longtemps que nécessaire. Assurez-vous que vos commits sont cohérents et ne regroupez pas les changements séparés.

4. Pour garder votre branche de fonctionnalité à jour avec les derniers changements dans la branche master, utilisez le rebase.

De temps à autre pendant le développement, mettez à jour la branche de fonctionnalité avec les derniers changements apportés à master. Pour ce faire, utilisez :

git fetch origin
git rebase origin/master

Dans le cas (un peu moins courant) où d'autres développeurs travaillent également sur une même branche de fonctionnalité distante, faites un rebase des changements qui en sont issus :

git rebase origin/PRJ-123-awesome-feature

À ce stage, résolvez tous les conflits apparus suite au rebase.

Résoudre les conflits pendant le rebase vous permettra d'obtenir des merges propres à l'issue du développement de votre fonctionnalité. L'historique de votre branche de fonctionnalité restera propre et ciblé, sans interférences.

5. Quand vous êtes prêt pour le feedback, pushez votre branche à distance et créez une pull request.

Lorsque le moment est venu de partager votre travail et de solliciter un feedback, vous pouvez pusher votre branche à distance avec :

git push -u origin PRJ-123-awesome-feature

(si la branche est déjà configurée comme « upstream » et que votre remote se nomme « origin », « git push » est suffisant)

Vous pouvez désormais faire une pull request sur votre serveur Git favori (par exemple Bitbucket Server ou Bitbucket Cloud).

Après le push initial, vous pouvez continuer le push des mises à jour vers la branche distante à plusieurs reprises. Cela peut arriver suite à un feedback ou parce que vous n'avez pas terminé le développement de la fonctionnalité.

6. Effectuez un nettoyage de rebase final après que la pull request a été approuvé

Une fois la révision terminée, il est recommandé d'effectuer un nettoyage final et de débarrasser l'historique des commits de la branche de fonctionnalité de tous les commits inutiles qui n'apportent aucune information pertinente. Dans certains cas (si votre équipe est assez expérimentée pour le gérer), vous pouvez également exécuter un rebase pendant le développement, mais je vous le déconseille fortement :

git rebase -i origin/master

(À ce stade, si vous avez réécrit l'historique d'une branche publiée et à condition qu'aucun autre développeur n'y intègre des commits ou ne l'utilise, vous devrez probablement faire un push de vos changements en utilisant le flag --force).

7. Lorsque le développement est terminé, enregistrez un merge explicite

Une fois que vous aurez terminé de développer la branche de fonctionnalité et que les réviseurs auront fait leur travail, lancez merge en utilisant le flag --no-ff. Ainsi, le contexte sera préservé, et vous pourrez facilement inverser la fonctionnalité dans son intégralité si nécessaire. Les commandes sont :

git checkout master
git pull origin master

git merge --no-ff PRJ-123-awesome-feature

Si vous avez suivi le conseil ci-dessus et que vous avez utilisé rebase pour tenir votre branche de fonctionnalité à jour, le commit de merge réellement utilisé n'inclura aucun changement, ce qui est plutôt cool ! Le commit de merge devient un simple marqueur, qui stocke le contexte de la branche de fonctionnalité.

Pour en savoir plus, reportez-vous à mon article récent sur les avantages et les inconvénients de l'utilisation d'un workflow de merge et de rebase.

Option de basculement .gitconfig utile :

Vous pouvez ordonner à Git que toute commande pull utilise rebase plutôt que merge et de lancer en parallèle la commande preserve :

git config --global branch.autosetuprebase always 
git config --global pull.rebase preserve #(il s'agit d'un ajout très récent et utile apparu dans Git 1.8.5)

Tout le monde ne souhaite pas modifier le comportement par défaut des commandes principales ; par conséquent, n'appliquez ces instructions que si vous en comprenez les implications. Reportez-vous à Stack Overflow pour en savoir plus sur la conservation des merges.

Conclusions

À présent, vous avez toutes les cartes en main pour vous familiariser avec les workflows, les modèles de création de branches et les possibilités de collaboration autour du code. Pour plus d'infos passionnantes sur Git, suivez moi (@durdn) et l'incroyable équipe @AtlDevtools. Crédits : ce billet est partiellement inspiré de ce gist concis et très bien fait.

Prêt à découvrir Git ?

Essayez ce tutoriel interactif.

Démarrez maintenant