Git - Quels problèmes découlent du travail direct sur le maître?

25

J'ai vu beaucoup de conseils sur les modèles de branchement git et l'opinion la plus courante semble être que faire des changements directement sur la branche principale est une mauvaise idée.

Un de nos collègues est très heureux d'apporter des modifications directement sur la branche principale, et malgré plusieurs conversations, il ne semble pas probable que cela change.

À ce stade, je ne peux pas convaincre un collègue que c'est une mauvaise pratique de travailler directement sur le maître, mais j'aimerais comprendre les choses qui entreront en conflit avec sa façon de travailler, savoir quand je dois revoir ce problème.

version-control git svn branching linuxunil
la source
2
Définissez «travailler directement». Le maître existe parce qu'il est destiné à être utilisé. À quoi pensez-vous que c'est et à quoi ne sert-il pas?
candied_orange
3
Travailler hors master fonctionne-t-il pour vous? Si c'est le cas, pourquoi ressentez-vous le besoin de changer maintenant? Si cela ne fonctionne pas, quel (s) problème (s) rencontrez-vous? Au lieu de demander aux gens de vous indiquer les arguments des autres, nous pouvons vous aider à résoudre vos problèmes.
Thomas Owens
1
On dirait qu'il fait du développement de troncs, ce qui, avec une intégration continue, est assez normal dans une équipe Agile. S'il veut travailler comme ça, vous devrez appliquer WIP pour vous assurer qu'il n'y a jamais trop de travail en cours sur un produit à la fois - et également utiliser le changement de fonctionnalité pour vous assurer que le master peut être publié avec des fonctionnalités incomplètes désactivées.
M. Cochese
... quelle est la taille de l'équipe?
ZJR
@MrCochese Je n'appellerais pas le développement de tronc dans le sens ici "normal". Certainement aucun des nombreux endroits où j'ai utilisé Git n'a fonctionné de cette façon, et je le découragerais. Les branches de fonctionnalités fonctionnent mieux.
Marnen Laibow-Koser

Réponses:

57

Il y a plusieurs problèmes lorsque les validations sont directement poussées vers le master

  • Si vous poussez un état de travail en cours à distance, le maître est potentiellement cassé
  • Si un autre développeur commence à travailler pour une nouvelle fonctionnalité à partir de master, il démarre avec un état potentiellement cassé. Cela ralentit le développement
  • Différentes fonctionnalités / corrections de bugs ne sont pas isolées, de sorte que la complexité de toutes les tâches de développement en cours est combinée dans une seule branche. Cela augmente la quantité de communication nécessaire entre tous les développeurs
  • Vous ne pouvez pas faire de requêtes pull qui sont un très bon mécanisme pour les revues de code
  • Vous ne pouvez pas écraser les validations / modifier l'historique de git en général, car d'autres développeurs peuvent avoir déjà retiré la branche principale entre-temps
Gernot
la source
11
Hé regarde! Vous avez en fait répondu à la question, contrairement à tout le monde. ++ Bienvenue sur SE.SE!
RubberDuck
La plupart de ces problèmes sont dus à un mauvais fonctionnement direct du maître , et non au travail directement sur le maître en soi.
Ant P
1
@AntP quels problèmes pourraient être évités de votre point de vue?
Gernot
10

Expliquez-lui que les nouvelles fonctionnalités ont besoin de leur propre branche de développement qui peut être déployée dans un environnement de test avant d'être mise en production.

Sinon, vous êtes dans un état perpétuel de fonctionnalités à moitié terminées. Vous ne pouvez pas déployer des fonctionnalités à moitié terminées en production, donc si vous travaillez directement sur la branche principale, tout le monde doit attendre que vous terminiez votre fonctionnalité avant que les modifications de quelqu'un d'autre puissent passer en production, y compris les corrections de bogues.

L'utilisation de branches indépendantes pour les fonctionnalités signifie que chaque nouvelle fonctionnalité peut être testée et déployée indépendamment des autres.

