Comment puis-je minimiser la douleur git quand tout le monde travaille sur master?

123

Notre équipe de documentation composée d’une dizaine de personnes a récemment quitté SVN pour Git. Dans SVN, tout le monde travaillait sur master - un modèle que j'ai toujours détesté, mais je n'ai pas été en mesure de provoquer ce changement. Dans le cadre de la migration vers Git, nous avons convenu de résoudre ce problème, mais nous ne pouvons pas le faire pour l'instant (attendre les modifications de construction qui autoriseraient les versions de branches arbitraires). Pendant ce temps, tout le monde travaille sur maître. Oui je sais que c'est terrible, croyez-moi.

Nous voyons beaucoup plus de problèmes maintenant que lorsque nous utilisions SVN, dont certains sont causés par le modèle en deux étapes de Git (local et distant). Parfois, les gens commettent des actes mais ne parviennent pas à faire pression, ou bien ils tirent des conflits avec les modifications locales en attente. Hier, quelqu'un a brouillé les modifications récentes - d'une manière ou d'une autre - avec une fusion qui a mal tourné, ce qui, à mon avis, était la fusion que fait Git lorsque vous effectuez des modifications en suspens. (Il n'a pas été en mesure de me dire exactement ce qu'il a fait et, comme il utilise une interface graphique, je ne peux pas simplement consulter l'historique de ses obus.)

En tant qu'utilisateur le plus compétent de Git (lire: je l'ai déjà utilisé, mais pas pour quelque chose de très compliqué), je suis la personne qui définit les règles, définit les outils et nettoie les dégâts. Quels changements puis-je apporter à la façon dont nous utilisons les outils pour rendre un maître actif et partagé moins sujet à l'erreur jusqu'à ce que nous puissions passer au développement sur des branches?

L’équipe utilise Tortoise Git sous Windows. Nous utilisons Tortoise Git parce que nous utilisions auparavant Tortoise SVN. ( J'utilise personnellement la ligne de commande sous Cygwin pour certaines opérations, mais l'équipe a clairement indiqué qu'elle avait besoin d'une interface graphique et nous y allons.) Les réponses devraient fonctionner avec cet outil, pas proposer de remplacements.

Tortoise Git a "Commit & Push" disponible en une seule opération et je leur ai dit de toujours le faire. Cependant, ce n'est pas atomique - il peut arriver que le commit (qui après tout soit local) fonctionne très bien mais que la poussée ne fonctionne pas (par exemple, à cause d'un conflit ou d'un problème de réseau). Lorsque cela se produit, ils obtiennent une erreur ambiguë; Je leur ai dit de vérifier le journal de validation de BitBucket s'ils ont des doutes sur une validation récente et, s'ils ne le voient pas, de pousser. (Et pour résoudre le conflit si tel est le problème, ou demandez de l'aide s'ils ne savent pas quoi faire.)

L’équipe a déjà la bonne habitude de «tirer tôt et souvent». Cependant, il semble que l’attraction puisse causer des conflits, ce qui, à mon avis, est nouveau? Si ce n'est pas nouveau, beaucoup plus fréquent que dans SVN. J'ai entendu dire que je pouvais changer la façon dont Git tire (rebaser au lieu de fusionner), mais je ne comprends pas bien les compromis qui existent là-bas (ni comment le faire dans notre environnement).

Le serveur est BitBucket (pas Github). J'ai un contrôle administratif total sur notre référentiel, mais aucun sur le serveur en général. Rien de tout cela n'est modifiable.

Les fichiers sources sont XML. Il existe également des fichiers graphiques, que tout le monde sait que vous ne pouvez pas fusionner, mais nous n’avons presque jamais de collision. Les conflits de fusion proviennent des fichiers XML, pas des graphiques.

Quels changements puis-je apporter à notre utilisation de Git pour rendre le partage principal plus fluide pour l'équipe jusqu'à ce que nous puissions passer à l'utilisation de branches de fonctionnalités avec des demandes d'extraction examinées et validées par des tests?

