Utiliser git correctement dans une petite équipe

14

Quelle serait la façon la plus simple d'utiliser correctement git dans une petite équipe d'environ 5 développeurs, avec un serveur exécutant l'application en direct?

version-control  git 
— ONOZ
source
5
Je remettrais en question l'utilisation de git dans ce cas. Il n'y a aucun avantage à utiliser le contrôle de source décentralisé, lorsque vous avez toutes les personnes dans une pièce avec un serveur dédié. Et il y a encore des frais généraux de tirer / pousser sur les commits.
— Euphoric
10
@Euphoric dépend de votre outillage et de votre flux de travail.
3
@ONOZ veuillez décrire plus en détail votre façon de travailler actuelle.
22
@ Euphoric - Quelle attitude incroyablement étroite. Pour la facilité de branchement et de fusion seul gitou hgbat la plupart des VCS centralisés. Je peux comprendre que les gens soient ennuyés par les gens qui disent constamment à quel point les DVCS sont excellents, mais s'enfoncer la tête dans le sable et refuser de reconnaître que vous pouvez développer des flux de travail différents et peut-être plus efficaces avec DVCS que sans un est tout aussi mauvais.
— Mark Booth
8
@Euphoric, l'utilisation de Git ne signifie pas que votre contrôle de code source est "décentralisé". Je travaille dans une petite équipe, et nous utilisons Git, et nous avons toujours un référentiel central. C'est à cela que vous insistez. L'utilisation d'un DVCS ne signifie généralement pas que chaque personne tire de toute autre personne sans point central.
— Kyralessa

Réponses:

11

Je vous suggère de créer une branche:

  • production
  • Maître
  • local

La branche de production est une branche "live". L'application est-elle en cours d'utilisation?

Lorsqu'une mise à jour est nécessaire, un développeur peut tirer la branche principale dans la branche locale. Que, peut commencer à coder. À la fin, il suffit de tirer et de pousser de la branche locale du développeur vers le maître. Un chef de projet peut jeter un œil dans la branche master. Essaye-le. Et lorsqu'il est prêt, peut fusionner la production avec le maître. Et maintenant, vous aurez un nouveau logiciel.

— sensorario
source
Si vous êtes dans une situation de conseil ou d'entreprise, vous voudrez peut-être également avoir une succursale pour l'UAT.
— John MacIntyre
D'accord, j'utilise ce flux de travail.
— Cheung
Pourriez-vous expliquer pourquoi la différence entre une branche locale et une branche principale? Je peux voir pourquoi vous voudriez avoir une version de production fonctionnelle, mais lorsque vous tirez / poussez des modifications, elle fusionnera automatiquement même sans branche locale, n'est-ce pas?
— Luc
1
Étant donné que la branche locale peut être nommée comme nom de fonction XXX, vous avez donc la branche principale comme fusion de toutes les branches de fonctionnalité que vous souhaitez en production. Oui: car certaines fonctionnalités peuvent ne pas être incluses.
— sensorario
7

Commencez simplement et développez un workflow plus complexe au fur et à mesure de vos besoins.

Quoi que vous fassiez, ne laissez pas un modèle de branchement Git réussi être la première chose que les gens voient, cela ne fera que les confondre et les submerger. Regardez cela plus tard lorsque vous aurez plus d'expérience.

Je suggérerais que vous commenciez par un gitréférentiel central et que tout le monde, y compris votre production et vos versions de test, clone à partir de cela.

Dans votre référentiel git, créez une productionbranche et une testbranche.

Les développeurs doivent travailler dans leurs propres branches de fonctionnalités locales ou distantes jusqu'à ce qu'ils soient terminés et fusionnés master. À partir de là, ils peuvent être fusionnés dans la testbranche pour être déployés dans l'environnement de test et lorsqu'ils réussissent les tests, ils peuvent être fusionnés dans la productionbranche.

De cette façon, vous pouvez toujours voir ce qui est nouveau et non testé, ce qui est testé mais pas encore déployé en production et ce qui est réellement en production.

— Mark Booth
source
Opinion intéressante, je considérerais le modèle de branchement git comme un facteur de rupture pour git, d'un autre côté, il pourrait ne pas être aussi évident pour les utilisateurs non-git.
— wirrbel
@wirrbel Il n'y a pas des choses telles que le modèle de branchement git, vous pouvez mettre en œuvre quel que soit le modèle de branchement que vous désirez en utilisant gitpour l' adapter à votre flux de travail. Celui que je suggère ici est simple et sera probablement meilleur pour les gitutilisateurs inexpérimentés qu'un modèle de branchement Git réussi, mais AsGbm sera probablement meilleur pour les gitutilisateurs plus expérimentés , mais il ne convient pas à certaines équipes (personnes souhaitant maintenir une version multiple) par exemple). Comme je l'ai dit cependant, le problème avec AsGbm est qu'il peut sembler trop compliqué.
— Mark Booth
Je vois ce que tu veux dire. Juste pour moi, j'ai commencé avec AsGbm (ou plutôt l'adapté à mes besoins). C'était parfait car je pouvais voir comment git pouvait être utilisé différemment de svn
— wirrbel
0

Vous devez avoir un référentiel maître sur le serveur d'intégration et chaque développeur doit le cloner. Après cela, il suffit de tirer et de pousser. Développer de nouvelles fonctionnalités importantes dans une branche distincte. Pas de fusée ici. Sur le serveur en direct - vous devez également cloner le référentiel maître. Et c'est une bonne pratique d'avoir une branche comme "live" pour cela.

— Nikolay Fominyh
source
2
git archive est une autre option pour le déploiement sur le serveur en direct en supposant que vous ne voulez pas réellement éditer directement des choses sur le serveur en direct
— jk.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.