Quels sont les avantages d’utiliser Branching en tant que développeur solo?

Tout d'abord, je suis conscient du fait que de nombreuses questions ont été posées à propos de VCS en tant que développeur solo, mais elles sont souvent trop larges. Cela ne concerne que les branches, et cela a toujours été marqué comme un doublon ... le supposé doublon est, là encore, marqué comme un autre doublon d'une autre question trop large qui ne concerne pas spécifiquement les branches. C'est comme ça que ma question est unique.

Quels sont les avantages, le cas échéant, d’utiliser Branching en tant que développeur solo? Je l'ai souvent vu recommandé même dans un contexte de développeur solo, mais pour autant que je sache, au-delà de l'utilisation d'une trompe «principale» pour le développement et de la création de code pour travailler, du code prêt pour la publication, je ne vois pas comment Je pouvais exploiter le pouvoir des branches (par exemple, compartimenter de nouvelles fonctionnalités) sans trop compliquer le processus de développement.

Les avantages sont généralement les mêmes que pour les groupes de développeurs. En utilisant une branche principale toujours prête à être lancée et des branches permettant de développer de nouvelles fonctionnalités, vous pouvez toujours libérer le maître. Trouver un bug important en travaillant sur une fonctionnalité? Changez de branche, corrigez, relâchez, revenez en arrière et poursuivez le développement.

Ou peut-être s'agit-il d'un projet de loisir et vous aimez simplement pouvoir travailler un peu sur cette fonctionnalité et un peu de cela, selon l'humeur qui vous frappe. En gros, vous imitez une équipe composée de plusieurs personnes en découpant votre temps.

Le branchement implicite que font les DVCS sur les clones signifie que les branches formelles du référentiel faisant autorité sont moins axées sur la coordination des personnes et davantage sur la coordination des orientations de développement, et même une seule personne peut en effectuer plusieurs.

Développement à long terme

La création de branches pour une seule personne serait utile pour une fonction de développement longue qui ne correspondrait pas à votre cycle de publication.

Vous pouvez prendre une branche pour votre changement couvrant plusieurs mois tout en conservant la possibilité d'insérer les corrections de bugs quotidiennes ou les modifications apportées à votre branche principale à intervalles réguliers.

Cela présente l'avantage sur les "commutateurs" d'une seule branche en ce sens que votre branche principale est toujours dans un état déployable et qu'il est garanti qu'aucun élément de la longue fonctionnalité n'a eu d'impact sur du code précédemment testé.

Caractéristiques expérimentales

Une branche peut également être utile pour les fonctionnalités que vous souhaitez peut-être créer en prototype, mais qui ne pourront jamais en faire partie dans votre code déployé. Le fait de les terminer sur une branche qui sera finalement jetée signifie que vous ne polluez jamais inutilement votre base de code principale.

Je l'utilise pour la maintenance de sites Web critiques. Je suis le seul développeur mais j'ai un master, développe et édite des branches.

Mon processus de travail pour la configuration du site ressemble à ceci:

1. Rendre la branche maîtresse réalisable. Faites le commit initial.

2. Commander développer la branche. Ne faites rien, développez des fonctions en tant que tampon de test pour la fusion en maître.

3. Branche de sortie de caisse. Codez votre problème, une fois terminé, tirez-le pour développer, voyez si des problèmes surviennent, fusionnez des conflits, etc. ... corrigez-les.

Lorsque suffisamment de problèmes sont fusionnés en développement pour une version et que développement a été testé pour la stabilité, tirez développez en maître.

   Master
     |
   Develop  - E
   / |  \  \
 A   B   C  D

De cette façon, vous obtenez une collection complète de tests en développement, où vous pouvez tester la stabilité, les problèmes, etc. sans avoir à risquer de faire mal à Maître et à avoir à annuler les commits s’ils étaient dangereux.

