Comment structurez-vous votre workflow de référentiel Git?

Question

Nous avons visionné et regardé les vidéos sur la taille des équipes distribuées utilisant Git, mais qu'en est-il de ceux d'entre nous qui ne sont pas distribués et qui travaillent au bureau avec le reste de notre équipe? Comment devrions-nous structurer notre ou nos référentiels et notre flux de travail?

Pensez au bureau traditionnel qui utilisait Subversion ou CVS comme point d’autorité unique. Ces équipes pourraient certainement gérer chacune leur propre référentiel Git et se rapprocher si nécessaire, ce qui se transformerait rapidement en cauchemar dans de nombreuses situations. Ou bien, ils pourraient chacun gérer leur propre référentiel et se synchroniser avec un seul référentiel appelé "maître". pour l'équipe. Ou bien, il pourrait y avoir toute combinaison de flux de travail avec les possibilités qu’un DVCS ouvre.

Comment fonctionne votre équipe? Qu'avez-vous trouvé être un flux de travail utile?

Answer 1

J'aime la façon dont Yahoo! L’interface utilisateur (YUI) semble fonctionner. Je ne suis pas chez Yahoo, pas plus que dans cette équipe, mais leurs journaux de commit git en disent long sur leur processus.

L’équipe YUI gère un référentiel central où chaque membre de l’équipe dispose d’un accès de validation. Périodiquement après les validations dans ce référentiel (ce peut être après chaque poussée, mais je ne le pense pas), le système de construction se déclenche, reconstruit YUI et pousse une nouvelle validation étiquetée dans github, où la communauté peut créer le code et travailler dessus. .

Je suis en faveur du référentiel central qui représente le "fonctionnaire" statut du projet. Bien sûr, si je veux partager du code avec un collègue, je peux lui demander de me retirer une branche et nous pouvons collaborer de cette manière.

Le " maître " Le référentiel offre également d'autres avantages, tels que la facilité d'intégration continue, car les déclencheurs push / pull peuvent être configurés sur le référentiel «maître» pour déclencher les tests unitaires et construire le système. Cela garantit également que tout le monde sait où se trouve la version la plus récente du référentiel "de qualité connue", de sorte que si le projet doit être construit, publié ou testé, il peut être raisonnablement assuré que le référentiel "maître" est prêt à être utilisé. .

Git prend en charge presque tous les flux de travail auxquels vous pouvez penser, mais même au sein d'une petite équipe, vous ne voulez pas qu'il y ait une question sur l'emplacement du référentiel "officiel". Le cauchemar de maintenance qui pourrait en résulter, en particulier à l’approche d’un dégagement, serait désagréable.

Answer 2

jetez un coup d'œil au blog http://nvie.com/git-model et aux commentaires

Answer 3

Jetez un coup d'œil à une équipe github de flux de travail qui utilise:

http://scottchacon.com/2011/08/31/github- flow.html

Cela nécessite l’utilisation de github, mais c’est aussi simple et net.