Git itme hatası '[uzaktan reddedildi] master -> master (şube şu anda teslim alınmış)'

Dün, Git deposunun makinelerimden birinden diğerine nasıl kopyalanacağı hakkında bir soru yayınladım , Başka bir makineden nasıl 'klonlayabilirim'? .

Artık bir Git deposunu kaynağımdan (192.168.1.2) hedefime (192.168.1.1) başarıyla kopyalayabiliyorum.

Ancak, a git commit -a -m "test"ve a dosyalarında bir düzenleme yaptığımda git push, hedefimde bu hatayı alıyorum (192.168.1.1):

git push                                                
hap@192.168.1.2's password: 
Counting objects: 21, done.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 1010 bytes, done.
Total 11 (delta 9), reused 0 (delta 0)
error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.
error: 
error: You can set 'receive.denyCurrentBranch' configuration variable to
error: 'ignore' or 'warn' in the remote repository to allow pushing into
error: its current branch; however, this is not recommended unless you
error: arranged to update its work tree to match what you pushed in some
error: other way.
error: 
error: To squelch this message and still keep the default behaviour, set
error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To git+ssh://hap@192.168.1.2/media/LINUXDATA/working
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'git+ssh://hap@192.168.1.2/media/LINUXDATA/working'

Git'in iki farklı sürümünü kullanıyorum (uzaktan kumandada 1.7 ve yerel makinede 1.5). Bu olası bir neden mi?

Uzak deponuzu yalnızca çıplak depoya dönüştürebilirsiniz (çıplak depoda çalışan bir kopya yoktur - klasör yalnızca gerçek depo verilerini içerir).

Uzak depo klasörünüzde aşağıdaki komutu yürütün:

git config --bool core.bare true

Ardından .git, bu klasör dışındaki tüm dosyaları silin . Ve sonra git pushuzak havuza herhangi bir hata yapmadan gerçekleştirebileceksiniz .

Git'i öğrenmeye başlarken aynı hatayla karşılaştım . Diğer cevaplardan bazıları Git için yeni olan biri için değil!

(Fikri ele almak için teknik olmayan terimleri kullanacağım.) Her neyse, olan şey, iki deponuz olması, biri ilk yaptığınız orijinal, diğeri az önce yaptığınız iş.

Şu anda çalışma havuzundasınız ve "ana" dalını kullanıyorsunuz. Ancak aynı "ana" şubeye orijinal deponuzda "giriş yapmış" olursunuz. Artık orijinalde "giriş yaptığınız" için Git, orijinal üzerinde çalışabileceğinizden ve işleri mahvettiğinizden korkabileceğinizden korkuyor. Bu yüzden orijinal depoya geri dönmeniz ve bir "git checkout someotherbranch" yapmanız gerekiyor ve şimdi sorunsuz bir şekilde itebilirsiniz.

Umarım bu yardımcı olur.

Hata mesajı ne olduğunu açıklar. Git'in daha modern sürümleri, bir şube kullanıma alınmışsa, bir dalı bir push ile güncellemeyi reddeder.

İki çıplak olmayan depo arasında çalışmanın en kolay yolu ya

1. depoları her zaman çekme (veya getirme ve birleştirme) ile güncelleyin veya gerekiyorsa,

2. ayrı bir dala (bir içe aktarma dalı) iterek ve o dalı uzak makinedeki ana dalda birleştirerek.

Bu kısıtlamanın nedeni, push işleminin yalnızca uzak Git deposunda çalışması, dizin ve çalışma ağacına erişimi olmamasıdır. Bu nedenle, izin verilirse, kullanıma alınmış şubeye yapılan bir basma , uzak depodaki dizin ve çalışma ağacıyla tutarsız olacak şekilde değişecektir HEAD .

Bu, tüm itilen değişiklikleri geri alan bir değişikliği yanlışlıkla yapmayı çok kolaylaştıracak ve ayrıca yapılmayan yerel değişiklikler ile yeni HEAD, endeks ve çalışma ağacı arasındaki farkları ayırt etmeyi çok zorlaştıracaktır. itme hareketinden kaynaklanır HEAD.

ö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.

İhtiyaçlarınıza bağlı olarak birden fazla çözüm vardır.