En outre, en utilisant des branches individuelles pour commettre, vous pouvez "laisser" le travail que vous avez déjà fait, recommencer à zéro pour autre chose afin de résoudre un problème plus urgent et le diffuser plus tôt.

Dans la vie réelle, j'ai généralement une branche de problème et je tire celle-ci en développement, puis en maître. Parfois, c'est fastidieux, mais au moins tous les deux mois, je dois abandonner le travail du jour au lendemain, parce que quelqu'un a eu l'idée que je devais créer RightNow ™ et que, de cette manière, je pourrais rapidement revenir à un état de base. et ensuite continuer là où j'étais. Surtout avec les grands projets qui prennent plusieurs semaines, c’est un don que je peux rapidement changer de branche.

Considérez ce scénario: Vous travaillez toujours sur une branche principale et vous avez AwesomeCodeThing ™ dans les œuvres qui laisse votre branche principale en chirurgie cardiaque ouverte et une YugeBug ™ apparaît qui a besoin de fixer d' urgence sinon des milliers d'utilisateurs se plaignent de vous au sujet BigProblems ™
La seul moyen de résoudre rapidement votre problème dans un tel scénario,

1. vérifiez vos commits précédents,
2. voir quand était votre dernier commit stable (la malédiction est optionnelle)
3. revenir à ce commit
4. faire correctif, pousser correctif à la production
5. Résolvez tous les conflits et problèmes que vous rencontrez maintenant pour revenir au statut AwesomeCodeThing ™
6. abandonner, pleurer et recommencer à travailler (facultatif)

Si vous utilisez des branches:

1. Maître de caisse
2. créer une branche UrgentFix ™ et résoudre des problèmes
3. tirer UrgentFix ™ dans le maître
4. pousser à la production
5. Fusionner le maître pour développer
6. Fusionnez dans AwesomeCodeThing ™
7. prendre une bière et continuer à travailler.

Les branches facilitent le travail sur plusieurs fonctionnalités à la fois, ce qui peut être très utile lorsque les priorités changent au cours d'un projet.

Supposons que vous décidiez qu'une fonctionnalité est plus importante maintenant. Peut-être avez-vous un besoin urgent de corriger un bogue critique dans un système en direct. Vous pouvez travailler avec un client sur plusieurs fonctionnalités sur une longue période et souhaiter tester la progression de chaque fonctionnalité séparément. Peut-être que vous venez de lire un article sur un exploit nul et que vous voulez en parler avant que le client ne le lise.

Si vous utilisez des branches pour chaque fonctionnalité / correctif, il sera généralement plus facile, plus propre et plus rapide d’isoler et de déployer ces modifications plutôt que d’utiliser une seule branche pour tout. Cela est vrai que vous soyez développeur unique ou membre d'une équipe.

En ce qui concerne un processus réel, je trouve que git flow fonctionne bien. La feuille de triche git flow de Daniel Kummer est une excellente ressource. Il vaut la peine de la regarder même si vous n'utilisez pas git.

Comme mentionné par d'autres affiches, les avantages sont sensiblement similaires à ceux du travail en équipe: possibilité de développer et de tester de manière autonome des fonctionnalités, de gérer une branche principale distincte pour les correctifs / déploiements de production, d'expérimenter.

Pour ma part, j’ai généralement tendance à travailler en maître si je connais très bien le domaine sur lequel je travaille, cela ne fait qu’ajouter des frais généraux à une branche, car je vais simplement les fusionner de toute façon.

Toutefois, si j’ai une quelconque hésitation à propos des modifications que je suis en train de faire, je créerai une branche et seul le rapport PR / fusion une fois que la branche se comportera comme prévu et sera généralement entièrement testé. Ainsi, si je découvre un problème pour lequel la restauration est la meilleure solution, il s’agit d’un simple commit au lieu d’une série entière (je ne me souviens jamais de la syntaxe pour annuler une série d’engagements, mais un seul est facile).