GitLab-Fehler behoben: "Sie dürfen in diesem Projekt keinen Code an geschützte Zweige senden"?

325

Ich habe ein Problem, wenn ich meine Codes auf Git drücke, während ich Entwicklerzugriff in meinem Projekt habe, aber alles ist in Ordnung, wenn ich Masterzugriff habe. Woher kommt das Problem? Und wie kann man das beheben?

Fehlermeldung:

Fehler: Sie dürfen in diesem Projekt keinen Code an geschützte Zweige senden.
...
Fehler: Einige Refs konnten nicht an ...

— Fachrein Rachim Muhamad
quelle

Die Antwort von Hcorg ist eine gute Lösung. Es gibt ein anderes Problem damit. Wenn das Projekt gerade erstellt wurde und noch keinen Zweig hat. Wenn Sie auf "Geschützte Zweige" klicken, wird zur Projekthomepage weitergeleitet. Das Erstellen eines Zweigs funktioniert.

— pdwjun

Siehe auch stackoverflow.com/a/61964599/6309 mit GitLab 13.0 (Mai 2020), wo Sie den Standardzweigschutz auf Gruppenebene aktivieren können.

— VonC

505

Es gibt kein Problem - alles funktioniert wie erwartet.

In GitLab können einige Zweige geschützt werden. Standardmäßig können nur Benutzer von Maintainern / Eigentümern geschützte Zweige festlegen (siehe Berechtigungsdokumente ). masterDer Zweig ist standardmäßig geschützt. Entwickler müssen Zusammenführungsanforderungen ausgeben, die von den Projektbetreuern validiert werden müssen, bevor sie in den Hauptcode integriert werden.

Sie können den Schutz für ausgewählte Zweige in den Projekteinstellungen aktivieren und deaktivieren (wobei dies genau von der GitLab-Version abhängt - siehe Anweisungen unten).

Auf derselben Einstellungsseite können Sie Entwicklern auch erlauben, in die geschützten Zweige zu pushen. git push --forceWenn diese Einstellung aktiviert ist , beschränkt sich der Schutz auf das Ablehnen von Vorgängen, die erforderlich sind (Rebase usw.).

Seit GitLab 9.3

Gehen Sie zum Projekt: "Einstellungen" → "Repository" → "Erweitern" auf "Geschützte Zweige"

Ich bin mir nicht sicher, wann diese Änderung eingeführt wurde. Die Screenshots stammen aus der Version 10.3.

Jetzt können Sie auswählen, wer in ausgewählten Zweigen zusammengeführt oder verschoben werden darf (zum Beispiel: Sie können Push- masterto-Vorgänge deaktivieren, um alle Änderungen am Zweig über Zusammenführungsanforderungen zu erzwingen). Oder Sie können auf "Schutz aufheben" klicken, um den Schutz vollständig vom Zweig zu entfernen.

Seit GitLab 9.0

Ähnlich wie bei GitLab 9.3, jedoch ohne auf "Erweitern" klicken zu müssen - alles ist bereits erweitert:

Gehen Sie zum Projekt: "Einstellungen" → "Repository" → scrollen Sie nach unten zu "Geschützte Zweige".

Vor GitLab 9.0

Projekt: "Einstellungen" → "Geschützte Zweige" (wenn Sie mindestens "Master" eines bestimmten Projekts sind).

Klicken Sie dann auf "Unprotect" oder "Developers can push":

— Hcorg
quelle

Vergessen Sie nicht, dass möglicherweise einige Berechtigungen erforderlich sind. Wie in docs.gitlab.com/ee/user/project/protected_branches.html angegeben , mindestens "Master-Berechtigungsstufe". In meinem Fall wird durch Drücken eines Einstellungsrads nur die Option "Projekt verlassen" angezeigt.

— CoolMind

1

Aus irgendeinem Grund musste ich mich plötzlich als Master-User für mein eigenes Projekt hinzufügen.

— jgillich

3

Ich habe dieses Problem erhalten, weil ich NICHT Mitglied meines EIGENEN Projekts war und dieses Projekt bereits vorangetrieben habe. Um es zu ändern, klicken Sie im Tour-Projekt auf die Ausrüstung, Mitglieder, suchen Sie Ihren Benutzer, geben Sie ihm eine Rolle und klicken Sie auf "Hinzufügen" Benutzer zu projizieren ".

— Loenix

Seltsam, ich auch, musste mich in ein persönliches Projekt auf gitlab.com einbeziehen

— Thomas Decaux

1

Es ist gut, wenn Sie der einzige Betreuer oder Entwickler sind, damit Sie die Einstellung ändern und damit herumspielen können. Wenn jedoch ein Team am Repo arbeitet, ist es keine gute Praxis, den Schutz des Repos zu ändern.

— Mnemo

26

für die GitLab Enterprise Edition 9.3.0

Standardmäßig ist der Hauptzweig geschützt, also nicht geschützt :)

