Correction d'une erreur GitLab: "vous n'êtes pas autorisé à envoyer du code aux branches protégées sur ce projet"?

327

J'ai un problème lorsque je pousse mes codes vers git alors que j'ai un accès développeur dans mon projet, mais tout va bien quand j'ai un accès maître. D'où vient le problème? Et comment y remédier?

Message d'erreur:

erreur: vous n'êtes pas autorisé à envoyer du code aux branches protégées sur ce projet.
...
erreur: impossible de pousser certaines références vers ...

— Fachrein Rachim Muhamad
source

La réponse de Hcorg est une bonne solution. Il y a un autre problème avec ça. Si le projet vient de créer et qu'il n'a pas encore de branche. Si vous cliquez sur "Branches protégées", il sera redirigé vers la page d'accueil du projet. Créer une branche fonctionnera.

— pdwjun

Voir également stackoverflow.com/a/61964599/6309 , avec GitLab 13.0 (mai 2020), où vous pouvez activer la protection de branche par défaut au niveau du groupe.

— VonC

506

il n'y a pas de problème - tout fonctionne comme prévu.

Dans GitLab, certaines branches peuvent être protégées. Par défaut, seuls les utilisateurs responsables / propriétaires peuvent s'engager dans des branches protégées (voir les documents d'autorisation ).masterLa branche est protégée par défaut - elle oblige les développeurs à émettre des demandes de fusion à valider par les responsables de projet avant de les intégrer dans le code principal.

Vous pouvez activer et désactiver la protection sur les branches sélectionnées dans les paramètres du projet (où cela dépend exactement de la version de GitLab - voir les instructions ci-dessous).

Sur la même page de paramètres, vous pouvez également autoriser les développeurs à pénétrer dans les branches protégées. Lorsque ce paramètre est activé, la protection sera limitée au rejet d'opérations nécessitantgit push --force activé (rebase, etc.)

Depuis GitLab 9.3

Aller au projet: "Paramètres" → "Référentiel" → "Développer" sur "Branches protégées"

Je ne sais pas vraiment quand ce changement a été introduit, les captures d'écran sont de la version 10.3.

Vous pouvez maintenant sélectionner qui est autorisé à fusionner ou à pousser dans les branches sélectionnées (par exemple: vous pouvez désactiver les push masterà tout, forçant toutes les modifications à la branche à effectuer via les demandes de fusion). Ou vous pouvez cliquer sur "Déprotéger" pour supprimer complètement la protection de la branche.

Depuis GitLab 9.0

Similaire à GitLab 9.3, mais pas besoin de cliquer sur "Développer" - tout est déjà développé:

Allez dans le projet: "Paramètres" → "Référentiel" → faites défiler jusqu'à "Branches protégées".

Pre GitLab 9.0

Projet: "Paramètres" → "Branches protégées" (si vous êtes au moins "Maître" d'un projet donné).

Cliquez ensuite sur "Déprotéger" ou "Les développeurs peuvent pousser":

— Hcorg
source

N'oubliez pas que certaines autorisations peuvent être nécessaires. Comme indiqué dans docs.gitlab.com/ee/user/project/protected_branches.html , au moins «Niveau d'autorisation principal». Dans mon cas, appuyer sur une molette de paramètres affiche uniquement l'option «Quitter le projet».

— CoolMind

1

Pour une raison quelconque, j'ai soudainement dû m'ajouter en tant qu'utilisateur maître pour mon propre projet.

— jgillich

3

J'ai eu ce problème parce que je n'étais PAS membre de mon propre projet et j'ai déjà poussé ce projet ... Pour le changer, dans le projet de tournée, cliquez sur l'engrenage, Membres, recherchez votre utilisateur, donnez-lui un rôle et cliquez sur "Ajouter utilisateurs à projeter ".

— Loenix

Étrange, moi aussi, j'ai dû m'inclure sur un projet personnel sur gitlab.com

— Thomas Decaux

1

C'est bien si vous êtes le seul mainteneur ou développeur, vous pouvez donc modifier le paramètre et jouer avec. Mais s'il y a une équipe travaillant sur le repo, alors ce n'est pas une bonne pratique de changer la protection du repo.

— Mnemo

27

pour GitLab Enterprise Edition 9.3.0

Par défaut, la branche principale est protégée donc sans protection :)

1-Sélectionnez votre "projet"

