Bazı birleştirme çakışmalarını çözdüm, sonra değişikliklerimi zorlamaya çalıştım ve aşağıdaki hatayı aldım:

c:\Program Files (x86)\Git\bin\git.exe push --recurse-submodules=check "origin" master:master
Done
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error: 
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error: 
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To C:/Development/GIT_Repo/Project
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'C:/Development/GIT_Repo/Project'

Bu hataya neyin sebep olabileceğini bilen var mı?

Sebep: Çıplak Olmayan Bir Depoya Zorluyorsunuz

İki tür depo vardır: çıplak ve çıplak olmayan

Çıplak depoların çalışan bir kopyası yoktur ve bunlara itebilirsiniz. Bunlar Github'da aldığınız depo türleri! Çıplak bir depo oluşturmak istiyorsanız,

git init --bare

Kısacası, çıplak olmayan bir depoya zorlayamazsınızDüzenle . Yapabileceğiniz şey, diğer havuzu almak ve birleştirmek. Bu nasıl pull requestsen Github eserlerinde görebilirsiniz. Onlardan senden çekmelerini istiyorsun ve onlara zorla itmiyorsun.

Güncelleme : Bunu işaret ettiği için VonC sayesinde, en son git versiyonlarında (şu anda 2.3.0), çıplak olmayan bir deponun kullanıma alınmış şubesine itmek mümkündür . Yine de, yine de güvenli bir işlem olmayan kirli bir çalışma ağacına itemezsiniz .

İlk önce uzaktan kumandanın kullanıma alınmadığını (gerçekten olması gerekmediğini) doğrulayarak bu sorunu çözdüm ve sonra çıplak hale getirdim:

$ git config --bool core.bare true

Bundan sonra git itme iyi çalıştı.

özet

Bir deponun kullanıma alınmış dalına zorlayamazsınız, çünkü o deponun kullanıcısıyla büyük olasılıkla veri ve geçmiş kaybıyla bitecek şekilde bozulur . Ancak aynı havuzdaki diğer herhangi bir şubeye gidebilirsiniz.

Çıplak depoların hiçbir zaman şubesi teslim alınmadığından, her zaman çıplak bir havuzun herhangi bir şubesine itebilirsiniz.

Sorunun otopsisi

Şube teslim alındığında, taahhütte bulunmak mevcut şubenin başı olarak yeni bir taahhüt ekler ve şubenin kafasını bu yeni taahhüt haline getirir.

Yani

A ← B
    ↑
[HEAD,branch1]

olur

A ← B ← C
        ↑
    [HEAD,branch1]

Ancak, birisi bu dalın arasına girebilseydi, kullanıcı git'in ayrılmış kafa modunu çağırdığı şeyde kendini alır :

A ← B ← X
    ↑   ↑
[HEAD] [branch1]

Şimdi kullanıcı, açıkça başka bir şubeye bakmalarını istemeden, branch1'de değil. Daha da kötüsü, kullanıcı şimdi herhangi bir şubenin dışında ve yeni taahhütler sadece sarkacak :

      [HEAD]
        ↓
        C
      ↙
A ← B ← X
        ↑
       [branch1]

Varsayımsal olarak, bu noktada, kullanıcı başka bir dalı kontrol ederse, bu sarkan taahhüt Git'in çöp toplayıcısı için adil bir oyun haline gelir .

Benim için, aşağıdaki hile yaptı:

git config --global receive.denyCurrentBranch updateInstead

Git'i kullanarak Windows 10 masaüstüm ile Windows 10 dizüstü bilgisayarım arasında senkronizasyon yapmak için F: sürücüsünü neredeyse tamamen ayarladım. Her iki makinede de yukarıdaki komutu çalıştırdım.

Önce masaüstünün F sürücüsünü ağda paylaştım. Sonra dizüstü bilgisayarımda çalıştırarak klonlayabildim:

F: git clone 'file://///DESKTOP-PC/f'

Ne yazık ki, tüm dosyalar doğrudan F: \ altında değil, dizüstü bilgisayarımdaki "F: \ f \" altında sona erdi. Ama onları elle kesip yapıştırabildim. Git daha sonra yeni konumdan çalıştı.