Çözüm 1: Çıplak Repostiory Kullanın

Önerildiği gibi, bir makinede çalışma dizinine ihtiyacınız yoksa, çıplak bir depoya gidebilirsiniz. Havuzla uğraşmaktan kaçınmak için klonlayabilirsiniz:

machine1$ cd ..
machine1$ mv repo repo.old
machine1$ git clone --bare repo.old repo

Şimdi istediğiniz her şeyi eskisi gibi aynı adrese gönderebilirsiniz.

Çözüm 2: Teslim Edilmeyen Bir Dalı Zorla

Ancak uzaktan kumandanızdaki kodu kontrol etmeniz gerekiyorsa <remote>, itmek için özel bir dal kullanabilirsiniz. Diyelim ki yerel deponuzda uzaktan kumandayı aradınız originve şube yöneticisisiniz. Sonra yapabilirsin

machine2$ git push origin master:master+machine2

O zaman originuzak repodayken birleştirmeniz gerekir :

machine1$ git merge master+machine2

Problemin 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 olarak taşır.

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 .

.git/configHedef sunucuda düzenleyerek bu "sınırlamayı" aşabilirsiniz. Bir git deposunun "teslim alınmış olsa bile" gönderilmesine izin vermek için aşağıdakileri ekleyin:

[receive]
denyCurrentBranch = warn

veya

[receive]
denyCurrentBranch = false

Birincisi, dalın dağılması olasılığını uyarırken itmeye izin verirken, ikincisi sadece sessizce izin verir.

Bu, kodu düzenleme amaçlı olmayan bir sunucuya "dağıtmak" için kullanılabilir. Bu en iyi yaklaşım değil, kod dağıtımı için hızlı bir yaklaşımdır.

git config --local receive.denyCurrentBranch updateInstead

https://github.com/git/git/blob/v2.3.0/Documentation/config.txt#L2155

Bunu sunucu havuzunda kullanın ve izlenmemiş bir üzerine yazma gerçekleşmezse çalışma ağacını da güncelleştirir.

Yorumlarda VonC tarafından belirtildiği gibi Git 2.3'e eklenmiştir .

Git 2.3'ü derledim ve denedim. Örnek kullanım:

git init server
cd server
touch a
git add .
git commit -m 0
git config --local receive.denyCurrentBranch updateInstead

cd ..
git clone server local
cd local
touch b
git add .
git commit -m 1
git push origin master:master

cd ../server
ls

Çıktı:

a
b

Yay, bitildi!

Uzak kutuda hala kullanılabilir bir depoya sahip olma fikrini seviyorum, ancak kukla bir dal yerine, kullanmayı seviyorum:

git checkout --detach

Bu bir çok yeni özellik gibi görünüyor Git Ben git sürüm 1.7.7.4 kullanıyorum -.

Aynı sorunu yaşadım. Benim için Git push komutunu sunucularıma taşımak için kullanıyorum. Ben asla sunucu tarafında kodu değiştirmek, bu yüzden bu güvenlidir.

Havuzda aşağıdakileri yazmak için bastırıyorsunuz:

git config receive.denyCurrentBranch ignore

Bu, çalışan bir kopyayken havuzu değiştirmenize olanak tanır.

Git düğmesini çalıştırdıktan sonra, uzak makineye gidin ve şunu yazın:

git checkout -f

Bu, ittiğiniz değişikliklerin uzak makinenin çalışma kopyasına yansıtılmasını sağlar.

İtiraz ettiğiniz çalışma kopyasında değişiklik yaparsanız bunun her zaman güvenli olmadığını lütfen unutmayın.

Sunucu havuzunuzu yeniden oluşturabilir ve yerel şube yöneticinizden sunucu yöneticisine gönderebilirsiniz.

Uzak sunucunuzda:

mkdir myrepo.git
cd myrepo.git
git init --bare

Tamam, yerel şubenizden:

git push origin master:master

Buna neden olmak için muhtemelen ne yaptınız:

Bu tür bir şey, küçük bir programı patlatmaya gittiğinizde olur. Halihazırda çalışan bir şeyi değiştirmek üzeresiniz, böylece seviye-3 kalıcı kalıcılık büyüsünü yapıyorsunuz:

machine1:~/proj1> git init