1-Wählen Sie Ihr "Projekt"

2-Wählen Sie "Repository"

3-Wählen Sie "Zweige"

4-Wählen Sie "Projekteinstellungen"

5-In "Geschützte Zweige" klicken Sie auf "Erweitern"

6-und nach dem Klicken in "Unprotect" Schaltfläche

— krekto
quelle

Ich hatte keine "Zweige", da ich noch keine Datei in diesem Repository erstellt habe. Ich habe Readme.md erstellt und Zweige erschienen.

— Ikrom

1

Ich habe diesen Fehler bei "einem leeren Zweig" auf meinem lokalen Gitlab-Server festgestellt. Einige Leute erwähnten, dass "man nicht zum ersten Mal auf einen leeren Ast schieben kann". Ich habe versucht, über meinen Browser eine einfache README-Datei auf dem Gitlab zu erstellen. Dann wurde alles erstaunlich behoben und das Problem behoben !! Ich erwähne, dass ich der Meister war und der Zweig nicht geschützt war.

— Vahid F.
quelle

Das ist seltsam für mich und ich betrachte dieses Problem als einen Gitlab-Fehler. Es ist inakzeptabel, dass ich keine Erlaubnis habe, in ein leeres Repo zu gehen. Ich hoffe, Git-Jungs haben eine Antwort darauf.

— Vahid F

1

Versuchen Sie, Änderungen gemäß Link vorzunehmen

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

Machen Sie das Projekt für den Betreuer oder Entwickler ungeschützt, damit Sie es festschreiben können

— Barath Ravichander
quelle

1

Einfache Lösung für dieses Problem, um schnell mit einer Person zu chatten, die eine Eigentümerrolle in gitlab hat. Er kann eine Datei READ.md oder ähnliches pushen, um damit zu beginnen. Später wird alles wie früher funktionieren.

— kris
quelle

Versuchen Sie nach Möglichkeit, die Eigentümerrolle im Repository abzurufen. Sobald Sie eine Eigentümerrolle haben, können Sie sich direkt zum Master verpflichten. Es ist ärgerlich, aber vorbeugend, keine unerwünschten neuen Projekte zu erstellen. Es gibt keinen Hack, bis der Eigentümer des Repos die erste Datei pusht oder Sie die Eigentümerrolle haben. Hoffe das hilft.

— Kris

1

Ich war unter Windows, als dieses Problem auftrat.

Der Fehler ist seltsam, da er auftritt, bevor ich meinen Benutzernamen und mein Passwort eingeben konnte. Was wäre, wenn es einen Cache oder ähnliches gäbe? Ich habe es online gefunden und diese Antwort im Support-Forum von gitlab gefunden :

Ich öffne "Systemsteuerung => Benutzerkonten => Anmeldeinformationen verwalten => Windows-Anmeldeinformationen". Ich habe zwei für https: //@github.com gefunden und einer war der falsche Benutzer. Ich habe es gelöscht und beim nächsten "Git Push" wurde ich erneut aufgefordert und habe die richtigen Anmeldeinformationen angegeben, und es hat funktioniert! Einige andere Hinweise - dies könnte mit jeder Git-Fernbedienung geschehen sein.

In den Windows-Anmeldeinformationen habe ich zwei GitLab-Einträge für ein altes Konto gefunden. Ich entferne beide und jetzt funktioniert es!

Das Panel:

— aloisdg wechselt zu codidact.com
quelle

Vielen Dank - ich dachte, ich hätte den Verstand verloren ...

— Yanick Senn

@YanickSenn Gern geschehen. Ich habe viel Zeit verloren. Ich bin froh, dass es hilft.

— Aloisdg wechselt zu codidact.com

1

Dies wird in Gitlab als Feature betrachtet.

Maintainer / OwnerDer Zugriff kann nie wieder einen Push für den standardmäßigen und geschützten Zweig erzwingen, wie in diesem Dokument angegeben

— Mochadwi
quelle

1

Eigentlich ist das überhaupt nicht unglücklich. Es ist definitiv eine gute Sache. Es ist eine zusätzliche Schutzschicht.

— Chiramisu

0

Ich hatte das gleiche Problem in meinem Repository. Ich bin der Meister des Repositorys, aber ich hatte einen solchen Fehler.

Ich habe mein Projekt ungeschützt und dann wieder geschützt, und der Fehler ist verschwunden.

Wir hatten die Gitlab-Version zwischen meinem vorherigen und dem problematischen Push aktualisiert. Ich nehme an, dass dieses Upgrade den Fehler verursacht hat.

— Jean Pierre Huart
quelle

0

Die obigen Lösungen erklären klar, wo das Problem liegt. Wenn Sie keine Kontrolle über das Repo haben, können Sie Ihren Code am besten senden, indem Sie eine Abzweigung des ursprünglichen Repos erstellen und Ihren Code an dieses neue Repo senden, damit Sie ihn später an das ursprüngliche Repo senden können.

— Gogasca
quelle