Yerel olandan uzak bir Git deposu nasıl oluşturulur?


243

Yerel bir Git depom var. Uzak, ssh özellikli bir sunucuda kullanılabilir hale getirmek istiyorum. Bunu nasıl yaparım?

Yanıtlar:


288

Uzak tarafta çıplak bir havuz oluşturduğunuzu, uzak tarafı git init --bareyerel deponuz için itme / çekme izleyicisi olarak ekleyin ( git remote add origin URL) ve sonra yerel olarak söyleyin git push origin master. Şimdi başka herhangi bir depo pulluzak depodan olabilir.


@Nips: evet, doğru, özür dilerim. Gerçekten şubeleri itiyorsunuz!
Kerrek SB

GUI kullanıyorsam ne olur? Tüm havuz için bir sunucu nasıl kurabilirim ve aynı ağdaki her PC buna bağlanabilir?
SearchForKnowledge

4
eğer git push origin masterhata "bulunamadı depo" ile başarısız deneyin git update-server-infoyaptığını, nerede uzak tarafındagit init --bare
HongKilDong

7
@KerrekSB, yerelde git push origin master'ı çalıştırır çalıştırmaz otomatik olarak sunucuda çıplak bir repo oluşturmak mümkün
ANinJa

@HongKilDong Denedim git update-server-infoama hata alıyorum fatal: Unable to look up Volumes (port 9418) (nodename nor servname provided, or not known)
Nayef

81

Başlangıçta herhangi bir Git sunucusu kurmak için, var olan bir depoyu yeni bir çıplak depoya, yani çalışma dizini içermeyen bir depoya vermeniz gerekir. Bunu yapmak genellikle kolaydır. Yeni bir çıplak depo oluşturmak üzere havuzunuzu klonlamak için, --bareseçenekle klon komutunu çalıştırırsınız . Kural olarak, çıplak depo dizinleri şu şekilde biter .git:

$ git clone --bare my_project my_project.git
Initialized empty Git repository in /opt/projects/my_project.git/

Bu komut, Git deposunu çalışan bir dizin olmadan kendi başına alır ve özel olarak yalnızca bunun için bir dizin oluşturur.

Deponuzun çıplak bir kopyasına sahip olduğunuza göre, tek yapmanız gereken onu bir sunucuya koymak ve protokollerinizi ayarlamaktır. Diyelim ki git.example.comSSH erişiminiz olan bir sunucu kurdunuz ve tüm Git depolarınızı /opt/gitdizinin altına kaydetmek istiyorsunuz . Yeni deponuzu, çıplak deponuzu şuraya kopyalayarak ayarlayabilirsiniz:

$ scp -r my_project.git user@git.example.com:/opt/git

Bu noktada, /opt/gitdizine okuma erişimi olan aynı sunucuya SSH erişimi olan diğer kullanıcılar , çalıştırarak deponuzu klonlayabilir

$ git clone user@git.example.com:/opt/git/my_project.git

Bir kullanıcı SSH'si bir sunucuya giriyorsa ve /opt/git/my_project.gitdizine yazma erişimine sahipse , otomatik olarak push erişimine de sahip olacaktır. Git init komutunu --sharedseçeneği ile çalıştırırsanız Git otomatik olarak bir depoya grup yazma izinleri ekler .

$ ssh user@git.example.com
$ cd /opt/git/my_project.git
$ git init --bare --shared

Bir Git deposu almak, çıplak bir sürüm oluşturmak ve sizin ve ortak çalışanlarınızın SSH erişimine sahip olduğunuz bir sunucuya yerleştirmek çok kolaydır. Artık aynı projede ortak çalışmaya hazırsınız.


6
scpSolüsyon daha pratikte IMO daha iyi çalışır init --bare. Yine de yerel olarak klonlamak, sonra sunucuya kopyalamak için yine de çirkin bir hack hissediyor ... git git bir seferde yapmak için bir komut olsaydı.
leftaroundabout

1
Bunu + 1'ledi çünkü --sharedbenim için çalıştı. Acaba git init --sharedbir --baretane yapmadan kullanırsanız ne olur ...
icedwater

