Le Workflow Git Qui Fonctionne Réellement pour les Développeurs Solo
Je me souviens encore du moment exact où j'ai craqué. Il était 2 heures du matin un mardi, et je fixais un conflit de fusion entre ma branche `feature/redesign` et `main`. Le comble ? J'étais le seul développeur du projet. J'étais littéralement en conflit de fusion avec moi-même. Trois jours de travail—partis. Pas à cause d'une défaillance catastrophique du disque dur ou d'un dépôt supprimé. Non, j'ai perdu ces trois jours parce que j'avais suivi religieusement un workflow Git conçu pour des équipes de 10 développeurs ou plus. J'avais des branches de fonctionnalités, des branches de corrections, des branches de versions, et une branche `develop` qui n'existait que pour me faire sentir professionnel. L'ironie ne m'a pas échappé : j'avais passé plus de temps à gérer Git qu'à réellement écrire du code. Cette nuit-là, assis dans mon bureau à domicile avec un café froid et un ego meurtri, j'ai pris une décision. J'allais éliminer chaque aspect de la cérémonie Git qui ne me servait pas en tant que développeur solo. Plus de mimétisme des workflows d'équipe. Plus de prétendre que j'avais besoin de la même infrastructure qu'une équipe d'ingénierie de 50 personnes. Ce qui a émergé de cette frustration est le workflow que j'ai utilisé pour expédier plus de 40 projets solo depuis lors. Ce n'est pas sexy. Cela n'impressionnera personne lors d'une conférence technique. Mais ça fonctionne, et plus important encore, ça ne me met pas des bâtons dans les roues pour que je puisse vraiment construire des choses.Pourquoi La Plupart des Workflows Git Échouent pour les Développeurs Solo
Le problème avec la plupart des tutoriels et workflows Git est qu'ils sont écrits par des personnes travaillant dans des entreprises avec plusieurs équipes, processus de révision de code, et pipelines de déploiement qui impliquent au moins trois environnements différents. Quand vous êtes un développeur solo, vous n'avez pas ces contraintes—mais vous n'avez pas non plus ces filets de sécurité. GitFlow, le workflow qui dominait les années 2010, est un parfait exemple. Il a été conçu par Vincent Driessen pour un problème spécifique : gérer les versions de logiciels qui devaient prendre en charge plusieurs versions simultanément. Si vous construisez une application de bureau que les clients installent localement, GitFlow a du sens. Si vous êtes un développeur solo expédiant un produit SaaS ou un site web client, c'est complètement excessif. Le parcours typique d'un développeur solo avec Git va quelque chose comme ceci : Vous commencez par ne vous engager qu'à `main` (ou `master`, selon quand vous avez appris Git). Ensuite, vous lisez un article sur les "workflows Git professionnels" et vous vous sentez coupable. Vous implémentez des branches de fonctionnalités. Ensuite, vous ajoutez une branche `develop` parce que c'est ce que montrait le diagramme. Avant longtemps, vous passez 20 minutes par jour rien qu'à gérer des branches, et vous n'êtes même pas sûr de pourquoi la moitié d'entre elles existent. J'y ai été. J'ai eu des dépôts avec des branches nommées `feature/new-feature`, `feature/new-feature-2`, `feature/new-feature-actually-final`, et `feature/new-feature-for-real-this-time`. Si vous n'avez jamais eu de crise de nommage de branche, vous mentez soit, soit vous n'avez pas développé en solo assez longtemps. Le problème fondamental est que les workflows d'équipe sont conçus pour résoudre des problèmes d'équipe : coordonner le travail entre plusieurs personnes, prévenir les conflits, gérer les processus de révision de code, et maintenir la stabilité dans des environnements partagés. Lorsque vous travaillez en solo, la plupart de ces problèmes n'existent tout simplement pas. Vous ne pouvez pas avoir de conflit de fusion avec quelqu'un d'autre s'il n'y a personne d'autre.La Règle des Trois Commits Qui a Tout Changé
Après mon désastre de 2 heures du matin, j'ai commencé à analyser mes véritables habitudes de travail. J'ai extrait mon historique Git des six mois précédents et j'ai regardé chaque branche que j'avais créée, chaque fusion que j'avais faite, et chaque conflit que j'avais résolu. Ce que j'ai trouvé était éclairant. Quatre-vingt-dix pour cent de mes branches de fonctionnalités contenaient trois commits ou moins avant fusion. Ce n'étaient pas des fonctionnalités complexes de plusieurs semaines qui nécessitaient de l'isolement. C'étaient de petites améliorations, des corrections de bogues, et des changements incrémentaux que j'avais séparés artificiellement en branches parce que je pensais que c'était ce que faisaient les "vrais développeurs". Les dix pour cent restants—les véritables fonctionnalités complexes—étaient là où les branches avaient du sens. Mais même là, j'ai remarqué quelque chose : les branches qui causaient des problèmes étaient celles que j'avais laissées ouvertes pendant plus d'une semaine. Plus une branche vivait longtemps, plus il était probable qu'elle cause des problèmes lors de la fusion. Cela m'a conduit à ce que j'appelle la Règle des Trois Commits : Si un changement prend plus de trois commits, il est probablement trop gros et devrait être décomposé. S'il ne peut pas être décomposé, c'est l'un des rares cas où une branche aide réellement. Cette règle m'a forcé à penser différemment quant à ma façon de travailler. Au lieu de créer une branche pour "redessiner l'ensemble de l'interface utilisateur", je créerais une branche pour "mettre à jour les styles de bouton" ou "implémenter un nouveau composant de navigation". Chaque branche vivait un jour ou deux au maximum, contenait des changements ciblés, et fusionnait proprement. Le changement psychologique a été significatif. J'ai arrêté de penser en termes de "fonctionnalités" et j'ai commencé à penser en termes "d'incréments déployables". Chaque branche devait représenter quelque chose que je pouvais expédier en production sans casser la fonctionnalité existante. Cela gardait naturellement les branches petites et de courte durée.Le Jour Où J'ai Expédié un Bogue en Production (Et Pourquoi Cela a Amélioré Mon Workflow)
Permettez-moi de vous parler du pire déploiement de ma carrière. Je travaillais sur un projet client—un système de réservation pour une petite chaîne hôtelière. J'avais travaillé sur une branche de fonctionnalité pendant deux semaines (oui, je sais, j'ai enfreint ma propre règle) qui ajoutait une nouvelle intégration de paiement. La branche s'était considérablement divergeant de `main`. J'avais été tellement concentré sur la fonctionnalité de paiement que je ne suivais plus les petites corrections et améliorations que j'avais faites directement sur `main` pour des demandes urgentes du client. Quand il était temps de fusionner, j'avais des conflits dans 14 fichiers. J'ai résolu les conflits, exécuté les tests (ils ont réussi), et déployé en production. Dans l'heure qui a suivi, j'ai reçu un appel paniqué du client. Le formulaire de réservation était cassé. Pas la nouvelle intégration de paiement—le formulaire de réservation de base qui fonctionnait bien depuis des mois. Que s'est-il passé ? En résolvant l'un des conflits de fusion, j'avais accidentellement conservé la mauvaise version d'une fonction. Les tests ne l'ont pas détectée parce que je n'avais pas écrit de tests pour ce cas particulier (leçon apprise). Le bogue était entièrement de ma faute, mais le workflow avait facilité cette erreur. Cet incident m'a appris quelque chose d'essentiel : en tant que développeur solo, mon plus grand risque n'est pas le code des autres—c'est mon propre code d'il y a deux semaines. Lorsque je change de contexte entre différentes parties d'un projet, je collabore essentiellement avec les versions passées de moi-même. Et le moi du passé est souvent un collègue peu fiable. Cette réalisation a conduit au deuxième pilier de mon workflow : la Règle de la Semaine. Aucune branche ne vit plus d'une semaine. Si une fonctionnalité doit prendre plus de temps, je la décompose en plus petites pièces qui peuvent chacune être complétées et fusionnées dans une semaine. Si ce n'est pas possible, j'utilise des drapeaux de fonctionnalité pour fusionner du code incomplet à `main` tout en le gardant caché des utilisateurs. La Règle de la Semaine m'a sauvé d'innombrables fois. Elle m'oblige à rester proche de `main`, ce qui signifie que je travaille toujours avec la version la plus actuelle de la base de code. Elle empêche le genre de divergence qui mène à des conflits de fusion complexes. Et elle me garde honnête sur la portée—si je ne peux pas terminer quelque chose en une semaine, j'essaie probablement d'en faire trop à la fois.Le Vrai Coût de la Complexité des Branches
Parlons chiffres. J'ai suivi mes activités liées à Git pendant trois mois avant et après avoir simplifié mon workflow. Les résultats étaient frappants :| Activité | Avant (heures/semaine) | Après (heures/semaine) | Temps Économisé |
|---|---|---|---|
| Création et gestion des branches | 2.5 | 0.5 | 2 heures |
| Résolution des conflits de fusion | 3.0 | 0.3 | 2.7 heures |
| Décider quelle branche utiliser | 1.5 | 0.1 | 1.4 heures |
| Nettoyage des branches obsolètes | 1.0 | 0.1 | 0.9 heures |
| Rebasing et synchronisation des branches | 2.0 | 0.2 | 1.8 heures |
| Coût total lié à Git | 10.0 | 1.2 | 8.8 heures |
Pourquoi "Commitez Tôt, Commitez Souvent" Est Mauvais pour les Développeurs Solo
Voici un avis controversé : le conseil de "commiter tôt, commiter souvent" est en réalité nuisible pour les développeurs solo. Je sais que cela va à l'encontre de la sagesse conventionnelle, mais écoutez-moi.Le but des commits n'est pas de créer un journal détaillé de chaque frappe. C'est de créer des points de contrôle significatifs qui racontent une histoire sur l'évolution de votre code. Lorsque vous travaillez en solo, vous êtes la seule personne qui doit comprendre cela.