Est-ce que quelqu'un connaît-il un moyen d'autoriser plusieurs utilisateurs à travailler à partir du même référentiel sur Github ou SpringLoops ?? La façon dont nous avons essayé cela partageait la même clé / paire avec les 4 machines utilisées, mais cela ne fonctionne pas. Un compte fonctionne bien, mais nous ne savons donc pas comment coordonner réellement l'ensemble de l'aspect push / pull / fusion. Ce que nous voulions éviter, c'est avoir plusieurs branches.
L'appel des SpringLoops était que chaque fois que quelqu'un effectue une modification, ce changement serait automatiquement FTP'd au serveur de dev. Ensuite, une seule personne est chargée de déplacer Dev pour la production.
4 Réponses :
Git a été conçu pour être utilisé avec un référentiel pour chaque développeur. Créez un compte pour chaque personne, puis désignez un en tant que mainteneur de la branche principale. Tout le monde voudra chercher le maître, et ils peuvent travailler sur tout ce qu'ils veulent seuls. Une fois qu'ils ont fini quelque chose, ils vous enverront une demande de traction et vous pouvez tirer leurs modifications dans la branche principale. Ensuite, tout le monde peut tirer du maître aussi souvent qu'ils aiment (une fois par jour, deux fois par jour, etc.).
La gestion de plusieurs branches peut sembler difficile, mais tant que vous communiquez efficacement, cela ne devrait pas être un problème. Une fois qu'un développeur termine une fonctionnalité, il est important qu'ils vous envoient une demande de traction et ils ne sont pas simplement assis sur les engagements et personne ne le sait à leur sujet.
Une bonne politique possible pour les développeurs à suivre avant d'envoyer une demande de fusion est de les faire tirer de la maîtrise et de s'assurer qu'il n'y a pas de conflit.
Si vous voulez vraiment utiliser un compte, vous n'avez pas à partager la même clé. GitHub vous permet de télécharger autant de clés que vous le souhaitez. Cependant, si vous voulez quelque chose qui fonctionne comme SVN, vous devez utiliser svn car Git n'est pas conçu pour suivre le même flux de travail que SVN.
Peut-être que github est conçu pour être un repo par développeur, mais git elle-même est tout à fait heureux de laisser n'importe qui avec des autorisations pousser à un seul repo. Je ne vois pas pourquoi vous dites que c'est un flux de travail SVN - il est assez courant d'avoir un référentiel central canonique que plusieurs personnes de confiance peuvent accéder.
La question principale lorsque cela fait, c'est que nous ne savons pas comment cela est mis en place. Par exemple, je suis assis ici avec mon ordinateur portable et mon ordinateur de bureau et je veux me développer sur les deux et poussez tirer du repo central. Chaque machine a-t-elle besoin d'un compte différent et d'un ensemble de clés?
Un compte GITUB est à utiliser par personne et non par machine, donc non, vous n'avez pas besoin d'un compte différent de votre ordinateur portable et de votre ordinateur de bureau. Vous pouvez soit utiliser la même clé sur plusieurs touches de votre compte Github. Si vous essayez d'utiliser le même compte pour plusieurs personnes, même si vous risquez de vous désordonner si vous n'avez pas de flux de travail solide. En particulier, si plusieurs personnes tentent de commettre les mêmes branches dans les mêmes temps, votre histoire pourrait être jonchée de fusion inutile.
Un référentiel par développeur est l'un des flux de travail valides pour lesquels GIT est conçu. Un objectif similaire peut être obtenu en utilisant un seul repo avec une branche individuelle par histoire / billet. (Je me rends compte que l'OP a voulu éviter de multiples branches, mais pourquoi?) Le flux de travail de la ramification facilite les choses lorsque plusieurs Devs doivent faire fonctionner sur un seul billet, car vous pouvez éviter les demandes d'extraction intermédiaires du repo d'un devenu à un autre pour WIP. Toujours repo par devement domine la plupart des OSS. Les deux sont des options valides, mais pour l'amour de Dieu, obtenez votre DevS leurs propres comptes Github.
Git est extrêmement flexible et vous pouvez le mettre de différentes manières différentes. Cependant, les gens ont des opinions très fortes sur les bonnes conventions pour adhérer à l'utilisation de Git. Cependant, la configuration nécessite une certaine cohétermination, mais certaines manières peuvent nécessiter davantage ou moins. Le terme général à rechercher est "Git Workflow" pour trouver des discussions à ce sujet.
Notez que chaque caisse GIT est un référentiel, donc dans un sens trivial, chaque développeur doit en effet avoir son propre référentiel. Il est tout à fait possible de disposer d'un référentiel «partagé» sur GitHub, avec plusieurs clés ou une touche. Cela nécessite plus de coopération à l'avance - vous devez vous mettre d'accord sur l'endroit où le développement est dirigé. Avec plusieurs référentiels «public», vous pouvez retarder cela. Les gens peuvent se pencher sur le travail de chacun et discuter si cela devrait être fusionné dans un référentiel béni.
(vous pouvez également le faire avec plusieurs branches sur un référentiel et vous pouvez également faire des discussions via l'envoi d'ensembles de patchs, il ne s'agit que de ce qui est plus facile.)
La réponse est la suivante:
chgrp -R <whatever group> gitrepo chmod -R g+swX gitrepo
Il y a deux flux de travail principaux. Les deux supposent que chaque développeur a mis en place un compte GITUB qui est libre et raisonnable:
Les collaborateurs sont préférables si un groupe de vous créez ou maintient un produit logiciel. Il y a un référentiel pour le projet sur GitHub et chaque développeur disposera d'un référentiel local pour son travail de développement.
Le forking est utile s'il existe d'autres équipes ou développeurs utilisant leur propre version de votre produit. Cela leur donne une manière (demandes de traction) pour remettre leurs modifications pour améliorer votre produit. Chaque fourche est généralement considérée comme une variante viable distincte de votre projet.
Le forking est également utile dans un environnement open source pendant que vous «viennent faire confiance à» un collaborateur potentiel. Si vous vous trouvez régulièrement acceptant leurs demandes de traction, vous pouvez «les promouvoir» d'être un collaborateur.
Les branches sont importantes et très utiles. C'est difficile à faire sans eux sur le repo à distance si plus d'un développeur doit travailler ensemble sur une caractéristique expérimentale ou une extension importante de votre projet.