Git pousser la synchronisation entre les membres de l'équipe

Quelle est la manière «correcte» de s'assurer que les autres users ne poussent pas à repasser le repo distant alors que quelqu'un d'autre effectue une opération de fusion / rebasage qui prend du time et souhaite que le repo rest stable tout en le faisant? Existe-t-il un moyen élégant de verrouiller le repo en mode lecture seule jusqu'à ce qu'une personne finisse avec une longue opération ou exécute la suite de tests pour s'assurer que tout fonctionne bien?

Actuellement, nous utilisons une approche créative (lire: légèrement peu orthodoxe) à ce problème – nous avons un file spécial sur un référentiel SVN local distinct que chaque membre de l'équipe doit extraire manuellement (c'est-à-dire effectuer un ') avant de faire pousse à repo git à distance. Maintenant, cette approche (telle qu'elle est) fonctionne mais est sujette à des erreurs et à des erreurs mentales (quelqu'un, généralement un nouveau membre de l'équipe, pousse au milieu de la fusion / rebase de quelqu'un d'autre).

Il doit y avoir une façon plus élégante de le faire.

Maintenant, je ne suis pas un expert git en aucune façon (je suis juste un user régulier) mais écrire une command personnalisée pour faire le verrou ne devrait pas être trop onéreux. Mais cela ne résout pas le problème d' empêcher l' autre user de pousser à repo à distance, c'est-à-dire comment faire git repo conscient que quelque part là-bas, il y a un drapeau qui, s'il est levé, devrait empêcher l'user de repo.

Existe-t-il un moyen plus standard de résoudre ce problème, un model existant que les gens utilisent? Y a-t-il même un moyen de mettre tout le repo en mode lecture seule?

Je suis ouvert à toutes les suggestions mais je voudrais certainement éviter d'introduire de nouveaux inter-repositorys et / ou des personnes dédiées qui seraient les seules à avoir des prémisses à pousser vers la télécommand – nous voulons que tous les développeurs aient cette capacité mais juste pour éviter de marcher sur les orteils de l'autre.

Solutions Collecting From Web of "Git pousser la synchronisation entre les membres de l'équipe"

Il existe une façon standard de le faire. Utilisez git normalement et cela n'arrive jamais.

Git est un système de contrôle de version dissortingbué. Lorsque vous fetch un référentiel ( A ) dans le vôtre, vous obtenez une copy des twigs de ce référentiel dans le vôtre, nommée A/branch_name . Vous l'avez probablement déjà vu en faisant git merge origin/master par exemple. La modification de la twig sur le référentiel distant n'affecte pas votre copy locale avant la prochaine fetch , ce qui arrive chaque fois que vous décidez.

Qu'est-ce que cela signifie? Pensons aux actions suivantes:

  1. A twig a une branch .
  2. Vous récupérez A dans votre référentiel et fusionnez dans votre branch locale.
  3. Vous démarrez votre long process sur votre référentiel local .
  4. Pendant ce time, quelqu'un d'autre pousse à branch sur A
  5. Vous effectuez toujours votre long process sur votre référentiel local sans jamais connaître l'étape 4.
  6. Vous essayez de repousser votre fusion.

Donc, à ce stade, vous savez que tout fonctionne sur votre référentiel local. Cependant, lorsque vous essayez de pousser, vous ne pouvez pas. Quelques observations:

  • À l'étape 4, quiconque a poussé A fait les mêmes longs tests en parallèle avec vous, mais a terminé plus tôt. Donc il s'est assuré que tout avec une branch sur A est ok.
  • Si l'autre personne avait verrouillé A en lecture seule, vous ne le sauriez pas jusqu'à l'étape 6, puisque vous étiez en train de lire le référentiel. Donc, faire le repo en lecture seule ne changerait rien.

Maintenant, ce que cela signifie pour vous, c'est que vous devez répéter les étapes ci-dessus. Vous devez donc recommencer, merge nouveau et relancer vos longs tests. Mais c'est correct et c'est habituellement ce qui est fait, mais pas aussi mauvais que vous pourriez le penser.

Il y a deux possibilités:

  1. L'autre personne travaillait sur quelque chose que vous aviez travaillé sur vous-même (improbable).
  2. L'autre personne travaillait sur quelque chose de totalement indépendant (probable).

Dans le second cas, il n'y a pas de problème. La fusion se ferait sans problème et vous n'avez pas besoin de répéter les longs tests puisque les tests pour chaque sous-système sont séparés (ils sont, non?!). Peut-être que vous feriez les tests sur l'intégration complète.

Dans le second cas, il y aurait des conflits de fusion, ce qui signifie plus de travail pour les conflits de fusion et l'exécution de tests à nouveau. Mais ce conflit de fusion se manifesterait tôt ou tard, que vous ayez verrouillé le référentiel ou non. Cependant, si vous aviez verrouillé le référentiel, votre collègue aurait à gérer le conflit. En fin de count, vous ou lui devez le faire.