2-Sélectionnez "Référentiel"

3-Sélectionnez "succursales"

4-Sélectionnez "Paramètres du projet"

5-In "Branches protégées" cliquez pour "développer"

6-et après clic dans le bouton "déprotéger"

— krekto
source

Je n'avais pas de "branches" car je n'ai pas encore créé de fichier sur ce référentiel. J'ai créé Readme.md et des branches sont apparues.

— Ikrom

1

J'ai rencontré cette erreur sur "une branche vide" sur mon serveur gitlab local. Certaines personnes ont mentionné que "vous ne pouvez pas pousser pour la première fois sur une branche vide". J'ai essayé de créer un simple fichier README sur le gitlab via mon navigateur. Ensuite, tout s'est arrangé de façon incroyable et le problème a été réglé !! Je mentionne que j'étais le maître et que la branche n'était pas protégée.

— Vahid F
source

C'est étrange pour moi et je considère ce problème comme un bug gitlab. Il est inacceptable pour moi de n'avoir aucune permission de pousser dans un dépôt vide. J'espère que les gars ont une réponse.

— Vahid F

1

Essayez d'apporter des modifications selon le lien

https://docs.gitlab.com/ee/user/project/protected_branches.html

rendre le projet non protégé pour le responsable ou le développeur pour que vous vous engagiez

— Barath Ravichander
source

1

Solution simple pour ce problème d'avoir une discussion rapide avec une personne qui a un rôle de propriétaire dans gitlab. Il peut pousser un fichier READ.md ou similaire pour commencer. Plus tard, tout fonctionnera comme précédemment.

— kris
source

Si possible, essayez d'obtenir le rôle de propriétaire dans le référentiel. Une fois que vous avez le rôle de propriétaire, vous pouvez vous engager directement sur master. C'est ennuyeux mais préventif de ne pas créer de nouveaux projets indésirables.Il n'y a pas de piratage jusqu'à ce que le propriétaire du repo pousse le premier fichier ou que vous ayez le rôle de propriétaire. J'espère que cela t'aides.

— kris

1

J'étais sous Windows lorsque ce problème est apparu.

L'erreur est étrange car elle se produit avant que je puisse entrer mon nom d'utilisateur et mon mot de passe. Et s'il y avait un cache ou quelque chose comme ça? Je l'ai creusé en ligne et j'ai trouvé cette réponse sur le forum de support de gitlab :

J'ouvre "Panneau de configuration => Comptes d'utilisateurs => Gérez vos informations d'identification => Informations d' identification Windows" J'en ai trouvé deux pour https: //@github.com et l'une était le mauvais utilisateur. Je l'ai supprimé et lors du prochain "git push", j'ai été invité à nouveau et j'ai fourni les informations d'identification correctes et cela a fonctionné! Quelques autres notes - cela aurait pu arriver avec n'importe quelle télécommande git.

Dans les informations d'identification Windows, j'ai trouvé deux entrées GitLab pour un ancien compte. J'enlève les deux et maintenant ça marche!

Le panel:

— aloisdg passe à codidact.com
source

@YanickSenn Vous êtes les bienvenus. J'ai perdu beaucoup de temps sur celui-ci. Heureux que ça aide.

— aloisdg passe à codidact.com le

1

Ceci est considéré comme des fonctionnalités de Gitlab.

Maintainer / Ownerl'accès n'est jamais en mesure de forcer à nouveau la poussée pour la branche par défaut et protégée, comme indiqué dans cette documentation

— mochadwi
source

1

En fait, ce n'est pas malheureux du tout. C'est définitivement une bonne chose. C'est une couche de protection supplémentaire.

— Chiramisu

0

J'ai rencontré le même problème sur mon référentiel. Je suis le maître du référentiel, mais j'ai eu une telle erreur.

J'ai non protégé mon projet, puis je me suis à nouveau protégé, et l'erreur a disparu.

Nous avions mis à jour la version de gitlab entre mon push précédent et celui problématique. Je suppose que cette mise à niveau a créé le bug.

— jean pierre huart
source

0

Les solutions ci-dessus expliquent clairement quel est le problème; lorsque vous n'avez pas de contrôle sur le référentiel, la meilleure façon de soumettre votre code est de créer une fourchette du référentiel d'origine et de soumettre votre code à ce nouveau référentiel afin que plus tard vous puissiez le pousser vers celui d'origine.

— gogasca
source