ve eklemeye / eklemeye başlarsınız. Ama daha sonra , proje başlar daha karışmaya ve böyle bir şey yapmak böylece, (ev PC veya dizüstü bilgisayar gibi) başka bir bilgisayardan üzerine çalışmaları istiyorum

machine2:~> git clone ssh://machine1/~/proj1

ve klonlar ve her şey iyi görünüyor ve böylece makinenizdeki kodunuz üzerinde çalışıyorsunuz2.

Sonra ... taahhütlerinizi makineden2 itmeye çalışıyorsunuz ve başlıktaki uyarı mesajını alıyorsunuz.

Bu iletinin nedeni, çektiğiniz git repo'sunun sadece makine1'deki klasör için kullanılması amaçlanmış olmasıdır. Sen edebilirsiniz klonlamak gayet ondan ancak iterek sorunlara neden olabilir. Kodun iki farklı konumda yönetilmesinin "uygun" yolu, önerildiği gibi, "çıplak" bir repo kullanmaktır. Bir çıplak Repo herhangi bir iş yapılıyor olması için tasarlanmamıştır içinde bunun, birden kaynaklardan kaydedilmesini koordine etmek anlamına gelir. Bu nedenle en yüksek puanlı yanıt , sizden sonra .git klasörü dışındaki tüm dosyaları / klasörleri silmenizi önerir git config --bool core.bare true.

En iyi cevabı açıklığa kavuşturmak : Bu cevaba yapılan yorumların çoğu, ".git olmayan dosyaları makineden1 silmedim ve hala makineden2 işleyebildim" gibi bir şey söylüyor. Doğru. Ancak, bu diğer dosyalar artık git deposundan tamamen "boşandı". Gidip git statusorada deneyin ve "ölümcül: Bu işlem bir çalışma ağacında yürütülmelidir" gibi bir şey görmelisiniz. Bu nedenle, dosyaları silme önerisi makine2'den gelen taahhüdün çalışacağı şekilde değildir ; kafanız karışmaz ve git'in bu dosyaları izlediğini düşünürsünüz. Ancak, hala makine1'deki dosyalar üzerinde çalışmak istiyorsanız, dosyaları silmek sorun olur, değil mi?

Peki, gerçekten ne yapmalısın?

Hala makine1 ve makine2 üzerinde ne kadar çalışmayı planladığınıza bağlı ...

Eğer makine1'den geliştirmeyi tamamladıysanız ve tüm gelişiminizi makine2'ye taşıdıysanız ... sadece en yüksek dereceli cevabın önerisini yapın: git config --bool core.bare trueve sonra isteğe bağlı olarak, .git dışındaki tüm dosyaları / klasörleri silin. takip edilmiyor ve karışıklığa neden olması muhtemel.

Eğer makine2'deki çalışmanız sadece bir kerelik bir şeyse ve orada gelişmeye devam etmeniz gerekmiyorsa ... o zaman çıplak bir repo yapmakla uğraşmayın; sadece ftp / rsync / scp / vb. makinenizdeki * 2 * dosyalarınızı makinedeki * 1 * üzerindeki dosyaların üzerine getirin, makineden * 1 * gönderin / alın ve ardından makinedeki dosyaları silin * 2 *. Diğerleri bir şube oluşturmayı önerdi, ancak yaptığınız bazı gelişmeleri bir kerede başka bir makineden birleştirmek istiyorsanız, bunun biraz dağınık olduğunu düşünüyorum.

Hem makine1 hem de makine2 üzerinde geliştirmeye devam etmeniz gerekiyorsa ... işleri düzgün bir şekilde ayarlamanız gerekir. Repo'yu çıplaka dönüştürmeniz gerekiyor, o zaman çalışmanız için makinede1 bir klon yapmanız gerekiyor . Muhtemelen bunu yapmanın en hızlı yolu

machine1:~/proj1> git config --bool core.bare true
machine1:~/proj1> mv .git/ ../proj1.git
machine1:~/proj1> cd ..
machine1:~> rm -rf proj1
machine1:~> git clone proj1.git
machine1:~> cd proj1