1
Yerel olarak çıplak bir depo oluşturun ve scpuzaktan kumandanın desteklememesi durumunda uzaktan kumandaya daha iyi çalışır git init --bare(git 1.5.5, 2008'de olduğu gibi). Uzaktan kumandanın hiç gitmese bile bunun çalışması gerektiğini düşünüyorum.
Yaroslav Nikitenko


1
küçük bir not: çözümün adım scp'si doğrudur, ancak uzaktaki kullanıcının düzenli bir kabuğu varsa çalışır, kullanıcı bir git kabuğu kullanıyorsa çalışmaz.
user1708042

9

Windows'ta yerel kopyayı oluşturan ve Unix-line sistemde karşılık gelen bir uzak depo oluşturmak isteyen insanlar için bir not; burada metin dosyaları Unix benzeri sistemlerde geliştiriciler tarafından daha fazla klonda LF sonları alır, ancak Windows'ta CRLF sonları.

Satır sonu çevirisini ayarlamadan önce Windows deponuzu oluşturduysanız, bir sorununuz vardır. Git'in varsayılan ayarı çeviri değildir, bu nedenle çalışma kümeniz CRLF kullanır ancak deponuz (yani .git altında depolanan veriler) dosyaları da CRLF olarak kaydetmiştir.

Uzaktan kumandaya bastığınızda, kaydedilen dosyalar olduğu gibi kopyalanır, satır sonu çevirisi gerçekleşmez. (Satır sonu çevirisi, dosyalar havuzlara aktarıldığında değil bir depoya aktarıldığında gerçekleşir). Unix benzeri deponuzda CRLF ile sonuçlanırsınız, ki bu istediğiniz şey değildir.

LF'yi uzak depoya almak için, Windows deponuzu yeniden normalleştirerek önce LF'nin yerel depoda olduğundan emin olmalısınız . Bunun hala CRLF uçları olan Windows çalışma setinizde görünür bir etkisi olmayacaktır, ancak uzaktan kumandaya bastığınızda uzaktan kumanda LF'yi doğru şekilde alacaktır.

Windows deponuzda hangi satır sonlarına sahip olduğunuzu söylemenin kolay bir yolu olup olmadığından emin değilim - sanırım core.autocrlf = false ve sonra klonlama ayarlayarak test edebilirsiniz (repo LF sonlarına sahipse, klon LF de).


5

Yukarıdaki iki popüler çözüm arasında ilginç bir fark var:

  1. Eğer böyle bir çıplak depo oluşturursanız:

    cd / outside_of_any_repo
    mkdir my_remote.git
    cd my_remote.git
    git init - çıplak
    

ve sonra

cd  /your_path/original_repo
git remote add origin /outside_of_any_repo/my_remote.git
git push --set-upstream origin master

Daha sonra git bu ilişkiyle 'original_repo' içindeki yapılandırmayı ayarlar:

original_repo origin --> /outside_of_any_repo/my_remote.git/

ikincisi yukarı akış uzaktan kumandası olarak. Ve yukarı akışlı uzaktan kumandanın yapılandırmasında başka uzaktan kumanda yok.

  1. Ancak, bunu başka şekilde yaparsanız:

    (original_repo dizininden)
    cd ..
    git clone --bare original_repo /outside_of_any_repo/my_remote.git
    

daha sonra 'my_remote.git', yapılandırması 'orijinal' karakterini 'orijinal_repo'ya bir uzaktan kumanda olarak işaret ederek, remote.origin.url dosyasının yerel dizin yoluna denk geldiğini ve taşınacaksa uygun olmayabileceğini gösterir. bir sunucuya.

Bu "uzak" referans daha sonra uygun değilse kurtulmak için kolay olsa da, "orijinal_po" ifadesinin yine de "my_remote.git" öğesini yukarı akış uzaktan kumandası olarak (veya nereye giderse gitsin) gösterecek şekilde ayarlanması gerekir. paylaşılacak). Yani teknik olarak, aynı sonuca # 2 yaklaşımı ile birkaç adım daha varabilirsiniz. Ancak # 1, daha az adımla bir sunucuya taşınmaya uygun, yerel olandan kaynaklanan bir "merkezi çıplak paylaşılan repo" oluşturma konusunda daha doğrudan bir yaklaşım gibi görünüyor. Uzaktan repo'nun oynamasını istediğiniz role bağlı olduğunu düşünüyorum. (Ve evet, bu belgelerde ile ihtilaflı burada .)

Dikkat: Yukarıdakileri (Ağustos 2019 başlarında bu yazıda) yerel sistemim üzerinde gerçek bir repo ile bir test yaparak ve ardından sonuçlar arasında dosya bazında karşılaştırma yaparak öğrendim. Fakat! Hala öğreniyorum, bu yüzden daha doğru bir yol olabilir. Ancak testlerim, # 1'in şu anda tercih edilen yöntem olduğum sonucuna varmamı sağladı.


4

Uzak depo genellikle çıplak bir havuzdur - çalışma dizini olmayan bir Git deposu. Havuz yalnızca bir işbirliği noktası olarak kullanıldığından, anlık görüntünün diskte teslim alınması için bir neden yoktur; bu sadece Git verisidir. En basit ifadeyle, çıplak bir depo projenizin .git dizininin içeriğidir ve başka bir şey değildir.