Monica Cellio
la source
52
N'utilisez pas de tortue, utilisez les extensions Git. Tortoise essaie de cacher que Git n'est pas SVN et détruit la plus grande partie de sa grandeur. J'ai traversé deux fois la transition SVN-> Git, et Git Extension était un excellent outil pour amener les gens à penser de la même manière.
Wilbert
91
Git n'est pas SVN. Si vous essayez de répliquer SVN avec Git, vous obtenez tous les points douloureux de SVN avec tous les points douloureux de Git combinés, sans aucun des avantages des deux, cela ne fonctionnera tout simplement pas. Le plus gros problème que vous rencontrez est un problème social: certains membres de votre équipe refusent d’apprendre de nouveaux concepts. Vous ne pouvez pas résoudre ce problème avec une solution technique, vous devez commencer par obtenir l’assentiment des membres de votre équipe pour apprendre les concepts de Git plutôt que d’essayer de les convaincre que c’est comme du SVN.
Lie Ryan
10
Je sais que vous avez dit de ne pas recommander d'autres applications, mais @ Wilbert a raison. TortoiseGit essaie de cacher des choses, ce qui les rend plus douloureuses dans mon expérience. Si une interface utilisateur est souhaitée, j'ai trouvé la transition la plus facile (lire: je forme des équipes logicielles non traditionnelles sur l'outillage et DevOps) via SourceTree d'Atlassian (avec une formation appropriée, bien sûr). J'ai également utilisé GitFlow pour les aider à comprendre le modèle de Git (bien que cela ne convienne pas à toutes les équipes).
JasCav
28
Je suis un peu surpris que tout le monde craint de travailler sur le maître, principe fondamental de l' intégration continue . Tant que vous disposez d'une suite de tests robuste et que tout le monde sait que la construction est interrompue, travailler à partir du maître peut être avantageux pour la collaboration en équipe. La création de branches (sur laquelle s'appuient à peu près tous les autres flux de travail) peut être tout aussi destructive sans protection mise en place. Vous avez probablement des problèmes fondamentaux plus profonds en jeu ici.
DanK
14
@DanK, je pense aussi que l'op a mal identifié la racine du problème. Si vous avez des personnes qui modifient des modifications sur le maître et que vous passez à une branche, vous aurez des personnes qui répercutent des modifications sur la branche. Si vous passez à des branches individuelles, vous rencontrerez des personnes qui ont des problèmes de fusion dans leurs branches (ou qui se développent sur leur branche sans fusionner pendant des mois).
user3067860

Réponses:

11

Jusqu’à présent, SourceTree était le meilleur IDE pour apprendre les concepts, car il montre tous les dialogues et options pertinents que vous avez sur chaque étape, les options par défaut sont généralement correctes, ne jouez pas avec rebase, etc. Suivez simplement le flux normal:

  • Tirez sur maître, juste pour être sûr d'être à jour
  • Modifier vos fichiers
  • Commettez vos modifications (uniquement localement)
  • Tirez à nouveau du maître (cela provoquera des conflits)
  • Modifiez tous les fichiers jusqu'à ce que les conflits soient résolus, ce qui signifie que le fichier se trouve dans l'état approprié que vous souhaitez valider (aucun message <<<<< HEAD et >>>> maître dans le fichier brut).
  • Valider les modifications de fusion
  • Pousser

Si tout le monde suit cette recette, ça devrait aller.

Chaque fois que quelqu'un effectue un changement plus important ou central, demandez aux autres utilisateurs de s’engager localement et d’extraire du maître afin qu’ils ne rencontrent pas trop de conflits par la suite et que la première personne soit toujours disponible pour résoudre les conflits avec eux.

Consacrez beaucoup de temps à faire en sorte que tout le monde comprenne le flux, sinon ils risquent de se déplacer un moment, puis se sentent à l'aise avec le système tout en bousillant la branche principale. Par exemple, "utiliser mon fichier au lieu de à distance" pour résoudre un conflit ne fera que commencer. tous les changements effectués par d'autres personnes.

Git est un système difficile à apprendre, surtout si vous avez grandi avec Svn, soyez patient et donnez-leur le temps de l'apprendre correctement. Avec les nouveaux utilisateurs, vous pouvez parfois passer une journée à nettoyer des dégâts, ce qui est normal. ;)

Mike M.
la source
9
nitpick: SourceTree n'est pas un environnement de développement intégré ...
Mathieu Guindon
J'ai quelqu'un (autre que moi) qui teste actuellement ce flux de travail (avec Tortoise Git, je veux dire) pour éviter les surprises / problèmes. En supposant qu’il n’y en ait pas, j’ai l’intention de le transmettre à l’équipe d’ici quelques jours.
Monica Cellio
Je sais que cette réponse très votée couvre une grande partie du même territoire que celui-ci, mais ce n'est que lorsque j'ai vu la recette présentée pas à pas dans cette réponse que j'ai vraiment compris comment l'appliquer. accepte celui-ci (pour la recette, pas pour l'IDE :-)). Nous suivons ce processus depuis quelques jours sans autre problème. Nous nous concentrerons également davantage sur l'exploration et la compréhension de la "méthode géniale".
Monica Cellio
99

Lorsque vous travaillez dans la même branche que quelqu'un d'autre, vous devez vous rappeler trois points principaux:

  • N'utilisez jamais --forcesi vous ne savez pas vraiment ce que vous faites.
  • Soit commitou stashvotre travail en cours avant chaque pull.
  • Cela va généralement plus facile si vous avez pulljuste avant push.

En dehors de cela, je ferai remarquer qu'avec le contrôle de version distribué, peu importe que votre référentiel "officiel" utilise des branches ou non. Cela n’a aucune incidence sur ce que les utilisateurs individuels font dans leurs dépôts locaux. J'avais l'habitude d'utiliser git pour obtenir des branches locales lorsque mon entreprise utilisait un VCS central complètement différent. S'ils créent des branches locales pour leurs fonctionnalités et font des erreurs de fusion dans leurs sections locales master, il est beaucoup plus facile de les réparer sans entrer dans le reflet ou une autre magie.

Karl Bielefeldt
la source
51
Toujours pullavant pushest un bon conseil, mais je voudrais aller un peu plus loin et vous suggère de considérer si vous le pouvez pull --rebasequand vous le faites.
Anaximander
20
@ anaximander, je recommanderais que tout le monde utilise --rebase ou personne ...
keuleJ
12
@TemporalWolf C'est aussi ce qu'ils m'ont dit à propos du gâteau ...
BlackVegetable
15
@ anaximander "alors vous n'avez pas résolu le conflit, et vous le faites mal. Dans ce cas, on ne peut pas faire confiance à leur base". Donc, vous dites que vous n'avez jamais foiré un conflit de fusion? Doit être agréable de travailler sur des bases de code assez simples pour que vous puissiez faire cette généralisation. Voici la position de Linus sur le rebase, que je trouve personnellement plus agréable que toutes ces approches en noir et blanc.
Voo
10
"Ne l'utilisez jamais --forcesi vous ne savez pas vraiment ce que vous faites." J'irais plus loin. Désactivez l' historique de réécriture dans le référentiel "principal" pour tout le monde, à l'exception des personnes les plus fiables. Que cela soit possible ou non dépend en partie de votre hébergement, mais BitBucket a l'option.
jpmc26
68

Est-il possible de prendre un jour pour tout le monde à apprendre git?

Les professionnels de l’informatique devraient vraiment s’attendre à apprendre un nouvel outil et, bien qu’il soit possible de faire beaucoup d’erreurs dans n’importe quel VCS, ils devraient utiliser l’outil tel qu’il a été conçu.

Le meilleur moyen de le présenter est de faire en sorte que chacun travaille sur sa propre branche quand ils effectuent un changement (aussi bref que possible) et se rebasent puis fusionnent à nouveau lorsqu'ils sont terminés. Cela n’est pas si éloigné de la façon de travailler actuelle et introduit un flux de travail simple auquel ils peuvent s’habituer jusqu’à ce qu’ils se sentent suffisamment en confiance pour effectuer des opérations plus compliquées.

Je n'utilise pas les fenêtres, mais si Tortoise leur cache en substance et prétend que c'est SVN, alors Tortoise est peut-être le mauvais outil.

MarkJL
la source
37
"Si Tortoise leur cache fondamentalement des idiots et prétend que c'est un SVN, alors peut-être que Tortoise est le mauvais outil." cette. Je sais que OP a dit de ne pas remplacer l'outil, mais s'il obscurcissait le fonctionnement de git, cela nuirait à la croissance personnelle de vos développeurs et à votre efficacité opérationnelle. Votre équipe continuera à abuser de votre VCS s’ils ne le comprennent pas.
2rs2ts
3
Learn Git Branching est une autre ressource d’apprentissage git utile . Il présente une arborescence visuelle et comporte en outre un bac à sable afin que vous puissiez vous moquer de nombreuses commandes et voir quel type d'arborescence en résulte.
TemporalWolf
4
Il a fallu beaucoup plus de temps qu'une journée à tous les membres de l'équipe de développement pour apprendre git (et ce ne sont ni des fainéants ni des fainéants), alors j'ai supposé que ce serait également vrai pour l'équipe de doc. Je vais jeter un oeil sur les sites mentionnés ici dans les commentaires (peut-être qu'ils devraient figurer dans cette réponse ou dans une autre?).
Monica Cellio
3
Vous n’apprendrez git que si toutes les erreurs ont été commises et que des fusions et des reflexions contradictoires vous ont échappé. Il leur suffit d’apprendre à peu près tout ce qu’il faut faire pour créer une branche, la rebasonner pour y inclure les modifications apportées par fusionner leur branche dans le maître. N'importe quel autre apprentissage qu'ils peuvent faire pour tenter de résoudre la douleur qu'ils rencontrent dans ce flux (il y en aura). Au moins l'équipe de doc n'a pas le souci de casser la base de code.
MarkJL
1
@ 2rs2ts Tortoise Git est un git gui exceptionnel. Je l’installe sur toutes mes machines Windows et je connais très bien la ligne de commande git. Son outil de navigation est l'un des meilleurs que j'ai jamais utilisés. J'ai initié beaucoup d'utilisateurs novices à utiliser git Tortoise Git. Son plus gros problème est qu'il expose certaines des options avancées de git avec une simple case à cocher. Ainsi, une option comme --force push pourrait être réalisée en cochant simplement une case dans l'interface graphique. C'est probablement ce qui a été fait qui a perdu le travail. Je n'utilise pas beaucoup Tortoise, mais il y a quelques petites choses que cela rend vraiment plus simple.
gnash117
26

Parfois, ce que vous faites doit changer.

Le plus gros problème est que tout le monde est travaille sur le maître. Ce n'est pas typique pour le développement de code, et pourrait également être le mauvais modèle dans votre cas. Si vous pouvez changer cela en demandant / exigeant que les changements soient apportés sur des branches distinctes, vous serez beaucoup mieux en forme. Avec les branches, vous pouvez obtenir les avantages suivants:

  • Assurez-vous qu'aucune poussée directement à mastersont autorisés.
  • Appliquez via Bitbucket que les demandes d'extraction sont créées et ont au moins une approbation avant la fusion . Cela garantit que quelqu'un regarde les modifications et rend également la fusion moins pénible, car l'interface utilisateur affichera des conflits avec la version distante du code, et non pas ce que l'utilisateur a sur le bureau. Cela empêche le scénario de validation réussie-mais-poussée-échouée.
  • Exécutez des "builds" sur votre repo avant de les fusionner. Je me rends compte que c’est un repo doc, mais peut-être qu’il ya une vérification orthographique, un raclage juridique ou même une traduction automatique (exportation de choses STRING_DEF dans un fichier csv) qui pourrait être construite à partir de cette construction. Ou peut-être pas, dépend de votre travail.
  • Permettez aux gens de travailler sur plusieurs choses différentes simultanément plus facilement. Oui, cela peut aussi être fait avec des caches, mais c'est un peu plus salissant et quelque chose me dit que vous ne les utilisez pas non plus.

Si vous ne pouvez pas utiliser les branches, vous pouvez envisager d'écrire un merge-and-pushscript qui pourrait automatiser certains des problèmes rencontrés. Peut-être vérifierait-il que l'utilisateur n'est pas en retard sur le maître, effectuera une extraction et une extraction, puis tentera la fusion ( éventuellement avec--no-commit --no-ff ), etc.

Dan1701
la source
3
Nous allons passer aux succursales, pour toutes les raisons que vous avez mentionnées (mais plus particulièrement, les RP contrôlées et la possibilité de faire en sorte que les conflits soient résolus sur les succursales avant la fusion). Pourriez-vous en dire plus sur la façon d'attaquer un script de fusion et d'envoi?
Monica Cellio
6
Je ne suis pas d'accord avec ce conseil. De longues branches de fonctionnalités peuvent être beaucoup plus dévastatrices que de travailler à partir du maître (ce qui va se passer si vous n’avez pas un bon flux de travail en place). Martin Fowler a un excellent article sur ce sujet. À la fin de la journée, l’équipe OP a un problème de collaboration dans le flux de travail, pas un problème avec Git. Je dirais que davantage de branches ne feront qu’aggraver ce problème.
DanK
6
Les longues branches de fonctionnalités ne sont pas ce que je préconisais (ni ne mentionnais). Je suis d'accord qu'ils sont mauvais pour le développement "régulier", et ne seraient pas meilleurs ici. Les branches régulières "ravioli" avec de petites séries de modifications pouvant être examinées / testées avant la fusion sont très utiles et ne le seraient pas moins ici simplement parce qu’il s’agit d’un dépôt de documentation pour toutes les raisons énoncées dans la réponse.
Dan1701
3
Bien sûr, je comprends ce que vous dites et je ne suis pas en désaccord en théorie, mais avec les problèmes de collaboration décrits ici, même avec les meilleures intentions du monde, je pense que les branches de l’équipe OP se transformeront toutes par inadvertance en branches de longue durée. À la fin de la journée, le problème fondamental n’est pas de travailler ici. Le problème est un manque général de compréhension des tenants et des aboutissants d'un VCS distribué et un manque de collaboration / cohésion entre les développeurs. La création de branches par elle-même ne résoudra pas le problème, mais l'OMI l'exacerbe.
DanK
2
Nous sommes sur le point de devoir déplacer ceci pour discuter, mais si vous êtes toujours sur une branche de fonctionnalité, vous ne terminez pas votre travail. Ils doivent être fusionnés avec la branche livrée (ou publiés, dans ce cas). Cela permet d'introduire des contrôles automatisés et des sauvegardes autour des problèmes rencontrés par leur équipe. Une branche de fonctionnalité diffère totalement du travail sur maître en ce sens que la plupart des outils (au moins Bitbucket) sont configurés pour permettre les requêtes d'extraction avec les approbations requises et les générations préalables à la fusion dans le cadre du modèle de branche, ce qui n'est pas le cas lorsque vous travaillez uniquement sur master.
Dan1701
12

Soulignez que vous pouvez refaire des fusions

Cela peut sembler évident pour vous, mais les anciens utilisateurs de SVN pourraient ne pas être conscients qu'ils peuvent essayer de résoudre une fusion plusieurs fois. Cela pourrait réduire le nombre d'indicateurs d'aide reçus.

Dans SVN, lorsque vous travaillez hors de trunkvous aurait des changements non engagés assis autour. Ensuite, vous feriez un svn update. À quel point vos changements se mélangeraient avec les changements des autres peuples pour toujours. Il n'y avait aucun moyen de l'annuler (autant que je sache), vous n'aviez donc pas d'autre choix que de tout vérifier manuellement et d'espérer que le dépôt était en bon état. Quand vraiment vous seriez beaucoup plus à l'aise juste de refaire la fusion.

Les gens auraient la même mentalité même quand nous sommes passés à git. Menant à beaucoup d'erreurs non intentionnelles.

Heureusement, avec git, il y a un moyen de revenir, en particulier parce que vous pouvez faire des commits locaux. (Je décris plus tard comment cela est exprimé dans la ligne de commande)

Bien que la façon dont cela est fait variera selon l’outillage Je trouve que refaire un pull n'est pas quelque chose exposé dans de nombreuses interfaces graphiques en tant que bouton unique, mais est probablement possible. J'aime utiliser cygwin. Mes collègues utilisent sourcetree. Puisque vous utilisez BitBucket, il serait judicieux de l’utiliser comme interface graphique, celle-ci étant gérée par la même société: Atlassian. Je soupçonne une intégration plus étroite.

En ce qui concerne les tractions

Je pense que vous avez raison de dire que la fusion a pour effet de pullgâcher les gens. A pullest en fait git fetchqui récupère les modifications du serveur, suivi de git merge origin/<branchname>* qui fusionne les modifications distantes dans votre branche locale. ( https://git-scm.com/docs/git-pull )

Le résultat est que toutes les commandes de fusion standard fonctionnent avec pull. Si cette fusion présente des conflits, vous pouvez abandonner git merge --abort. Ce qui devrait vous ramener avant votre fusion. Ensuite, vous pouvez réessayer avec git pullou git merge origin/<branchname>.

Si vous pouvez en quelque sorte apprendre à faire ce qui précède à l' aide de l'outil de choix de l'interface graphique de vos collègues, je pense que cela résoudra la plupart de vos problèmes. Désolé je ne peux pas être plus spécifique.

* Je comprends que l'origine n'est pas toujours le cas ici.

Utiliser git reflogpour diagnostiquer les problèmes

Comme vous, je dois diagnostiquer les problèmes résultant principalement d'une mauvaise utilisation des outils d'interface graphique. Je trouve que cela git reflogpeut parfois être utile car cela constitue une suite assez cohérente d’actions sur le référentiel. Bien qu'il soit difficile de lire parfois.

Une alternative

Étant donné que votre situation est temporaire , vous pouvez simplement revenir à SVN jusqu'à ce que le processus de déploiement soit en place. J'hésiterais à le faire car de nombreux endroits ne cessaient de dire: "Nous avons essayé une fois, mais ça n'a pas fonctionné ..." et nous ne l'avons jamais vraiment repris.

Quelques autres problèmes de transition courants

  • Les gens supprimaient et refermaient souvent leur pension, convaincus qu'ils étaient inutilisables. Cela était généralement dû à une perte de connaissance de la différence locale et distante. Les outils de l'interface graphique et la CLI ne parviennent pas à montrer cela. Dans la CLI, je trouve git log --decoratele moyen le plus simple de voir les différences. Mais si les choses deviennent trop poilues sur maître (par exemple), vous pouvezgit reset --hard origin/master
jmathew
la source
2
Sur votre dernier point: pour un aperçu rapide et structurel, je trouve l’ git log --oneline --decorate --graphidéal. À tel point que j'ai défini un alias de shell pour cette combinaison précise.
cmaster
1
+1 pour votre réponse, je trouve que la solution suggérée est mauvaise, à cause de la raison que vous avez mentionnée. Vous aurez mal même si vous retournez à SVN puis à l'avenir allez chez git. Les membres de l'équipe n'apprendront le nouvel outil, différent et douloureux que s'ils n'ont pas d'autre choix. Ce n'est qu'après utilisation et après avoir commis des erreurs stupides qu'ils commenceront à comprendre ce que git peut faire.
CodeMonkey
8

Un mécanisme possible, adopté par de nombreuses équipes open source, consiste à utiliser le modèle de forking ( https://www.atlassian.com/git/tutorials/comparing-workflows) (assurez-vous d’énoncer clairement lorsqu’un flux de travail de forking git ) .

En cela, chaque développeur ou sous-équipe a son propre fork du référentiel qu’ils extraient de BitBucket fournit un mécanisme pour cela , définissant une origine "amont" en plus de la télécommande par défaut - ils devront penser à "extraire en amont" "et" fusionner maître / amont / maître "régulièrement.

Cela résoudra peut-être vos problèmes de mécanisme de construction car les outils de construction seraient éventuellement dirigés vers le maître d'un autre projet, par exemple le fork.

Vous pouvez alors supprimer de la plupart des personnes la possibilité de passer directement au projet principal et de créer une équipe plus réduite composée de personnes chargées de réviser et d’approuver les rôles. Voir https://www.atlassian.com/git/tutorials/making-a-pull-request

Pour vous assurer que toutes les vérifications souhaitables sont effectuées avant les envois incitatifs, reportez-vous à la section git book sur les hooks - https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks - vous pouvez utiliser des points d'ancrage pré-commit et pré-push pour effectuer des tests tels que l'exécution de tests sur le commit proposé pour vous assurer que le travail est valide, etc. - le seul problème avec les points d'ancrage côté client est que les développeurs peuvent les désactiver ou ne pas les activer. leur.

Les deux fonctions de récupération / fusion en amont sont disponibles dans TortoiseGit.

Steve Barnes
la source
Pas une mauvaise idée, vraiment. Il semble également que cette équipe bénéficierait d'un Master Merge jusqu'à ce qu'elle soit plus à l'aise. +1
Greg Burghardt
2
BitBucket a une fonctionnalité de synchronisation de fourchette qui permet de faire avancer rapidement les fourches quand cela est possible. Il est très pratique d’acheter aujourd’hui et d’arriver d’origine au départ la semaine prochaine sans jamais se soucier de l’amont.
pied
3

Cela va sembler contre-intuitif, mais écoutez-moi:

Encouragez-les à commencer à expérimenter avec git

L'un des aspects intéressants de git est qu'il est étonnamment facile de sécuriser complètement toute opération locale. Lorsque j'ai commencé à utiliser git, l'une des choses que je me trouvais capable de faire était de compresser l'intégralité du répertoire en tant que sauvegarde au cas où je ferais n'importe quoi. J'ai découvert par la suite que c’était un énorme kludge et qu’il n’était presque jamais nécessaire de protéger votre travail, mais cela a le mérite d’être très sûr et très simple, même si vous ne savez pas ce que vous faites et comment. la commande que vous voulez essayer deviendra. La seule chose que vous devez éviter lorsque vous faites cela est push. Si vous ne poussez rien, c’est un moyen sûr à 100% d’essayer ce que vous voulez.

La peur d'essayer des trucs est l'un des plus gros obstacles à l'apprentissage des imbéciles. Cela vous donne tellement de contrôle sur tout que c'est assez intimidant. La réalité est que vous pouvez vous en tenir à quelques opérations très sûres pour la plupart de vos utilisations quotidiennes, mais il est difficile de trouver les commandes qui vous conviennent.

En leur donnant un sentiment de sécurité , ils seront beaucoup plus disposés à essayer de comprendre comment faire les choses par eux-mêmes. Et ils seront beaucoup plus en mesure de trouver un flux de travail personnel sur leur machine locale qui fonctionne pour eux. Et si tout le monde ne fait pas la même chose localement , c'est bien, tant qu'ils adhèrent aux normes avec ce qu'ils poussent . S'il faut zipper l'intégralité du référentiel avant de procéder à une opération pour leur donner cette impression, c'est bien; ils peuvent trouver de meilleures façons de faire les choses au fur et à mesure qu'ils essaient. N'importe quoi pour que vous commenciez à essayer des choses et à voir ce qu'elles font.

Cela ne signifie pas que la formation ne vaut rien. Au contraire, la formation peut vous aider à vous familiariser avec les caractéristiques, les modèles et les normes. Mais ce n'est pas un remplacement pour s'asseoir et faire des choses dans votre travail quotidien. Ni git, ni SVN ne sont des choses que vous pouvez simplement aller à une classe et alors vous savez tout. Vous devez les utiliser pour résoudre vos problèmes, pour vous familiariser avec celles-ci et les fonctionnalités adaptées à chaque problème.

Arrêtez de les décourager d'apprendre les tenants et les aboutissants de git

J'ai dit de ne rien pousser, ce qui va en fait à l'encontre de ce que vous leur avez enseigné: toujours "Commit & Push". Je crois que vous devriez cesser de leur dire de faire cela et de leur dire de commencer à faire le contraire. Git a essentiellement 5 "endroits" où vos changements peuvent être:

  • Sur le disque, non engagé
  • Mis en scène mais non engagé
  • Dans un commit local
  • Dans une cachette locale
  • Référentiels distants (seules les validations et les balises sont poussées et extraites entre les différents référentiels)

Au lieu de les encourager à tirer et à pousser tout en un seul geste, encouragez-les à tirer parti de ces 5 lieux différents. Encouragez-les à:

  • Récupérer les modifications avant de commettre quoi que ce soit.
  • Faire une décision comment gérer les modifications extraites. Les options sont:

    • Validez leurs modifications locales, puis redéfinissez-les par-dessus les modifications extraites.
    • Commettez leurs modifications locales, puis effectuez une fusion avec les modifications extraites.
    • Rangez leurs modifications, fusionnez-les, puis décompactez-les et résolvez les conflits éventuels.

      Il y a d'autres choses, mais je n'entrerai pas dans les détails ici. Notez qu'un pull est littéralement juste un aller chercher et une fusion. Ce n'est pas comme eux il est eux. (Les --rebasemodifications de passage tirent de fetch + fusion en fetch + rebase.)

  • Mettez en scène leurs modifications, puis révisez-les.
  • Commettez leurs modifications par étapes, puis examinez le commit.
  • Poussez séparément.

Cela les encouragera à vérifier leur travail avant qu'il ne soit rendu public à tout le monde, ce qui signifie qu'ils verront leurs erreurs plus tôt. Ils verront le commit et penseront: "Attends, ce n'est pas ce que je voulais", et contrairement à SVN, ils peuvent revenir en arrière et réessayer avant de pousser.

Une fois habitués à comprendre où se trouvent leurs modifications, ils peuvent alors décider quand ignorer les étapes et combiner certaines opérations (quand extraire parce que vous savez déjà que vous voulez extraire + fusionner ou quand cliquer sur cette option Valider / Publier). .

C’est en fait l’un des avantages énormes de git par rapport à SVN, et git est conçu avec ce schéma d’utilisation. SVN, en revanche, suppose un référentiel central, il n’est donc pas surprenant que les outils de git ne soient pas optimisés pour le même flux de travail. En SVN, si votre commit est incorrect, votre seul recours est un nouveau commit pour annuler l’erreur.

Cela mènera naturellement à la stratégie suivante:

Encouragez-les à utiliser des branches locales

En fait, les branches locales facilitent beaucoup le travail sur des fichiers partagés. Je peux faire tous les changements que je veux dans ma propre branche, et cela n'affectera personne, puisque je ne les encourage pas. Ensuite, le moment venu, je peux utiliser toutes les mêmes stratégies de fusion et de refonte, mais plus facilement:

  • Je peux rebaser ma succursale locale, ce qui rend sa fusion en maître simple.
  • Je pourrais utiliser une fusion simple (créer un nouveau commit) en maître pour y intégrer les modifications de ma branche locale.
  • Je peux réduire la fusion de toute ma branche locale en un seul commit sur master si je pense que ma branche est trop difficile à sauver.

L'utilisation de branches locales est également un bon début pour élaborer une stratégie de branchement systématique. Il aide vos utilisateurs à mieux comprendre leurs propres besoins en matière de succursales. Vous pouvez donc choisir une stratégie en fonction des besoins et du niveau de compréhension / compétences de l'équipe et ne pas simplement utiliser Gitflow, car tout le monde en a entendu parler.

Sommaire

En bref, git n'est pas SVN et ne peut pas être traité comme tel. Tu dois:

  • Éliminez la peur en encourageant l'expérimentation en toute sécurité.
  • Aidez-les à comprendre en quoi git est différent pour qu'ils puissent voir en quoi cela modifie leur flux de travail normal.
  • Aidez-les à comprendre les fonctionnalités disponibles pour les aider à résoudre leurs problèmes plus facilement.

Tout cela vous aidera à adopter progressivement une meilleure utilisation de git, jusqu'à ce que vous puissiez commencer à mettre en œuvre un ensemble de normes.

Caractéristiques spécifiques

Dans l'immédiat, les idées suivantes pourraient aider.

Rebase

Vous avez parlé de rebase et que vous ne comprenez pas vraiment cela dans votre question. Alors, voici mon conseil: essayez ce que je viens de décrire. Apportez des modifications localement pendant que quelqu'un d'autre les pousse. Commettez vos modifications localement . Zip votre répertoire de référentiel en tant que sauvegarde. Récupère les modifications de l'autre personne. Maintenant, essayez de lancer une commande rebase et voyez ce qu'il advient de vos commits! Vous pouvez lire des articles de blog sans fin ou recevoir une formation sur rebase et sur la façon dont vous devriez ou ne pas l'utiliser, mais rien de tout cela ne remplace le voir en direct. Alors essayez -le.

merge.ff=only

Celui-ci va être une question de goût personnel, mais je vais le recommander au moins temporairement car vous avez déjà mentionné que vous aviez déjà des problèmes avec la gestion des conflits. Je recommande de régler merge.ffàonly :

git config --global merge.ff only

"ff" signifie "avance rapide". Une fusion rapide s'effectue lorsque git n'a pas besoin de combiner les modifications de différents commits. Cela déplace simplement le pointeur de la branche vers un nouveau commit le long d'une ligne droite du graphique.

En pratique, cela empêche d'empêcher git de créer automatiquement des commits de fusion. Donc, si je commets quelque chose localement puis que je récupère les modifications de quelqu'un d'autre, au lieu d'essayer de créer une validation de fusion (et éventuellement de forcer l'utilisateur à gérer les conflits), la fusion échouera. En effet, git n'aura effectué qu'un fetch. Lorsque vous n'avez pas d'engagement local, la fusion se déroule normalement.

Cela donne aux utilisateurs une chance de passer en revue les différents commits avant de tenter de les fusionner et les oblige à décider de la meilleure façon de les combiner. Je peux modifier la fusion, poursuivre la fusion (en utilisant git merge --no-ffpour contourner la configuration) ou bien simplement différer la fusion de mes modifications pour le moment et la gérer plus tard. Je pense que ce petit ralentisseur aidera votre équipe à éviter de prendre de mauvaises décisions concernant les fusions. Vous pouvez laisser votre équipe la désactiver une fois qu’elle sera mieux à même de gérer les fusions.

jpmc26
la source
2

J'ai vécu exactement la même expérience SVN -> git dans mon entreprise et, d'après mon expérience, le seul remède est le temps. Laissez les gens s'habituer aux outils, laissez-les commettre des erreurs, montrez-leur comment les réparer. Votre vitesse va souffrir pendant un certain temps et les gens vont perdre leur travail, et tout le monde sera un peu difficile, mais c'est la nature de changer quelque chose d'aussi fondamental que votre VCS.

Cela dit, je suis d'accord avec tous ceux qui sont d'avis que TortoiseGit est un obstacle plutôt qu'une aide, si tôt dans la période de transition. TortoiseGit n’est pas une excellente interface graphique dans le meilleur des cas, et en obscurcissant le fonctionnement réel de git au nom de la simplicité, il empêche également vos collègues de mieux comprendre les concepts de base de git tels que le commit en deux phases.

Nous avons pris la décision (assez radicale) de forcer les développeurs à utiliser la ligne de commande (git bash ou posh-git ) pendant une semaine, ce qui a fait des merveilles pour la compréhension du fonctionnement réel de git et de sa différence par rapport à SVN. Cela peut sembler drastique, mais je vous conseillerais de l'essayer simplement parce que cela crée cette compréhension du modèle de git - et une fois que tout est en place, vos collègues peuvent commencer à utiliser les façades de l'interface graphique de git qu'ils préfèrent.

Note finale: il y aura des collègues qui expliquent comment fonctionne immédiatement, et certains ne le feront jamais. Ce dernier groupe, il vous suffit d’enseigner aux incantations mystiques de faire en sorte que leur code passe de leur machine locale au serveur afin que tout le monde puisse le voir.

Ian Kemp
la source
1

Eh bien, récemment, j’ai adapté le flux de travail suivant pour ne jamais ficher la branche principale:

1) Chacun utilise sa propre branche, qui est initialement une copie de la branche principale.

Appelons la branche maître "master" et ma propre branche "my_master".

Je viens de faire ma branche à partir du maître, donc c'est exactement la même chose. Je commence à travailler sur une nouvelle fonctionnalité dans ma propre branche et, une fois cela fait, je fais ce qui suit.

Currenly sur ma branche, je viens de terminer le codage

git add . && git commit -m "Message" && git push

Retourner à la branche master

git checkout master

Tirez si ce n'est pas à jour

git pull

Retourner à ma propre branche

git checkout my_master

Fusionner le dernier maître dans ma propre branche

git merge master

Résoudre les conflits et les fusions

Tout tester à nouveau

Lorsque tout est fusionné et corrigé sur ma propre branche, appuyez dessus

git push

Retourner à la branche master

git checkout master

Fusionner avec ma branche

git merge my_master

Impossible d'avoir des conflits car ils sont résolus sur votre propre branche avec une fusion précédente

Pousser le maître

git push

Si tout le monde suit ceci, la branche principale sera propre.

TanguyB
la source
0

Nous avons donc une équipe qui est passée de TFS à git et a conservé les anciennes façons de penser. Les règles générales de fonctionnement sont plus ou moins les mêmes.

Oui, cela signifie que tout le monde travaille sur maître. Ce n'est pas si grave et une équipe habituée à TFS ou SVN trouvera cela très naturel.

Procédures générales pour rendre cela aussi indolore que possible:

  1. faire git stash && git pull --rebase && git stash poptous les matins
  2. s'engager tôt et souvent (il n'est pas nécessaire de pousser immédiatement; nous pouvons au moins commencer à prendre cet avantage de git tôt)
  3. pour pousser faire la boucle suivante:

    git add git commit git pull --rebase fix any merges compile git push loop until you don't get the can't fast forward error message.

Josué
la source
Si vous faites cela, vous pouvez aussi bien rester avec SVN. Dans le même état d'esprit que vous pouvez rester avec des calèches à l'époque des automobiles. Bien entendu, vous pouvez conduire votre voiture à la même vitesse qu’en calèche. Mais tout ce que vous obtenez avec ceci est de vous entraver et de mettre en colère les personnes capables de conduire une voiture. Apprenez à conduire votre voiture. Maintenant.
cmaster
@cmaster: Pour nous, l'avantage n ° 1 de git était que la perte du serveur ne perdait pas tout l'historique de contrôle du code source. (Cela nous est arrivé - nous avions des sauvegardes, mais le lecteur de bande a commencé à manger des bandes lorsque nous avons essayé de restaurer.)
Joshua
@cmaster: Nous avons commencé à introduire d'autres fonctionnalités utiles de git depuis, mais les changements de branches ne seront probablement pas utilisés.
Josué
@ cmaster La différence entre conduire une voiture lentement et monter à cheval est que conduire la voiture vous prépare à la conduire plus rapidement. Monter le cheval ne le fait pas. Toutes les personnes qui montent dans une voiture ne doivent pas forcément utiliser l’essence pour atteindre 100 km / h les premières fois.
jpmc26
@ jpmc26 Lorsque j'ai pris mes tout premiers cours de conduite, on m'a demandé de conduire à 30 km / h, et je pense que cette leçon incluait également une courte distance à 50 km / h. C'est certainement plus qu'une calèche typique. Et il en va de même pour git: Vous apprenez généralement à bifurquer et fusionner dès le premier jour. C'est une partie intégrante de l'utilisation git. Évitez cela, et vous abusez de l'outil de la même manière que vous abusez d'une voiture lorsque vous ne dépassez pas 15 km / h.
cmaster
-3

Si tout le monde travaille sur master, vous ne pouvez rien faire. Les choses vont inévitablement se brouiller.

Vous devez utiliser maître pour les produits finis envoyés à un client. Vous devez utiliser le développement pour le développement en cours, et vous devriez ne pas permettre à quiconque de pousser au développement. La norme est que tout le monde branche de dev, apporte ses modifications, les pousse de local à sa branche sur le serveur et envoie une demande de push. Ensuite, quelqu'un passe en revue le changement et le fusionne en développement.

Pour éviter les conflits, tout le monde fusionne le développement dans sa propre branche avant de pousser et résout les conflits à ce stade (de sorte que cela n'affecte qu'un développeur localement). Si la fusion dans le développement entraîne des conflits, elle n'est pas fusionnée. Le développeur fusionne à nouveau le développement dans sa branche, puis envoie à nouveau le serveur sur le serveur, puis il est réexaminé.

Vous pouvez utiliser par exemple sourcetree pour que cela fonctionne sans douleur.

gnasher729
la source
4
Cela remplace simplement "maître" par "développement", avec le risque supplémentaire que des personnes ne passent pas à la branche de développement après une validation par défaut. Je préfère GitLab Flow , qui est un juste milieu entre le GitFlow lourd et le GitHub Flow clairsemé.
Cees Timmerman
@CeesTimmerman Si vous ne l' aimez pas Gitflow, vous pourriez être intéressé par ONEFLOW aussi.
jpmc26