GitLab hatasını düzeltin: “bu projedeki korumalı şubelere kod göndermenize izin verilmiyor”?

327

Projemde geliştirici erişimine sahipken kodlarımı git'e ittiğimde bir sorunum var, ancak ana erişimim olduğunda her şey yolunda. Sorun nereden geliyor? Ve nasıl düzeltilir?

Hata mesajı:

hata: Bu projedeki korumalı dallara kod göndermenize izin verilmiyor.
...
hata: bazı referansları gönderemedi ...

— Fachrein Rachim Muhamad
kaynak

Hcorg'un cevabı iyi bir çözümdür. Bununla ilgili başka bir sorun var. Proje yeni oluşturduysa ve henüz bir dalı yoksa. "Korumalı dallar" ı tıklarsanız proje ana sayfasına yönlendirilir. Şube oluşturmaya çalışır.

— pdwjun

Grup düzeyinde varsayılan şube korumasını etkinleştirebileceğiniz GitLab 13.0 (Mayıs 2020) ile ayrıca stackoverflow.com/a/61964599/6309 adresine bakın .

— VonC

506

sorun yok - her şey beklendiği gibi çalışıyor.

GitLab'da bazı şubeler korunabilir. Varsayılan olarak yalnızca Maintainer / Owner kullanıcıları korumalı şubeleri taahhüt edebilir (bkz. İzinler belgeleri ). masterşube varsayılan olarak korunur - geliştiricileri, proje sahipleri tarafından ana koda entegre etmeden önce birleştirme isteklerini onaylamaya zorlar.

Proje Ayarlarında seçilen dallarda korumayı açıp kapatabilirsiniz (tam olarak GitLab sürümüne bağlıdır - aşağıdaki talimatlara bakın).

Aynı ayarlar sayfasında, geliştiricilerin korumalı dallara aktarmalarına da izin verebilirsiniz. Bu ayar açıkken, koruma gerektiren işlemlerin reddedilmesi git push --force( sınırlama vb.) İle sınırlı olacaktır .

GitLab 9.3'ten beri

Projeye gidin: "Ayarlar" → "Depo" → "Korumalı dallar" da "Genişlet"

Bu değişiklik ne zaman piyasaya sürüldüğünden emin değilim, ekran görüntüleri 10.3 sürümündedir.

Artık seçilen şubeleri kimlerin birleştirebileceğini veya içine sokabileceğini seçebilirsiniz (örneğin: itme işlemlerini tamamen kapatabilir master, şubedeki tüm değişiklikleri Birleştirme İstekleri aracılığıyla yapılmaya zorlayabilirsiniz). Ya da şubeden korumayı tamamen kaldırmak için "Korumayı kaldır" ı tıklayabilirsiniz.

GitLab 9.0'dan beri

GitLab 9.3'e benzer, ancak "Genişlet" i tıklamanız gerekmez - her şey zaten genişletilmiştir:

Projeye gidin: "Ayarlar" → "Depo" → "Korumalı dallar" a gidin.

GitLab 9.0 Öncesi

Proje: "Ayarlar" → "Korumalı dallar" (verilen projenin en azından 'Master'ıysanız).

Ardından "Korumayı kaldır" veya "Geliştiriciler zorlayabilir" seçeneğini tıklayın:

— Hcorg
kaynak

Bazı izinlerin gerekli olabileceğini unutmayın. Docs.gitlab.com/ee/user/project/protected_branches.html dosyasında belirtildiği gibi , en azından 'Ana izin düzeyi'. Benim durumumda bir ayar tekerleğine basmak sadece 'Projeden Ayrıl' seçeneğini gösterir.

— CoolMind

1

Nedense kendi projem için kendimi usta kullanıcı olarak eklemek zorunda kaldım.

— jgillich

3

Bu sorunu aldım çünkü KENDİ projemin bir üyesi DEĞİLDİM ve zaten bu projeyi ittim ... Bunu değiştirmek için, tur projesinde dişli çarkı, Üyeler, kullanıcı arama, bir rol verin ve "Ekle projelendirilecek kullanıcılar ".

— Loenix

Ben de garip, gitlab.com'daki kişisel bir projeye kendimi dahil etmek zorunda kaldım

— Thomas Decaux

1

Tek bakıcı veya geliştirici iseniz iyidir, böylece ayarı değiştirebilir ve onunla oynayabilirsiniz. Ancak repo üzerinde çalışan bir ekip varsa, repo korumasını değiştirmek iyi bir uygulama değildir.

— Mnemo

26

GitLab Enterprise Edition 9.3.0 için