Sonra dizüstü bilgisayardaki dosyalarda bazı değişiklikler yapmayı, bunları taahhüt etmeyi ve masaüstüne geri itmeyi denedim. Yukarıda belirtilen git config komutunu çalıştırana kadar bu işe yaramadı.

Tüm bu komutları her iki makinede de Windows PowerShell içinden çalıştırdığımı unutmayın.

GÜNCELLEME: Bazı durumlarda hala değişiklikleri zorlarken sorunlar yaşadım. Sonunda değişiklikleri çekmeye başladım, bilgisayarda aşağıdakileri çalıştırarak en son taahhütleri çekmek istiyorum:

git pull --all --prune

cd'yi uzak makinede içeri aktardığınız repo / dizine girin ve

$ git config core.bare true

Zaten mevcut bir depo olduğu için,

git config --bool core.bare true

uzak depoda yeterli olmalı

Core.bare dokümanlarından

True olursa (bare = true), havuzun ilişkili çalışma dizini olmadan çıplak olduğu varsayılır. Bu durumda, git-add veya git-merge gibi bir çalışma dizini gerektiren bir takım komutlar devre dışı bırakılır (ancak buna itebilirsiniz).

Depo oluşturulduğunda bu ayar otomatik olarak git-clone veya git-init tarafından tahmin edilir. Varsayılan olarak "/.git" ile biten bir havuzun çıplak olmadığı varsayılır (çıplak = yanlış), diğer tüm havuzların çıplak olduğu varsayılır (çıplak = doğru).

TLDR

1. Pull & tekrar itmek: git pull &&& git push.
2. Hala bir sorun mu var? Farklı dallara itin: git push origin master:foove uzak repoda birleştirin.
3. Alternatif olarak ekleyerek zorlamayı zorlayın -f( denyCurrentBranchgöz ardı edilmesi gerekir).

Temelde hata, deponuzun uzak kodla güncel olmadığı anlamına gelir (dizini ve çalışma ağacı, ittiğinizle tutarsızdır).

Normalde pullönce son değişiklikleri alıp pushtekrar almalısınız .

Yardımcı olmazsa, farklı bir şubeye aktarmayı deneyin, örneğin:

git push origin master:foo

daha sonra uzaktaki depodaki bu dalı master ile birleştirin.

Geçmişteki bazı taahhütleri kasıtlı olarak değiştirdiyseniz git rebaseve değişikliklerinizle repoyu geçersiz kılmak istiyorsanız, muhtemelen -f/ --forceparametre ekleyerek push'u zorlamak istersiniz (eğer yapmadıysanız önerilmez rebase). Hala iş, sette gerekecek olursa receive.denyCurrentBranchüzere ignoreuzak olarak bir git mesajla önerdiği tarih:

git config receive.denyCurrentBranch ignore

Belki uzak deponuz itmek istediğiniz şubede. Uzak makinenizdeki başka bir şubeyi kontrol etmeyi deneyebilirsiniz. Bunu yaptım, bu hata ortadan kayboldu ve uzaktan repoma başarı getirdim. Github.com yerine kendi sunucumu bağlamak için ssh kullandığım dikkat edin.

Git repo (yanlışlıkla) aynı yerde iki kez başlatıldı çünkü bu hata var: ilk olarak çıplak olmayan bir repo olarak ve kısa bir süre sonra çıplak bir repo olarak. .Git klasörü kaldığı için git deponun çıplak olmadığını varsayar. .Git klasörünün ve çalışma dizini verilerinin kaldırılması sorunu çözdü.

Progiti okurken bu hatayı aldım. Yerel bir depo hazırladım, daha sonra aynı dosya sistemindeki başka bir depoya getirdim, bir düzenleme yaptım ve zorlamaya çalıştım. NowhereMan'ın cevabını okuduktan sonra, "uzak" dizine gitmek ve geçici olarak başka bir taahhüdü kontrol etmek, değişiklik yaptığım dizinden itmek, sonra geri dönüp kafayı ustaya koymak oldu.

Benim için çalışıyor

1. git config --global receive.denyCurrentBranch updateInstead

2. git push origin master