Çok önemli: repo konumunu proj1'den proj1.git'e taşıdığınız için, bunu machine2 üzerindeki .git / config dosyasında güncellemeniz gerekir . Bundan sonra, değişikliklerinizi makineden yapabilirsiniz2. Son olarak, çıplak depolarımı iş ağaçlarından uzak, merkezi bir yerde tutmaya çalışıyorum (yani 'proj1.git'i' proj1 'ile aynı ana klasöre koymayın). Aynı şekilde yapmanızı tavsiye ederim, ancak yukarıdaki adımları mümkün olduğunca basit tutmak istedim.

Birkaç kurulum adımında, web sitenize değişiklikleri aşağıdaki gibi bir astar kullanarak kolayca dağıtabilirsiniz.

git push production

Bu güzel ve basit ve uzak sunucuya giriş yapmak ve bir çekme veya başka bir şey yapmak zorunda değilsiniz. Üretim kasanızı çalışan bir şube olarak kullanmazsanız, bunun en iyi sonucu vereceğini unutmayın! (OP biraz farklı bir bağlamda çalışıyordu ve bence @Robert Gould'un çözümü buna iyi değindi. Bu çözüm uzak bir sunucuya dağıtım için daha uygundur.)

Öncelikle sunucunuzda, web kökünüzün dışında bir yerde çıplak bir havuz kurmanız gerekir.

mkdir mywebsite.git
cd mywebsite.git
git init --bare

Ardından dosya oluşturun hooks/post-receive:

#!/bin/sh
GIT_WORK_TREE=/path/to/webroot/of/mywebsite git checkout -f

Ve dosyayı yürütülebilir yapın:

chmod +x hooks/post-receive

Yerel makinenizde,

git remote add production git@myserver.com:mywebsite.git
git push production +master:refs/heads/master

Her şey hazır! Şimdi gelecekte kullanabilirsinizgit push production değişikliklerinizi dağıtmak için !

Bu çözümün kredisi http://sebduggan.com/blog/deploy-your-website-changes-using-git/ adresine gider . Neler olup bittiğine dair daha ayrıntılı bir açıklama için oraya bakın.

Sadece çıplak bir depoya gitmelisiniz. Çıplak depo, kullanıma alınmış şubesi olmayan bir havuzdur. Çıplak bir depo dizinine cd yapsaydınız, sadece .git dizininin içeriğini görürdünüz.

3 seçeneğiniz var

1. Tekrar çekin ve itin:

   git pull; git push
   

2. Farklı dallara itin:

   git push origin master:foo
   

   ve uzaktan kumandada birleştirin (ya gitda çekme isteği )

   git merge foo
   

3. Zorla (taahhütleri kasıtlı olarak değiştirmediyseniz önerilmez rebase):

   git push origin master -f
   

   Eğer hala devre dışı reddetti denyCurrentBranch üzerinde uzaktan depo:

   git config receive.denyCurrentBranch ignore
   

Aslında, uzaktan kumandayı kontrol edilmeyen bir şubeye ayarlamak yeterlidir. Uzaktan kumandanızı farklı bir dalda teslim ettikten sonra itebilirsiniz.

.git/configHedef projede kontrol edin :

$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[receive]
    denyCurrentBranch = updateInstead

Eğer core. bareyanlış, true olarak ayarlayabilirsiniz:

$ git config core.bare true

ve sonra yerel uzaktan kumandanıza:

git push remote_repo   // suppose the destination repo is remote_repo

başarılı olacak, remote_repo'da git sürümünü kontrol edebilirsiniz.

$ git log -1
commit 0623b1b900ef7331b9184722a5381bbdd2d935ba
Author: aircraft < aircraft_xxx@126.com>
Date:   Thu May 17 21:54:37 2018 +0800

ve şimdi git "çalışma alanınızda" kullanamazsınız:

$ git status
fatal: This operation must be run in a work tree

bare.barefalse olarak ayarlamanız gerekir .

$ git config core.bare false

Android telefonumda ve dizüstü bilgisayarımda depoları senkronize etmek için Git'i kullanırken de aynı sorunu yaşadım. @CharlesBailey'in önerdiği gibi, benim için çözüm bir itme yerine bir çekiş yapmaktı.

git push origin master Android depoda, @ hap497'nin bir depo + çalışma kopyasının çıplak olmayan bir çıkışına bir itme nedeniyle aldığı aynı hata mesajlarıyla benim için başarısız oluyor.

git pull droid masterdizüstü bilgisayar deposu ve çalışma kopyası benim için çalışıyor. Tabii ki, daha önce böyle bir şey çalıştırmanız gerekiyor git remote add droid /media/KINGSTON4GB/notes_repo/.

Git'in eski sürümleri, çıplak olmayan bir deponun şu anda kullanıma alınmış dalına aktarmalara izin vermek için kullanılır.

Bu, izin vermek çok kafa karıştırıcı bir şeydi. Böylece gördüğünüz uyarı mesajını da eklediler, bu da çok kafa karıştırıcı.

İlk depo sadece bir sunucu gibi davranıyorsa, diğer cevapların önerdiği ve onunla yapılabileceği gibi onu çıplak bir depoya dönüştürün.

Bununla birlikte, kullanımda olan iki depo arasında paylaşılan bir şubeniz olması gerekiyorsa, aşağıdaki kurulumla bunu gerçekleştirebilirsiniz.

Repo1 - sunucu olarak işlev görür ve geliştirme için de kullanılır

Repo2 - yalnızca geliştirme amaçlıdır

Repo1'i aşağıdaki gibi kurun

Üzerinde çalışma paylaşmak için bir şube oluşturun.

git branch shared_branch

Güvenli olmak için, paylaşılan branşlardan başka herhangi bir değişikliği reddeden bir $ (REPO) .git / hooks / güncellemesi de oluşturmanız gerekir, çünkü kişilerin özel dallarınızla mucking yapmasını istemezsiniz.

repo1/.git/hooks  (GIT_DIR!)$ cat update
#!/bin/sh
refname="$1"
oldrev="$2"
newrev="$3"

if [ "${refname}" != "refs/heads/shared_branch" ]
then
   echo "You can only push changes to shared_branch, you cannot push to ${refname}"
   exit 1
fi

Şimdi repo1'de asıl çalışmanızı yapacağınız yerel bir şube oluşturun.

git checkout -b my_work --track shared_branch
Branch my_work set up to track local branch shared_branch.
Switched to a new branch 'my_work'

( çalışmak git config --global push.default upstreamiçin gerekebilir git push)

Artık repo2 ile

git clone path/to/repo1 repo2 
git checkout shared_branch 

Bu noktada shared_branch, bu hata iletisi hakkında endişelenmenize gerek kalmadan veya çalışma dizininin repo1'de eşitlenmemesine gerek kalmadan repo1'de itip çeken yerel şubelerde çalışmak için hem repo1 hem de repo2 kurulumuna sahipsiniz. Kullandığınız normal iş akışı ne olursa olsun çalışmalıdır.

Tamam, normal bir uzak depo istemeniz durumunda, fazladan bir dal oluşturun ve bir göz atın. Bir şubeye itin (teslim edilmez) ve daha sonra yerel olarak ittikten sonra aktif olan bir dalla birleştirin.

Örneğin, uzak bir sunucuda:

git branch dev
git checkout dev

Yerel kurulumda:

git push 

Uzak sunucuda:

git merge dev

bareSunucu öğelerinin nasıl çalıştığını görmek için yapabileceğiniz bir test :

Bir iş istasyonunuz ve üzerinde canlı site barındıran bir sunucunuz olduğunu ve bu siteyi zaman zaman güncellemek istediğinizi düşünün (bu, iki geliştiricinin çalışmalarını çıplak bir aracı aracılığıyla ileri geri gönderdiği bir durum için de geçerlidir).

Başlatma

Yerel bilgisayarınızda ve içinde bir dizin oluşturun cd, ardından şu komutları yürütün:

# initialization
git init --bare server/.git
git clone server content
git clone server local

1. Önce çıplak bir serverdizin oluşturun (sonunda .git'e dikkat edin). Bu dizin yalnızca depo dosyalarınız için bir kap görevi görür.
2. Ardından, sunucu havuzunuzu yeni oluşturulan bir contentdizine kopyalayın . Bu, sunucu yazılımınız tarafından sunulacak canlı / prodüksiyon dizininizdir.
3. İlk iki dizin sunucunuzda, üçüncüsü iş istasyonunuzdaki yerel bir dizindir.

İş Akışı

Şimdi temel iş akışı:

1. localDizini girin, bazı dosyalar oluşturun ve kaydedin. Son olarak bunları sunucuya aktarın:

   # create crazy stuff
   git commit -av
   git push origin master
   

2. Şimdi contentdizini girin ve sunucunun içeriğini güncelleyin:

   git pull
   

3. 1-2'yi tekrarlayın. Burada contentsunucuya da itebilecek başka bir geliştirici localolabilir ve ondan da çekebilirsiniz.

Bunu yukarı akış yukarı şubesine itmek için bu sorunu benim için çözdü:

git push <remote> master:origin/master

Uzaktan kumandanın yukarı akış deposuna erişimi yoktu, bu yüzden bu uzaktan kumandanın en son değişikliklerini almanın iyi bir yoluydu

git --initMevcut bir çıplak depoda yeniden çalıştırılmak zorunda kaldım ve bu .gitçıplak depo ağacının içinde bir dizin yaratmıştı.git status oraya . Bunu sildim ve her şey tekrar iyiydi :)

(Tüm bu cevaplar harika, ama benim durumumda açıklandığı gibi (görebildiğim kadarıyla) tamamen farklı bir şeydi.)

Eminim bu soruyu görüntüleyen çoğu kişi ilk iki büyük cevapta duracaktır, ancak yine de çözümümü sunmak istiyorum.

Açıklanan hatayla karşılaştığımda bir Eclipse + EGit web projesi kurulumu yaptım. Bana yardımcı olan şey, sorunu sihirli bir şekilde çözmüş gibi görünen GitHub uygulamasını kullanmaktı. EGit her zaman itmeyi reddederken, GitHub masaüstü uygulaması sadece omuzlarını silkti ve değişikliklerimi itti. Belki çoklu giriş durumunu daha zarif bir şekilde ele alır.

Başkaları için yararlı olabileceğini düşündüğüm bir makale 5 dakika içinde Git .

Git sürüm denetimi altında bir DC'de bulunan bir Sanal Dağıtılmış Ethernet'e (VDE) kadar itmek istediğim bir Xcode projem vardı . VDE Centos'u çalıştırıyor 5'i .

Git hakkında okuduğum makalelerin hiçbiri çıplak depolardan bahsetmedi. SVN geçmişinden gelmesi kolay olduğunu düşündüğüm şeyi denemeden bu kadar basit geliyordu .

Buradaki uzak depoyu çıplak yapmak için öneriler işe yaradı. Gereksinimlerim için daha da iyisi Xcode projesini klonlamak projectname.git, uzak sunucuya kopyalamaktı; sonra büyülü çalıştı iter. Bir sonraki adım Xcode'un taahhütlerle ilgili hatasız itmesini sağlayacak, ancak şimdilik Terminal'den yapıyorum.

Yani:

cd /tmp (or another other directory on your system)<br/>
git clone --bare /xcode-project-directory projectname.git<br/>
scp -r projectname.git sshusername@remotehost.com:repos/<br/>

Xcode'u tamamladıktan sonra Xcode projenizdeki değişiklikleri göndermek için:

cd /xcode-project-directory<br/>
git push sshusername@remotehost.com:repos/projectname.git<br/>

Yukarıdakileri yapmanın daha pürüzsüz ve sofistike bir yolu olduğundan eminim, ancak en azından bu işe yarıyor. Her şey açık, işte bazı açıklamalar: /xcode-project-directoryxcode projenizin saklandığı dizin. Muhtemelen/Users/Your_Name/Documents/Project_Name . projectname, kelimenin tam anlamıyla projenin adıdır, ancak onu aramak istediğiniz herhangi bir şey olabilir. Git umurunda değil.

Scp'yi kullanmak için, uzak sunucuda SSH erişimine izin verilen bir kullanıcı hesabınızın olması gerekir . Kendi sunucusunu çalıştıran herkes buna sahip olacaktır. Paylaşımlı barındırma veya benzeri bir şey kullanıyorsanız, şansınız olmayabilir.

remotehost.comuzak ana bilgisayarınızın adıdır. IP adresini kolayca kullanabilirsiniz. Sadece daha fazla netlik için, uzak ana bilgisayarda Gitosis'i SSH anahtarları ile kullanıyorum, bu yüzden bastığımda şifreleri sormuyorum . Git Depolarını Barındırma makalesi , Kolay (ve Güvenli) Yol , tüm bunları nasıl ayarlayacağınızı anlatır.

Bunu yapmanın en iyi yolu:

mkdir ..../remote
cd ..../remote
git clone --bare .../currentrepo/

Bu, depoyu klonlayacaktır, ancak herhangi bir çalışma kopyası oluşturmayacaktır .../remote. Uzaktan kumandaya bakarsanız currentrepo.git, muhtemelen istediğiniz gibi adlandırılan bir dizin oluşturulur .

Ardından yerel Git deponuzdan:

git remote add remoterepo ..../remote/currentrepo.git

Değişiklik yaptıktan sonra şunları yapabilirsiniz:

git push remoterepo master

Heroku'daki bir git git deposuyla bu sorunla karşılaştım .

Heroku'nun neden çıplak olmayan bir deposu olduğunu bilmiyorum, ancak geçici bir çözüm olarak uzak depoyu sıfırlayabiliyor ve yeniden yükleyebiliyordum.

Heroku'nun deponuzun kopyasını işbirliği için tek git deponuz olarak kullanmamalısınız, ancak her ihtimale karşı, açıkça söyleyeceğim: Deponuzun tam bir kopyasının güvenli bir yerde saklanmadığından emin değilseniz bunu yapmayın Heroku. Sıfırlama yapılması, depo içeriğini siler.

Sıfırlamak:

0. Henüz yapmadıysanız Heroku araç kemerini (komut satırı istemcisini içerir) takın .

1. Henüz yapmadıysanız heroku-repo eklentisini yükleyin .

   heroku plugins:install https://github.com/heroku/heroku-repo.git
   

2. Depoyu silen ve yeni, boş bir tane oluşturan sıfırlamayı yapın

   heroku repo:reset
   

3. Heroku uzaktan kumandanıza normal şekilde basın; her şeyi yeniden yükleyecek.

Boş (çıplak) depo oluşturduktan sonra, uzak sunucudaki yapılandırma dosyasını değiştirmeniz gerekir.

root@development:/home/git/repository/my-project# cat config 

orada göreceksin

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true

Bu çıplak yanlış doğru yapacak ve logallrefupdates = true (kullanımından emin değilim!) Kaldırdım

için

[core]
repositoryformatversion = 0
filemode = true
bare = true

Aşağıdakileri test edebilirsiniz

$ git remote show origin
* remote origin
Fetch URL: my-portal@development:/home/XYZ/repository/XYZ
Push  URL: my-portal@development:/home/XYZ/repository/XYZ
HEAD branch: (unknown)

Bu HEAD dalı: (bilinmiyor) PUSH yapamıyorsanız gösterilecektir. Eğer HEAD dalı bilinmezse, çıplak değeri true olarak değiştirmelisiniz ve itme başarılı olduktan sonra

git remote show origin

ve göreceksin

 HEAD branch: master

Benim için çalışma çözümü:

UZAKTAN:

git checkout -b some_tmp_name

YERELDE:

git push

UZAKTAN:

git checkout master
git branch -d some_tmp_name

Ama bu sadece geçici çözüm olan gerçek çözüm değil.

Birisinin faydalı bulması durumunda. Benim için git sunucusu izinleri sorunuydu. Projeyi başlangıçtan itibaren kontrol ettim ve basit bir dosyayı ittim ve sonra "Push reddedildi: Orijin / master itme reddedildi"

Git ile iki normal (çıplak olmayan) havuz, dosyaları doğrudan ileri geri itemez / çekemez. Bir aracı çıplak depo olmalıdır. Görünüşe göre, bir çocuğu olan evli bir çift gibi ve çift boşanıyor. Ebeveynler birbirleriyle konuşmayacaklar, ancak çocuk aracılığıyla iletişim kuracaklar.

Yani, bir havuzunuz var, bu havuzu çıplak bir depoya kopyaladınız ve sonra bunu üçte birine kopyaladınız. Birincisi ve üçüncüsü ikinci depo olan çıplak olandan bilgi alışverişi yapabilir. Birisinin sizin onayınız olmadan deponuza bir şeyler kontrol etmesini istemeyeceğiniz için bu mantıklıdır, çünkü bu birleşme çatışmalarına ve benzerlerine neden olabilir.

İşte bir örnek:

PC'de ~ / çalışma alanında

git init
echo "line 1" > afile.txt
git add .
git commit -m ‘initial import’
git clone --bare . ../remote-repository.git
git remote add origin ../remote-repository.git
git push --set-upstream origin master

Dizüstü bilgisayarda, ~ / çalışma alanında (git init, vb. Yapmayın)

git clone //LJZ-DELLPC/remote-repository.git/ .

// Sonra çeşitli taahhütlerde bulunun ve itin:

echo "line 2" > afile.txt
git add afile.txt
git commit -m 'added line 2'
git push    

Sonra ~ / çalışma alanında PC'ye geri dönün

git pull

// Sonra çeşitli taahhütlerde bulunun ve itin:

git push

Dizüstü bilgisayarda git pull

ve benzerleri ..

Burada, komut penceresinden doğrudan kopyalanan tek bir makinede mutlak bir somut örnek var, böylece hiçbir adımın kalmadığını, gerçekten işe yaradığını vb.

lylez@LJZ-DELLPC ~
$ cd gitdir
/home/lylez/gitdir

lylez@LJZ-DELLPC ~/gitdir
$ ls

lylez@LJZ-DELLPC ~/gitdir
$ mkdir repo1

lylez@LJZ-DELLPC ~/gitdir
$ cd repo1
/home/lylez/gitdir/repo1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git init
Initialized empty Git repository in /home/lylez/gitdir/repo1/.git/

lylez@LJZ-DELLPC ~/gitdir/repo1
$ echo "line 1" > afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git commit -m 'initial import'
[master (root-commit) f407e12] initial import
 1 file changed, 1 insertion(+)
 create mode 100644 afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git clone --bar . ../repo1-bare-clone
Cloning into bare repository '../repo1-bare-clone'...
done.

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git remote add origin ../repo1-bare-clone

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git push --set-upstream origin master
Branch master set up to track remote branch master from origin.
Everything up-to-date

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cd ..

lylez@LJZ-DELLPC ~/gitdir
$ ls
repo1  repo1-bare-clone

lylez@LJZ-DELLPC ~/gitdir
$ mkdir repo1-remote

lylez@LJZ-DELLPC ~/gitdir
$ cd repo1-remote
/home/lylez/gitdir/repo1-remote

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git clone ../repo1-bare-clone .
Cloning into '.'...
done.

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ echo "line 2" >> afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git commit -m 'added line 2'
[master 5ad31e0] added line 2
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 260 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
   f407e12..5ad31e0  master -> master

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cd ../repo1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cat afile.txt
line 1

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git pull
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../repo1-bare-clone
   f407e12..5ad31e0  master     -> origin/master
Updating f407e12..5ad31e0
Fast-forward
 afile.txt | 1 +
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cat afile.txt
line 1
line 2

lylez@LJZ-DELLPC ~/gitdir/repo1
$ echo "line 3" >> afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git add afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git commit -m 'added line 3'
[master 3fa569e] added line 3
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1
$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 265 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ../repo1-bare-clone
   5ad31e0..3fa569e  master -> master

lylez@LJZ-DELLPC ~/gitdir/repo1
$ cd ../repo1-remote/

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ ls
afile.txt

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git pull
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /home/lylez/gitdir/repo1-remote/../repo1-bare-clone
   5ad31e0..3fa569e  master     -> origin/master
Updating 5ad31e0..3fa569e
Fast-forward
 afile.txt | 1 +
 1 file changed, 1 insertion(+)

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ cat afile.txt
line 1
line 2
line 3

lylez@LJZ-DELLPC ~/gitdir/repo1-remote
$ git --version
git version 2.1.1

lylez@LJZ-DELLPC ~/gitdir/repo1-remote

Çözümüm (kullanımda)

1. Uzak sunucuda ödeme "ana"
2. "Dev" dalında yerel olarak çalışın
3. Uzak geliştiricideki değişiklikleri aktarma
4. Uzaktan kumandayla geliştiriciyi master'a birleştir

Bingo