Robert Harvey
la source
"Vous ne pouvez pas déployer des fonctionnalités semi-terminées en production" - ce n'est pas vrai du tout - il est tout à fait possible de travailler directement sur la branche principale, d'expédier le code à chaque validation, de déployer fréquemment des "fonctionnalités semi-terminées" et de ne rien casser . La livraison continue consiste à faire exactement cela: découpler le déploiement de la version. Ce qui arrive également à résoudre de nombreux autres problèmes organisationnels que les gens traitent normalement avec des solutions techniques à moitié cassées. Parfois, cela implique des basculements de fonctionnalité, mais il est généralement possible de créer et de déployer 90% d'une fonctionnalité sans changement de comportement visible.
Ant P
@AntP: Le processus que vous décrivez n'est pas ce que j'appellerais des «fonctionnalités à moitié terminées». Ces fonctionnalités sont soit testées, prêtes pour la production et utilisables, soit cachées par un commutateur de fonctionnalités ou quelque chose de similaire jusqu'à ce qu'elles soient testées, prêtes pour la production et utilisables. Vous ne livrez pas de fonctionnalités qui ne fonctionnent pas.
Robert Harvey
Vous avez affirmé que de nouvelles fonctionnalités doivent être développées sur des branches non maîtresses car vous ne pouvez pas déployer de semi-finies: ce n'est pas le cas. Vous pouvez absolument développer de nouvelles fonctionnalités directement sur le maître et expédier tout le code lié à ces fonctionnalités à la production avant la fin de la fonctionnalité et sans retarder le développement.
Ant P
1
@AntP: La seule chose que les branches de fonctionnalités ont que votre technique ne peut pas fournir est une comptabilité complète du travail effectué sur une fonctionnalité particulière. Dans certains magasins (le mien en particulier), ce type de responsabilité n'est pas un luxe mais plutôt une exigence.
Robert Harvey
1
@AntP Si je vous comprends bien, je considérerais cela comme un pas en arrière. J'adore les bons trackers de problèmes et je les utilise beaucoup, mais je veux que le VCS me raconte l' historique de développement de toute fonctionnalité ou ligne de code. Le tracker de problème peut raconter l'histoire de l' aspect commercial d'un changement, mais si le VCS ne peut pas m'aider à suivre et à auditer le code lui-même, il ne fait pas son travail. C'est une des raisons pour lesquelles je m'oppose au développement basé sur les troncs: cela rend le VCS stupide, sans aucun avantage compensatoire que je puisse voir. (Aussi: couplage fragile? Une caractéristique est un changement de code.)
Marnen Laibow-Koser
2

