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

Question

Notre équipe de documentation d'une dizaine de personnes est récemment passée de SVN à Git. Dans SVN, tout le monde a travaillé sur master - un modèle que j'ai toujours détesté, mais je n'ai pas pu apporter ce changement. Dans le cadre du passage à Git, nous avons convenu de résoudre ce problème, mais nous ne pouvons pas le faire pour l'instant (en attendant les modifications de build qui permettront les builds à partir de branches arbitraires). Pendant ce temps, tout le monde travaille sur master. Oui, je sais que c'est terrible, croyez-moi.

Nous voyons beaucoup plus de hoquets maintenant que lorsque nous utilisions SVN, dont certains sont causés par le modèle à deux étapes de Git (local et distant). Parfois, les gens s'engagent mais échouent à pousser, ou ils tirent et obtiennent des conflits avec leurs changements locaux en attente. Hier, quelqu'un a bouleversé les changements récents - d'une manière ou d'une autre - avec une fusion qui a mal tourné, ce qui, je pense, était la fusion que Git fait lorsque vous tirez et avez des changements en suspens. (Il n'a pas pu me dire exactement ce qu'il a fait, et parce qu'il utilise une interface graphique, je ne peux pas simplement inspecter son historique Shell.)

En tant qu'utilisateur Git le plus compétent (lire: Je l'ai déjà utilisé, mais pas pour quelque chose de super compliqué), je suis la personne qui définit la politique, enseigne 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 partagé et actif moins sujet aux erreurs jusqu'à ce que nous puissions passer au développement sur les succursales?

L'équipe utilise Tortoise Git sur Windows. Nous utilisons Tortoise Git parce que nous utilisions auparavant Tortoise SVN. ( I 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 allons avec celle-ci. ) Les réponses devraient fonctionner avec cet outil, et non proposer des 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 pas le Push (par exemple, en raison 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 n'importe lequel 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 peut provoquer des conflits, ce qui, je pense, 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 n'ai pas une bonne compréhension des compromis là-bas (ou comment le faire dans notre environnement).

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

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

Quelles modifications puis-je apporter à notre utilisation de Git pour faciliter le partage du maître 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 les tests?

Answer 1

Jusqu'à présent, SourceTree était le meilleur IDE pour apprendre les concepts, car il montre toutes les boîtes de dialogue et options pertinentes que vous avez à chaque étape, les options par défaut sont généralement bien, ne plaisante pas avec rebase , etc. Suivez simplement le flux normal:

• Tirez du maître, juste pour être sûr d'être à jour
• Modifiez vos fichiers
• Validez vos modifications (c'est uniquement localement)
• Tirez à nouveau du maître (cela provoquera l'apparition de conflits)
• Modifiez tous les fichiers jusqu'à ce que les conflits soient résolus, ce qui signifie que le fichier est dans l'état propper que vous souhaitez valider (pas de <<<<<< HEAD et >>>> messages principaux dans le fichier brut)
• Validez 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, informez les autres utilisateurs de s'engager localement et de retirer du maître, afin qu'ils n'obtiennent pas trop de conflits plus tard et que la première personne soit toujours là pour résoudre les conflits avec eux.

Investissez beaucoup de temps pour que tout le monde comprenne le flux, sinon ils pourraient se déplacer un moment et se sentir à l'aise avec tout en vissant la branche principale, par exemple "utiliser mon fichier au lieu de la télécommande" pour résoudre un conflit toutes les modifications apportées 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 de nouveaux utilisateurs, vous pouvez parfois passer une journée à nettoyer des dégâts, c'est normal. ;)

Answer 2

Il y a trois choses principales à retenir lorsque vous travaillez dans la même branche que quelqu'un d'autre:

• Ne jamais utiliser --force à moins que vous ne sachiez vraiment ce que vous faites.
• Soit commit ou stash votre travail en cours avant chaque pull.
• Cela devient généralement plus facile si vous pull juste avant un Push.

En dehors de cela, je soulignerai qu'avec le contrôle de version distribué, peu importe si votre dépôt "officiel" utilise des branches ou non. Cela n'a aucune incidence sur ce que font les utilisateurs individuels dans leurs dépôts locaux. J'utilisais git pour obtenir des succursales 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 avec leur master local, c'est beaucoup plus facile à corriger sans entrer dans le reflog ou une autre magie.

Answer 3

Est-il possible de prendre une journée pour que tout le monde apprenne le git?

Les professionnels de l'informatique devraient vraiment apprendre un nouvel outil et bien qu'il soit possible de faire de nombreuses erreurs dans n'importe quel VCS, ils devraient utiliser l'outil tel qu'il est conçu pour être utilisé.

La meilleure façon d'introduire cela est de faire en sorte que chacun travaille sur sa propre branche quand il fait un changement (aussi court que possible) et rebase puis fusionne de nouveau en maître quand il a terminé. Ce n'est pas trop loin 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 de fenêtres mais si Tortoise leur cache fondamentalement du git et fait semblant qu'il s'agit de SVN, alors peut-être que Tortoise n'est pas le bon outil.

Answer 4

Parfois, ce que vous faites doit changer.

Le plus gros problème est que tout le monde est travaille sur master. 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 effectués sur des branches distinctes, vous serez en bien meilleure forme. Avec les succursales, vous pouvez gagner ce qui suit:

• Imposer qu'aucune poussée directe vers master n'est autorisée.
• Appliquer via Bitbucket que les demandes d'extraction sont créées et ont au moins une approbation avant la fusion . Cela garantit que quelqu'un examine les modifications et rend également la fusion elle-même moins pénible, car l'interface utilisateur affichera des conflits avec la version distante du code, et non avec ce que l'utilisateur a sur le bureau. Cela empêche le scénario de validation réussie mais d'échec de la poussée.
• Exécutez des "builds" sur votre référentiel avant la fusion. Je me rends compte que c'est un dépôt de document, mais peut-être qu'il y a une vérification orthographique, un grattage de légalité ou même une traduction automatisée (exportez STRING_DEF dans un fichier csv) qui pourraient être construits à partir de cette version. Ou peut-être pas, cela dépend de votre travail.
• Permettez aux gens de travailler simultanément sur plusieurs choses différentes plus facilement. Oui, cela peut aussi être fait avec des cachettes, mais c'est un peu plus compliqué et quelque chose me dit que vous ne les utilisez pas non plus.

Si vous ne pouvez pas utiliser la ramification, vous pourriez envisager d'écrire un merge-and-Push script qui pourrait automatiser certains des points douloureux. Il vérifiera peut-être 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.

Answer 5

Soulignez que vous pouvez refaire des fusions

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

Dans SVN, lorsque vous travaillez hors de trunk, vous avez des modifications non validées. 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 (afaik), 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 de refaire la fusion.

Les gens auraient la même mentalité même lorsque nous sommes passés à Git. Menant à beaucoup d'erreurs involontaires.

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

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

Concernant les tractions

Je pense que vous avez raison de dire que la fusion de pull est ce qui dérange les gens. Un pull est en fait git fetch qui récupère les modifications du serveur, suivi de git merge Origin/<branchname> * qui fusionne les modifications à distance 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 comporte des conflits, vous pouvez abandonner en git merge --abort. Ce qui devrait vous ramener avant votre fusion. Vous pouvez ensuite réessayer avec git pull ou git merge Origin/<branchname>.

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

* Je comprends qu'Origin n'est pas toujours le cas ici.

Utilisation git reflog pour diagnostiquer les problèmes

Je dois, comme vous, diagnostiquer les problèmes créés principalement par une mauvaise utilisation des outils de l'interface graphique. Je trouve que git reflog peut parfois être utile car il s'agit d'une piste d'actions assez cohérente sur le référentiel. Bien qu'il soit parfois difficile à lire.

Une alternative

Étant donné que votre situation est temporaire, vous pouvez simplement revenir à SVN jusqu'à ce que le processus soit en place pour être déployé. J'hésiterais à le faire car de nombreux endroits continueraient à dire `` Nous avons essayé Git une fois mais cela n'a pas fonctionné ... '' et je ne l'ai jamais vraiment repris.

Quelques autres problèmes de transition courants

• Les gens supprimaient et reconclaient souvent leur dépôt, étant convaincus que leur dépôt était dans un état inutilisable. Habituellement, cela a été causé par la perte de la trace de la différence locale et distante. Les outils GUI et l'interface CLI ne parviennent pas à bien le montrer. Dans l'interface CLI, je trouve git log --decorate le moyen le plus simple de visualiser les différences. Mais si les choses deviennent trop poilues sur le maître (par exemple), vous pouvez git reset --hard Origin/master

Answer 6

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

Dans ce cas, chaque développeur ou sous-équipe a sa propre fourchette du référentiel à partir de laquelle il extrait BitBucket fournit un mécanisme pour cela, définissant une origine "en amont" en plus de la télécommande par défaut - ils devront se rappeler de "récupérer en amont" et de "fusionner à distance/en amont/maître" régulièrement.

Cela résoudra peut-être vos problèmes de mécanisme de génération, car les outils de génération pourraient être dirigés vers le maître sur un projet différent, c'est-à-dire la fourche.

Vous pouvez ensuite retirer à la plupart des gens la possibilité de pousser directement vers le projet principal et d'en faire une petite équipe de personnes avec des rôles de révision et d'approbation. Voir https://www.atlassian.com/git/tutorials/making-a-pull-request

L'endroit pour lire pour s'assurer que presque toutes les vérifications souhaitables sont effectuées avant les poussées est dans la section du livre git sur les crochets - https://git-scm.com/book/gr/v2/Customizing-Git- Git-Hooks - vous pouvez utiliser des hooks pré-commit et pre-Push pour faire des choses comme exécuter des tests sur le commit proposé pour vous assurer que le travail est valide, etc. - le seul problème avec les hooks côté client est que les développeurs peut les désactiver ou ne pas les activer.

Les deux extractions/fusions et crochets en amont sont disponibles dans TortoiseGit.

Answer 7

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

Encouragez-les à commencer à expérimenter avec git

Une des choses intéressantes à propos de git est qu'il est étonnamment facile de sécuriser n'importe quelle opération locale. Quand j'ai commencé à utiliser git, une des choses que je me suis retrouvé à faire était zipper tout le répertoire comme sauvegarde au cas où j'aurais foiré quelque chose. J'ai découvert plus tard que c'est un énorme kludge et n'est presque jamais réellement nécessaire pour protéger votre travail, mais il 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 souhaitez essayer se révélera. La seule chose que vous devez éviter lorsque vous effectuez cette opération est Push. Si vous ne poussez rien, c'est un moyen 100% sûr d'essayer tout ce que vous voulez.

La peur d'essayer des trucs est l'un des plus grands obstacles à l'apprentissage de Git. Cela vous donne donc beaucoup de contrôle sur tout ce que c'est un peu intimidant. La réalité est que vous pouvez vous en tenir à quelques opérations très sûres pour la plupart de votre utilisation quotidienne, mais trouver quelles commandes il s'agit de quelques explorations.

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 autorisés à 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 respectent les normes avec ce qu'ils Push. S'il faut zipper tout le référentiel avant de faire une opération pour qu'ils se sentent de cette façon, c'est bien; ils peuvent trouver de meilleures façons de faire les choses au fur et à mesure qu'ils essaient. Tout pour vous permettre de commencer - essayer des trucs et voir ce que ça fait.

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 en fait faire des trucs dans votre travail quotidien. Ni git ni SVN ne sont des choses que vous pouvez simplement aller en classe et que vous savez tout. Vous devez utiliser les pour résoudre vos problèmes afin de vous familiariser avec eux et quelles fonctionnalités sont bien adaptées à quels problèmes.

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 à l'encontre d'une des choses que vous leur avez enseignées: toujours "Commit & Push". Je crois que vous devriez cesser de leur dire de faire cela et leur dire de commencer à faire le contraire. Git a fondamentalement 5 "endroits" où vos changements peuvent être:

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

Au lieu de les encourager à tirer et à pousser tout en une seule étape, encouragez-les à tirer parti de ces 5 endroits différents. Encouragez-les à:

• Récupérez les modifications avant de valider quoi que ce soit.

• Prenez une décision comment gérer les modifications récupérées. Les options sont:

  • Validez leurs modifications locales, puis rebasez-les en plus des modifications extraites.
  • Validez leurs modifications locales, puis effectuez une fusion avec les modifications extraites.

  • Stockez leurs modifications, fusionnez, puis décompressez et résolvez tous les conflits.

    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 fetch et une fusion. Ce n'est pas comme eux; il c'est eux. (Qui passe --rebase les modifications passent de fetch + merge à fetch + rebase.)

• Mettez en scène leurs modifications, puis passez-les en revue.
• Validez leurs modifications par étapes, puis passez en revue la validation.
• Poussez séparément.

Cela les encouragera à vérifier leur travail - avant il est rendu public pour tout le monde, ce qui signifie qu'ils rattraperont leurs erreurs plus tôt. Ils verront le commit et penseront: "Attendez, ce n'est pas ce que je voulais", et contrairement à SVN, ils peuvent y retourner et réessayer avant de pousser.

Une fois qu'ils se sont habitués à l'idée de comprendre où leurs modifications sont, ils peuvent alors commencer à décider quand ignorer les étapes et combiner certaines opérations (quand tirer parce que vous savez déjà que vous voulez aller chercher + fusionner ou quand cliquer sur cette option Commit & Push).

C'est en fait l'un des énormes avantages de git sur SVN, et git est conçu avec ce modèle d'utilisation à l'esprit. SVN, en revanche, suppose un référentiel central, il n'est donc pas surprenant que l'outillage pour git ne soit pas aussi optimisé pour le même flux de travail. Dans SVN, si votre commit est erroné, votre seul véritable recours est un nouveau commit pour annuler l'erreur.

Faire cela mènera naturellement à la prochaine stratégie:

Encouragez-les à utiliser les branches local

Les succursales locales atténuent en fait la plupart des problèmes liés au travail sur des fichiers partagés. Je peux faire tous les changements que je veux dans ma propre branche, et cela n'affectera jamais personne puisque je ne les pousse pas. Ensuite, le moment venu, je peux utiliser toutes les mêmes stratégies de fusion et de rebase, mais plus facilement:

• Je peux rebaser ma branche locale, ce qui rend sa fusion en maître triviale.
• Je pourrais utiliser une fusion simple (créer un nouveau commit) dans master pour y apporter les modifications de ma branche locale.
• Je peux squash fusionner toute ma branche locale en un seul commit sur master si je pense que ma branche est trop compliquée à sauver.

L'utilisation de succursales locales est également un bon début pour trouver une stratégie de branchement systématique. Il aide vos utilisateurs à mieux comprendre leurs propres besoins de branchement, vous pouvez donc choisir une stratégie basée sur les besoins et le niveau de compréhension/compétence actuel de l'équipe et ne pas simplement déposer dans Gitflow car tout le monde en a entendu parler.

Sommaire

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

• Éliminez la peur en encourageant l'expérimentation en toute sécurité.
• Aidez-les à comprendre en quoi git est différent afin qu'ils puissent voir comment 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 progressivement à adopter une meilleure utilisation de Git, jusqu'à ce que vous puissiez commencer à implémenter un ensemble de normes.

Caractéristiques spécifiques

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

Rebase

Vous avez mentionné le rebase et que vous ne comprenez pas vraiment dans votre question. Voici donc mon conseil: essayez ce que je viens de décrire. Apportez des modifications localement pendant que quelqu'un d'autre pousse certaines modifications. Validez vos modifications localement. Compressez le répertoire de votre référentiel comme sauvegarde. Récupérez les modifications de l'autre personne. Essayez maintenant d'exécuter une commande de rebase et voyez ce qui arrive à vos commits! Vous pouvez lire des articles de blog sans fin ou recevoir une formation sur le rebase et comment vous devez ou ne pas l'utiliser, mais rien de tout cela ne remplace le voir en action. Alors essayez ça.

merge.ff=only

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

git config --global merge.ff only

"ff" signifie "avance rapide". Une fusion rapide se produit lorsque git n'a pas besoin de combiner les modifications de différentes validations. Il déplace simplement le pointeur de la branche vers un nouveau commit le long d'une ligne droite dans le graphique.

En pratique, cela empêche Git d'essayer automatiquement de créer des validations de fusion. Donc, si je valide quelque chose localement et que je tire les modifications de quelqu'un d'autre, au lieu d'essayer de créer un commit de fusion (et de forcer potentiellement l'utilisateur à gérer les conflits), la fusion échouera. En effet, git n'aura effectué qu'un fetch. Lorsque vous n'avez aucun commit local, la fusion se déroule normalement.

Les utilisateurs ont ainsi la possibilité de passer en revue les différents validations avant de tenter de les fusionner et les obligent à prendre une décision sur la meilleure façon de gérer leur combinaison. Je peux rebaser, poursuivre la fusion (en utilisant git merge --no-ff pour contourner la configuration), ou je peux même simplement suspendre la fusion de mes modifications pour l'instant 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 aura mieux géré les fusions.

Answer 8

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 faire des erreurs, montrez-leur comment les réparer. Votre vitesse souffrira pendant un certain temps, et les gens perdront du travail, et tout le monde sera un peu capricieux, 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 estiment 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 de git au nom de la simplicité, cela empêche également vos collègues de comprendre les concepts de base de git tels que la validation en deux phases.

Nous avons pris la décision (plutôt drastique) de forcer les développeurs à utiliser la ligne de commande (git bash ou posh-git ) pendant une semaine, et cela a fait des merveilles pour comprendre comment git fonctionne réellement et comment il fonctionne. diffère de SVN. Cela peut sembler drastique, mais je vous suggère de l'essayer simplement parce qu'il crée cette compréhension du modèle git - et une fois qu'ils ont cela, vos collègues peuvent commencer à utiliser les façades de l'interface graphique sur git qu'ils aiment.

Remarque finale: certains de vos collègues verront comment git fonctionne presque immédiatement, et certains ne le feront jamais. Pour ce dernier groupe, il vous suffit d'enseigner les incantations mystiques pour faire passer leur code de leur machine locale au serveur afin que tout le monde puisse le voir.

Answer 9

Eh bien, récemment, j'ai adapté le flux de travail suivant pour ne jamais f * ck la branche principale:

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

Appelons la branche principale "master" et ma propre branche "my_master".

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

Currenly sur ma branche, vient de terminer le codage

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

Retournez à la branche principale

git checkout master

Tirez s'il n'est pas à jour

git pull

Retourne dans 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

Testez tout à nouveau

Lorsque tout est fusionné et fixé sur ma propre branche, poussez-le

git Push

Retournez à la branche principale

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 la fusion précédente

Push master

git Push

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

Answer 10

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 master. Ce n'est pas si mal; et une équipe habituée à TFS ou SVN trouvera cela le plus naturel.

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

1. faire git stash && git pull --rebase && git stash pop tous les matins
2. s'engager tôt et souvent (pas besoin de pousser immédiatement; nous pouvons au moins commencer à profiter de cet avantage de git plus tôt)

3. pour pousser faites 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.