Çıplak olmayan bir Git deposuna nasıl aktarılır?


152

Git depom olan bir uzak sunucuda genellikle ssh (ekran ve vim) aracılığıyla çalışıyorum. Bazen çevrimiçi olmadığım için dizüstü bilgisayarımda ayrı bir depom (uzaktan kumandamdan klonlanmış) var.

Ancak, bu depodan uzak tarafta veri çekemiyorum çünkü genellikle bir güvenlik duvarının arkasındayım veya genel bir IP'ye sahip değilim.

Sadece çıplak bir depoya itmem gerektiğini okudum. Daha sonra değişikliklerimi uzak depoma nasıl aktarmalıyım?



3
Biri çıplak ve biri normal olmak üzere 2 uzak depoya sahip ve kancaları kullan. bir güçlük gibi görünüyor, ancak git ready ve resmi git wiki'ye göre , yalnızca çıplak bir depoya itmelisiniz . Muhtemelen git repo ana bilgisayarlarının (örn. GitHub, Bitbucket) sonradan alma kancaları içermesinin nedeni budur, böylece sunucunuzdaki örneğin çalışan bir komut dosyasını çalıştıran bir URL'ye POST yapabilirsiniz git pull github master.
Jake Berger

Yanıtlar:


139

receive.denyCurrentBranch updateInstead

Bu seçenekler Git 2.3'e eklendi ve eğer temizse sunucunun çalışma ağacını güncellemesini sağlıyor.

Bu nedenle, yerel olarak çekmeden önce her zaman yürüttüğünüzden ve sunucuda temiz bir çalışma ağacı tuttuğunuzdan emin olursanız (ki bu, birleştirme çakışmalarını önlemek için yapmanız gerekir), o zaman bu seçenek iyi bir çözümdür.

Ö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

heroku gibi çıplak bir depo oluşturmadan zorlamak mümkün mü
Rishabh Agrawal

2
@ANinJa Anlamıyorum, benim örneğim tam olarak böyle değil mi?
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

olan --localopsiyonel?
Yukulélé

@ Yukulélé --localyalnızca geçerli dizini --globaletkiler, ile tüm git depolarını etkiler ~/.gitconfig, bkz man git-config.
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

1
teşekkürler @CiroSantilli 新疆 改造 中心 六四 事件 法轮功 Belgeyi okuduktan sonra bunun gerekli olmadığını onaylıyorum "(--yerel diyebilirsiniz ama bu varsayılandır)"
Yukulélé

148

En iyi seçenek

Muhtemelen çıplak olmayan uzak deponuza girmenin en temiz, en az kafa karıştırıcı ve en güvenli yolu, dizüstü bilgisayar şubelerinizi temsil eden uzaktaki özel şubelere itmektir.

En basit duruma bakalım ve her depoda yalnızca bir şubeniz olduğunu varsayalım: ana. Master -> master, push master -> laptop-master (veya benzer bir ad) yerine dizüstü bilgisayarınızdan uzak depoya ittiğinizde. Bu şekilde push, uzak depodaki halihazırda teslim alınmış ana dalı etkilemez. Bunu dizüstü bilgisayardan yapmak için komut oldukça basittir:

git push origin master:laptop-master

Bu, yerel ana dalın uzak depodaki "laptop-master" adlı dala gönderileceği anlamına gelir. Uzak deponuzda, hazır olduğunuzda uzaktaki ana deponuzla birleştirebileceğiniz "laptop-master" adında yeni bir şubeniz olacak.

Alternatif Seçenek

Ayrıca sadece ana -> ana seçeneğine basmak da mümkündür, ancak çıplak olmayan bir deponun halihazırda ödünç alınmış dalına itmek genellikle önerilmez, çünkü neler olup bittiğini anlamıyorsanız kafa karıştırıcı olabilir. Bunun nedeni, teslim alınan bir dala göndermenin çalışma ağacını güncellememesidir, bu nedenle git status, teslim edilen teslim alınan dalı kontrol etmek , en son gönderilenle tam tersi farklılıkları gösterecektir. İtme yapılmadan önce çalışma ağacının kirli olması özellikle kafa karıştırıcı olabilir, bu da bunun tavsiye edilmemesinin büyük bir nedenidir.

Sadece master -> master'a basmayı denemek istiyorsanız, komut sadece:

git push origin