Aşağıdaki kodu kullanarak bir çıplak git deposu oluşturabilirsiniz:

$ git clone --bare /path/to/project project.git

Uzak git deposuna sahip olmak için bir seçenek SSH protokolü kullanmaktır:

Kendi kendine barındırma SSH üzerinde olduğunda Git için ortak bir aktarım protokolü. Bunun nedeni, sunuculara SSH erişiminin zaten birçok yerde kurulmuş olmasıdır - ve eğer değilse, bunu yapmak kolaydır. SSH aynı zamanda kimliği doğrulanmış bir ağ protokolüdür ve her yerde olduğu için kurulumu ve kullanımı genellikle kolaydır.

Git deposunu SSH üzerinden klonlamak için aşağıdaki ssh://gibi bir URL belirleyebilirsiniz :

$ git clone ssh://[user@]server/project.git

Veya SSH protokolü için daha kısa scp benzeri sözdizimini kullanabilirsiniz:

$ git clone [user@]server:project.git

Yukarıdaki her iki durumda da, isteğe bağlı kullanıcı adını belirtmezseniz Git, şu anda oturum açmış olduğunuz kullanıcıyı varsayar.

Profesyoneller

SSH kullanmanın artıları çoktur. Birincisi, SSH'nin kurulumu nispeten kolaydır - SSH artalanları yaygındır, birçok ağ yöneticisi onlarla deneyime sahiptir ve birçok OS dağıtımı onlarla kurulur veya bunları yönetmek için araçlara sahiptir. Ardından, SSH üzerinden erişim güvenlidir - tüm veri aktarımı şifrelenir ve doğrulanır. Son olarak, HTTPS, Git ve Yerel protokoller gibi SSH de verimlidir ve verileri aktarmadan önce mümkün olduğunca kompakt hale getirir.

Eksiler

SSH'nin olumsuz yanı, Git deponuza anonim erişimi desteklememesidir. SSH kullanıyorsanız, insanların SSH'yi salt okuma kapasitesinde bile makinenize SSH erişimi olması gerekir; bu da SSH'yi, insanların incelemek için deponuzu klonlamak isteyebilecekleri açık kaynaklı projelere elverişli hale getirmez. Yalnızca şirket ağınızda kullanıyorsanız SSH, ilgilenmeniz gereken tek protokol olabilir. Projelerinize anonim salt okunur erişime izin vermek ve aynı zamanda SSH kullanmak istiyorsanız, başkalarını almak için başka bir şey getirmeniz için SSH'yi ayarlamanız gerekir.

Daha fazla bilgi için başvuruyu kontrol edin: Sunucudaki Git - Protokoller


3

Uzak sunucuda bir dizin oluşturmanız gerekir. Daha sonra depo olarak ayarlamak için "git init" komutunu kullanın. Bu, sahip olduğunuz her yeni proje için (her yeni klasör) yapılmalıdır.

Ssh anahtarlarını kullanarak zaten kurulum yaptığınızı ve git kullandığınızı varsayarsak, çalışan bir dizinden yürütüldüğünde bir uzaktan kumanda kuracak ve dizini git repo olarak başlatacak küçük bir Python betiği yazdım. Tabii ki, tüm depolar için sunucu ve Kök yolunu söylemek için komut dosyasını (yalnızca bir kez) düzenlemeniz gerekecektir.

Buradan kontrol edin - https://github.com/skbobade/ocgi


-3

Normalde git initkomutunu yalnızca komutunu kullanarak ayarlayabilirsiniz.

git init

Sizin durumunuzda, uzaktan kumandada zaten bir repo var. Uzak deponuza nasıl eriştiğinize bağlı olarak (url içindeki kullanıcı adı veya doğrulamayı işleyen bir ssh anahtarı ile) yalnızca clonekomutu kullanın:

git clone git@[my.url.com]:[git-repo-name].git

Repoyu klonlamanın başka yolları da var. Makinenizde deponuzu çektiğinizi doğrulayan bir ssh anahtarı kurulumunuz varsa bu şekilde çağırırsınız. Uzak deponuza giriş yapmak için şifrenizi ve kullanıcı adınızı içerisine eklemek istiyorsanız URL'nin başka kombinasyonları da vardır.


1
bu ne kadar ironik ... bugün birisi bu cevabı az önce reddetti ve şimdi dosyalarımı itmekte zorlanıyorum. Görünüşe göre tekrar gitmek için biraz git egzersizine ihtiyacım var!
Alex Cio

7
Bence sorun, OP bir ssh sunucusunda uzak bir repo oluşturmak için bir çözüm istedi, ancak uzak bir ssh sunucusundan nasıl yerel bir repo oluşturmak açıkladı. Soruya cevap vermedin. (Ben aşağı
değildim
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.