Le maître devrait être potentiellement libérable. Période. Il ne devrait pas y avoir de travail à moitié terminé dans le maître (sauf s'il est désactivé avec un indicateur de fonctionnalité)

Cela dit, j'ai vu certaines équipes compliquer leur flux.

Ne pas utiliser PR lors de l'intégration à master est une erreur car les développeurs n'auront pas le pouvoir de choisir le moment de l'intégration.

Une seule branche de développement apporte très peu de valeur. Habituellement, cela ne fait que compliquer les choses. De nombreuses branches de fonctionnalités apportent beaucoup de valeur.

Faire des branches pour chaque environnement (dev, test, prod) est une erreur. Ceci est hors de portée pour git et devrait être géré par le pipeline de versions. La même version doit être déployée dans tous les environnements, ce qui est impossible s'il existe des branches pour chaque environnement.

Si une fonctionnalité est si volumineuse qu'elle ne peut pas être effectuée en un jour ou deux, tous les travaux vers une branche de fonctionnalité doivent être dans des branches distinctes et intégrés à PR.

Esben Skov Pedersen
la source
Je suis d'accord avec la plupart de ce que vous avez dit, à l'exception de ceci: "La même version exacte doit être déployée dans tous les environnements". En fait, un pipeline de versions devrait généralement être en mesure de déployer différentes versions dans différents environnements, puis de les promouvoir à mesure que les tests réussissent. Comment gérez-vous cela, sinon avec des branches différentes (ou au moins des balises différentes)?
Marnen Laibow-Koser
Peut-être que je n'étais pas complètement clair. Une fois qu'une build est déployée dans un environnement. Les mêmes artefacts doivent être déployés dans l'environnement suivant sans reconstruction.
Esben Skov Pedersen
Si vous avez des versions répétables, peu importe que vous reconstruisiez. Si vous n'avez pas de builds reproductibles, vous avez de plus gros problèmes. :)
Marnen Laibow-Koser
... mais oui, je pense que vous devez baliser vos validations déployées afin de pouvoir promouvoir le même code (que vous reconstruisiez ou non).
Marnen Laibow-Koser
Oui, mais la plupart des serveurs CI peuvent lier les versions aux versions prêtes à l'emploi, ce qui facilite le suivi des déploiements. Lorsque la configuration est correcte, il n'est pas vraiment nécessaire de suivre les déploiements dans git. Git est un scm. Pas un outil de déploiement.
Esben Skov Pedersen
2
  • Le Master doit refléter une branche de production, une version finale fonctionnelle.
  • Travailler directement dans master signifie que si vous créez des bogues, vous n'avez pas d'autre option pour "revenir en arrière" que d'inverser / supprimer / réinitialiser les commits, ce qui n'est pas une manière propre de travailler et peut vous faire perdre les parties du nouveau code qui étaient OK.
  • Bien sûr, dans les toutes premières étapes du développement, vous pouvez peut-être commencer à travailler directement sur le maître, mais après avoir quelque chose à livrer, vous devez utiliser les branches de développement, de test ou d'expérimentation pour ne pas toucher la version publiée, complète et fonctionnelle.
Tulains Córdova
la source
2

Tout d'abord, je tiens à souligner que dans git, tout pullest littéralement une opération de branchement et tout pushest une fusion. La mastermachine d'un développeur est une branche complètement distincte de celle masterd'un dépôt central que vous partagez, avec un statut égal d'un point de vue technique. Je renommerai parfois ma version locale en upstreamou quelque chose si cela convient mieux à mes besoins.

Je le signale parce que de nombreuses organisations pensent qu'elles utilisent les succursales plus efficacement que votre collègue, alors qu'en réalité, elles ne font guère plus que de créer un nom supplémentaire pour une succursale en cours de route, qui ne sera de toute façon pas enregistré dans l'historique. Si votre collègue valide des fonctionnalités dans une validation atomique, il est tout aussi facile de revenir en arrière qu'une validation de fusion d'une branche de fonctionnalité. La grande majorité des branches caractéristiques doivent être de très courte durée et souvent fusionnées de toute façon.

Cela dit, les principaux inconvénients de son style de travail sont doubles. Tout d'abord, il est très difficile de collaborer sur une fonctionnalité inachevée. Cependant, il ne serait pas difficile de créer une branche uniquement aux moments où une collaboration est nécessaire.

Deuxièmement, cela rend l'examen avant la fusion très difficile. Sur ce point, vous n'avez pas vraiment besoin de le convaincre. Vous pouvez adopter un outil comme github, gerrit ou gitlab, et exiger des révisions de code de demande d'extraction et des tests automatisés réussis pour toutes les fusions. Si vous ne faites pas quelque chose comme ça, franchement, vous n'utilisez pas git à son plein potentiel, et il n'est pas étonnant que votre collègue ne voit pas ce potentiel.

Karl Bielefeldt
la source
1
Pousser chaque jour les développeurs sur sa machine de branche est une bonne sauvegarde.
Ian
Je ne comprends pas ta première séquence. Je ne vois pas comment un pullcréerait une nouvelle branche ou comment un pushserait une opération de fusion. Au contraire, un pullest littéralement un fetchsuivi d'un merge!
mkrieger1
@ mkrieger1 Je peux facilement voir comment on pourrait considérer le local mastercomme une branche différente de origin master. Techniquement, ce sont des branches différentes sur deux télécommandes différentes, chacune avec sa propre histoire.
RubberDuck
@RubberDuck Oui, exactement. Avec pull: Avant: deux branches pointant potentiellement vers des validations différentes - Après: deux branches pointant vers des validations équivalentes - Aucune branche créée, donc je n'appellerais pas cela une "opération de branchement". Si l'une des deux commandes, je l'appellerais push, car cela crée potentiellement une nouvelle branche dans la télécommande. Ce qu'il ne fait pas , c'est une fusion.
mkrieger1
@ mkrieger1, vous devez également prendre en compte la direction de la fusion.
RubberDuck
2

D'autres réponses ont déjà mentionné divers avantages (fonctionnalités isolées, code toujours livrable sur le maître, etc.) pour travailler PAS directement sur le maître.

Pour moi, vous semblez avoir un problème différent. De toute évidence, vous n'avez pas de processus de développement, qui est accepté ou utilisé par tous vos développeurs (ou votre développeur en question ignore totalement le processus).

Avez-vous des branches de fonctionnalités qui sont fusionnées dans master ou avez-vous également des branches de versions différentes ou utilisez-vous un processus totalement différent?

"Ne pas utiliser la branche principale" n'est pas suffisant.

Simon
la source
2

Un de nos collègues est très heureux d'apporter des modifications directement sur la branche principale, et malgré plusieurs conversations, il ne semble pas probable que cela change.

Cela m'amène à croire qu'il y a plus de problèmes. Travailler sur master ou non fait principalement partie d'une philosophie plus large sur comment, quoi et quand vous lancez des produits.

Donc, en tandem avec un "vous ne devriez jamais travailler sur master", avez-vous des tests de fonctionnalités, testez-vous le travail les uns les autres, passez-vous en revue le code de chacun. Tests d'acceptation et d'intégration.

Si vous n'avez rien de ce qui précède et que vous le faites juste pour "faire du git", vous pourriez aussi bien travailler sur master.

Pieter B
la source
1

Il n'y a aucune "mauvaise pratique" à travailler directement sur la branche. Mais vous devez décider ce qui soutient le mieux votre processus:

Question 1: Votre maître doit-il représenter l'état de sortie actuel de votre logiciel? Ensuite, vous devez introduire une branche de développement global et fusionner le développement à la fin du développement d'une version.

Question 2: Voulez-vous avoir un processus de révision du code? Ensuite, vous devriez avoir des "branches de fonctionnalités" qui seront fusionnées en master (ou développées, si vous en avez une) via des requêtes pull.

Question 3: Est-il nécessaire de partager l'état de code intermédiaire avec d'autres développeurs qui ne devraient pas encore être publiés en production (ou test)? C'est le cas où plus d'un développeur développe une fonctionnalité. Ensuite, vous devez introduire des "branches de fonctionnalités".

oopexpert
la source
Les balises sont un moyen très viable de représenter l'état d'une base de code à la sortie. Git permet de retirer très facilement une balise spécifique. Fait une sorte de branche de dev.
RubberDuck