Comment protéger "master" dans github?
J'ai quelques contributeurs dans mon projet github. Je veux autoriser un seul d'entre eux à "pousser" à maîtriser. Et ce gars n'est pas moi (le propriétaire du référentiel). Est-il possible de faire?
À l'époque, lorsque cette question a été publiée, GitHub ne vous permettait pas de spécifier des privilèges d'accès au niveau d'une branche. Vous ne pouvez le faire qu'au niveau du référentiel. Donc, ce que vous demandez n'était pas possible.
Si vous souhaitez contourner cette limitation, je vois personnellement deux options:
- vous pouvez utiliser une sorte de hooks de validation, etc. pour au moins informer quelqu'un que quelque chose de mal s'est produit
- Si vous avez vraiment besoin de ce contrôle serré, vous pouvez utiliser deux référentiels, l'un ne contenant que votre branche "master". Vous devrez alors vous assurer que seul votre "gars" a accès en écriture au référentiel maître
Je pense qu'il est plus facile de résoudre cela avec une organisation. Dans mon équipe, nous ne poussons jamais rien directement à maîtriser, mais créons toujours des demandes de tirage. Cela garantit qu'au moins quelqu'un jette un coup d'œil avant que le code ne soit fusionné et vous pouvez également définir une stratégie selon laquelle seul votre "gars" est autorisé à fusionner les demandes d'extraction.
Mise à jour
GitHub a maintenant annoncé qu'ils déploieront une nouvelle fonctionnalité appelée branches protégées. Cette fonctionnalité est présente dans d'autres distributions git comme Atlassian Stash depuis des années. Il vous permettra de protéger certaines branches des poussées. Cependant, il ne permet toujours pas une protection complète basée sur ACL des branches individuelles. Donc, vous voudrez peut-être vérifier cette fonctionnalité au cas où vous ne voudriez pas compter sur une solution organisationnelle comme indiqué ci-dessus.
Remarque: Branches protégées et vérifications d'état requises (3 septembre 2015) vous permettra de protéger une branche
- contre forcé poussé
- contre la suppression
- contre les modifications fusionnées jusqu'à ce que les vérifications d'état requises réussissent
Depuis mars 2016, comme commenté par Sander ci-dessous, vous avez Restrictions utilisateur et équipe
Parfois, il est préférable de laisser les fusions dans une branche protégée à un responsable de publication ou à une équipe de personnes responsables de la stabilité de cette branche particulière. Les organisations peuvent désormais spécifier les membres et les équipes qui peuvent pousser vers une branche protégée.
C'est exactement pour cela que la fourche a été conçue. Vous auriez le référentiel principal protégé et vous autoriseriez des autorisations de lecture sur ce référentiel pour tous les contributeurs. Ces contributeurs fourreraient le repo et pousseraient leurs modifications à leurs copies personnelles du repo principal. Lorsqu'ils sont prêts à introduire du code dans le référentiel principal, ils soumettent une demande d'extraction dans le référentiel principal. Dans ce cas, les propriétaires du projet principal pourraient répondre à la demande de retrait.