Collaboration GitHub à l'aide du modèle de référentiel partagé
Quelqu'un peut-il me fournir la feuille de triche pour la collaboration GitHub pour une équipe de deux qui veulent un accès/des droits égaux au repo. Je suis confus quant à la nécessité d'utiliser forking qui semble avoir du sens pour un grand projet open source avec des développeurs dispersés mais seeems comme overkill quand moi et mon partenaire sommes assis 10 pieds l'un de l'autre.
Merci,
Doug
2 réponses
Si vous avez une petite équipe et que vous voulez que tout le monde ait accès au repo, vous pouvez simplement leur accorder l'autorisation de collaborateur dans les paramètres d'administration du repo. Forking n'est pas nécessaire si votre scénario ne l'exige pas. (Bien que le forking puisse être utile, vous avez également partiellement raison: si vous avez une petite équipe et connaissez tous les autres membres de l'équipe et que cela ne vous dérange pas de leur donner un accès en lecture/écriture, il n'y a pas besoin de fork.)
La différence entre le modèle de fourche et de traction et le modèle de référentiel partagé pourrait s'expliquer par Github.com: (https://help.github.com/articles/about-collaborative-development-models/)
À propos des modèles de développement collaboratif La façon dont vous utilisez les requêtes pull dépend du type de modèle de développement que vous utilisez dans votre projet.
Il existe deux principaux types de modèles de développement avec lesquels vous utiliseriez des requêtes pull. Dans la fourche et tirez modèle, n'importe qui peut fork un référentiel existant et pousser les modifications à leur fork personnel sans avoir besoin d'accéder au référentiel source. Les modifications peuvent être extraites dans le référentiel source par le responsable du projet. Lorsque vous ouvrez une requête pull proposant des modifications de la branche de votre fork vers une branche du référentiel source (amont), vous pouvez autoriser toute personne ayant un accès push au référentiel amont à apporter des modifications à votre requête pull. Ce modèle est populaire auprès des projets open source car il réduit la quantité de friction pour les nouveaux contributeurs et permet aux gens de travailler indépendamment sans coordination initiale.