Ancak uzak depoya geri döndüğünüzde, büyük olasılıkla git reset --hard HEADçalışma ağacını itilen içerikle senkronize etmek için bir yapmak isteyeceksiniz . Bu tehlikeli olabilir , çünkü uzak iş ağacında tutmak istediğiniz herhangi bir taahhütte bulunulmamış değişiklik varsa, bunları ortadan kaldıracaktır. Denemeden önce bunun sonuçlarının ne olduğunu bildiğinizden emin olun veya en azından önce bir yedekleme yapın!

DÜZENLE Git 2.3'ten beri, "push-to-deploy" git push'u kullanabilirsiniz: https://github.com/blog/1957-git-2-3-has-been-released . Ancak, ayrı bir dala itip sonra birleştirme, gerçek bir birleştirme yaptığı için genellikle daha iyidir (bu nedenle, tıpkı birleştirme gibi taahhüt edilmeyen değişikliklerle çalışır).


1
Laptop-master'ı çalıştırdıktan sonra dallanmayı otomatikleştirmek mümkün müdür?
rdoubleui

3
@rdoubleui: " Birleştirmeyi otomatikleştir " mi demek istediniz ? Öyleyse, hayır, birleştirme işlemlerinin insan müdahalesi olmadan mümkün olacağı garanti edilmediğinden, birleştirmeyi otomatikleştirmek mümkün değildir. Çözülmesi gereken çatışmalar olabilir.
Dan Molding

7
sonraki sürümlerde (?), git config receive.denyCurrentBranch ignoreçıplak olmayan
depolara gönderilmeden

3
Harika cevap @DanMoulding, teşekkürler. @rdoubleui: aşağıdaki gibi bir komut satırını her zaman bir bash işlevi olarak kaydedebilirsiniz:git push origin master:laptop-master && ssh user@remotemachine 'cd repos_path && git merge laptop-master'
Zengin

@rdoubleui, birleştirmeyi otomatikleştirmek için, gitolite kullanabilir ve onu (biraz karmaşık) kurarak (biraz karmaşık) çıplak olmayan her şeyi kirletmek ve bunu git öncesi tetiği kullanarak gitolit (çıplak) sürümüne itmek için ayarlayabilirsiniz. Bundan sonra, birleştirme çıplak olmayan şekilde çözülemezse, itmenizi reddeder, böylece önce çekmeniz, birleştirmeleri çözmeniz ve tekrar itmeniz gerektiğini bilirsiniz. Henüz bunu ayarlamadım, ancak süreçteyim ve işe yarayacağını düşünüyorum.

17

Sunucunuzda bir çıplak depoya ve yerel çalışan (çıplak olmayan) bir havuza sahip olmanızı öneririm. Değişiklikleri dizüstü bilgisayardan sunucuya çıplak depoya aktarabilir ve ardından bu çıplak depodan sunucu çalışan depoya çekebilirsiniz. Bunu söylememin sebebi, sunucuda dizüstünde çoğaltmak isteyeceğiniz birçok tamamlanmış / eksik şubeye sahip olabileceğinizdir.

Bu şekilde, değişiklikleri sunucuya iletirken sunucu çalışan depoda teslim alınan şubenin durumu hakkında endişelenmenize gerek kalmaz.


Ama sadece bir dizüstü bilgisayarım ve bir sunucum varsa, neden 3 depom olsun? Estetik değil. Sunucudaki değişiklikleri devre dışı bırakmanın daha iyi olduğunu düşünüyorum. Örneğin, yalnızca git kullanıcılarının repo yazmasına izin vererek.
Tomas Zubiri

4

Diğer bir seçenek de, itmek yerine çekebilmeniz için ters bir ssh tüneli kurmaktır.

# start the tunnel from the natted box you wish to pull from (local)
$ ssh -R 1234:localhost:22 user@remote

# on the other box (remote)
$ git remote add other-side ssh://user@localhost:1234/the/repo
$ git pull other-side

Ve tünelin arka planda çalışmasını istiyorsanız

$ ssh -fNnR 1234:localhost:22 user@remote

1

Yapabilirsin:

$git config --bool core.bare true

bu çıplak veya merkezi bir depoda yapılabilir, böylece çıplak olmayan depolardan gönderilen tüm dosyaları kabul eder. Bunu çıplak olmayan bir depoda yaparsanız, hiçbir dosyayı çıplak olmayan depoya aktaramayız.

Bilgisayarda merkezi ve çıplak olmayan depo oluşturarak GIT alıştırması yapıyorsanız, bazı PC'lerde itilen dosyaları göstermeyebilir, ancak itilmiştir. çalıştırarak kontrol edebilirsiniz.

$git log merkezi depoda.

GitHub'a basmanız dışında, dosyaları orada gösterecektir.

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.