Varsayılan olarak, ana dal korunur bu yüzden korumasız :)

1-Seçtiğiniz "proje"

2-"Havuz" u seçin

3-"Dallar" ı seçin

4-"Proje Ayarları" nı seçin

5-"Korumalı Dallar" da "genişletmek" için tıklayın

6-ve "korumayı kaldır" düğmesine tıkladıktan sonra

— krekto
kaynak

"Şubem" yoktu çünkü bu depoda henüz herhangi bir dosya oluşturmadım. Ben Readme.md dosyasını oluşturdum ve şubeler ortaya çıktı.

— Ikrom

1

Bu hatayla yerel gitlab sunucumdaki "boş bir dalda" karşılaştım. Bazı insanlar "boş bir dalda ilk kez itemezsiniz" diye bahsetti. Tarayıcım üzerinden gitlab üzerinde basit bir README dosyası oluşturmaya çalıştım. Sonra her şey inanılmaz sabit ve sorun dizildi! Usta olduğumu ve şubenin korunmadığından bahsediyorum.

— Vahid F
kaynak

Bu benim için tuhaf ve bu sorunu bir gitlab hatası olarak görüyorum. Boş bir repoya girme iznim olması benim için kabul edilemez. Umarım git çocuklar bunun için bir cevabı vardır.

— Vahid F

1

Bağlantıya göre değişiklik yapmayı deneyin

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

taahhüt ettiğiniz için projeyi bakıcı veya geliştirici için korumasız hale getirin

— Barath Ravichander
kaynak

1

Bu sorun için gitlab sahibi rolü olan kişi ile hızlı sohbet için basit bir çözüm. Sadece başlamak için READ.md veya benzeri bir dosyayı itebilir. Daha sonra her şey eskisi gibi çalışacak.

— kris
kaynak

Mümkünse, depodaki sahip rolünü almaya çalışın. Sahip rolüne sahip olduğunuzda, doğrudan ustalaşmayı taahhüt edebilirsiniz. İstenmeyen yeni projeler oluşturmak için can sıkıcı ama önleyici kanca.Repo sahibi ilk dosyayı itinceye veya sahip rolünüz olana kadar etrafta bir saldırı yok. Bu yardımcı olur umarım.

— kris

1

Bu sorun ortaya çıktığında Windows'daydım.

Hata garip çünkü kullanıcı adımı ve şifremi girmeden önce oluyor. Önbellek ya da bunun gibi bir şey olsaydı ne olurdu? Çevrimiçi olarak kazıyorum ve bu yanıtı gitlab'ın destek forumunda buldum :

"Denetim Masası => Kullanıcı Hesapları => Kimlik bilgilerinizi yönetin => Windows Kimlik Bilgileri" ni açtım. Https: //@github.com için iki tane buldum ve biri yanlış kullanıcıydı. Ben sildim ve bir sonraki "git push" Ben yeniden ve doğru kimlik bilgileri sağlandı ve çalıştı! Diğer bazı notlar - bu herhangi bir uzaktan kumanda ile olabilirdi.

Windows Kimlik Bilgilerinde, eski bir hesap için iki GitLab girdisi buldum. Her ikisini de kaldırıyorum ve şimdi çalışıyor!

Panel:

— aloisdg taşınma codidact.com
kaynak

@YanickSenn Bir şey değil. Bu konuda çok zaman kaybettim. Yardım etmekten memnunum.

— aloisdg moving to codidact.com

1

Bu Gitlab'da özellikler olarak kabul edilir.

Maintainer / Ownererişim, bu dokümanlarda belirtildiği gibi varsayılan ve korumalı dal için bir kez daha zorlamayı zorlayamaz

— mochadwi
kaynak

1

Aslında bu hiç de talihsiz değil. Kesinlikle iyi bir şey. Ekstra bir koruma katmanıdır.

— Chiramisu

0

Depomda da aynı sorunu yaşadım. Deponun efendisiyim ama böyle bir hatayla karşılaştım.

Projemi korumadım ve sonra tekrar korudum ve hata gitti.

Gitlab sürümünü önceki itme ve sorunlu olanı arasında yükseltmiştik. Sanırım bu yükseltme hatayı yarattı.

— jean pierre huart
kaynak

0

Yukarıdaki çözümler sorunun ne olduğunu açıkça göstermektedir; repo üzerinde kontrole sahip olmadığınızda, kodunuzu göndermenin en iyi yolu orijinal repodan bir Çatal oluşturmak ve kodunuzu bu yeni repoya göndermektir, böylece daha sonra orijinal olana itebilirsiniz.

— gogasca
kaynak