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?

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. ;)

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.

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.

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.

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

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.

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.

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.

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.

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.

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.