Git'i ağ erişimi olmayan birden fazla sistemde kullanma


84

Sürüm kontrolü kullanmak istiyorum, ancak güvenlik nedeniyle üzerinde çalıştığım sunucunun internet erişimi yok: Yalnızca USB flash sürücüdeki dosyaları taşıyabilirim. Git'i bu kurulumla kullanabilir miyim? Git deposuna uygulayabileceğim küçük yamalar oluşturabilir miyim?


65
Başlığınız ağ erişimi olmadığını, sorunuzun internet erişimi olmadığını söylüyor; büyük bir fark.
tkausl

7
@TutuKaeen İnternete bağlı olmayan bir yerel ağa sahip olabilirsiniz. Böylece, github.com yerine git sunucusunu örn. 192.168.1.100 ve diğer her şey aynı şekilde çalışır.
Ajan_L

12
@TutuKaeen: Kritik soru, iki makine arasında doğrudan (veya dolaylı) bir ağ iletişiminin mümkün olup olmadığıdır. Yani sizin durumunuzda, her iki makine de ağa bağlı, ancak ağlar birbirinden ayrı mı? Bu durumda, lütfen bu bilgiyi sorunuza göre düzenleyin.
sleske

15
@TutuKaeen Sorunuz belirsizliğini koruyor. Sürüm kontrolünü kullanmak istediğinizi söylüyorsunuz, ancak yorumlarınızda üretime dağıtmanıza yardımcı olmanız gerekiyor. Bu konular her zaman üst üste gelmez. Şu an aşağıda iyi cevaplar aldığınızı düşünüyorum, ancak gelecekte, sorunuzun gereksinimlerinizle ilgili daha kapsamlı olsaydı, bu yararlı olurdu: "sürüm kontrolü kullanmak istiyorum, geliştirme makinem internet erişimine sahip değil. ağa erişimi var ama üretim makinesine değil ve sürüm kontrolünden kodların üretim makinesine nasıl alınacağını bilmek istiyorum. ”
DavidS

4
serverHerhangi bir ağa bağlı olmayan bir makine için terimi kullanmak çok garip görünüyor . İnternet bağlantısı olmasa bile sadece yerel bir ağ olabilir, ancak yine de bir ağ.
Patrick Gregorio

Yanıtlar:


157

Tabii, Git hakkında belirli bir protokol gerektiren hiçbir şey yok. Kutudan çıktığında standart istemci HTTP (S), SSH, özel Git protokolünü ve en önemlisi yerel protokolü destekler. Adlandırma bir kural olsa da, yalnızca .gitçalışma dizini ( /path/to/project/.git) veya yalnızca çıplak bir dizin ( /path/to/project.git) içinde olabilecek yerel bir dizine giden bir yol izler.

Bu, tabii ki, uzaktan kumanda olarak bir flash sürücü ekleyebileceğiniz anlamına gelir:

git remote add origin /mnt/flashdrive/foo.git

veya, Windows’ta:

git remote add origin F:\foo.git

Hatta farklı bir adla ek bir uzaktan kumanda olarak bile ekleyin (eğer originbir yerde bir İnternet sunucusuna işaret etmeyi tercih ederseniz ):

git remote add flashdrive /mnt/flashdrive/foo.git

O zaman bu diğer cihazlarda olduğu gibi bu uzaktan kumandayı itebilir / çekebilirsiniz.

Belgeleri okursanız, file://biraz farklı davranan bir protokol de olduğunu fark edeceksiniz . Bazı ek optimizasyonlardan faydalanacak bir yerel yol kullanılması önerilir - eğer file://protokolü kullanırsanız git, daha yavaş olan bazı standart ağ bileşenlerini (yerel diskle konuşmak için) kullanır.


50
Bu istisnai cevaba eklemek için - Ayrıca flash sürücüde 'çıplak' bir respository kullanarak araştırmak faydalı olabilir. “çıplak” depolarda çalışan bir ağaç yoktur ve bu nedenle OP'nin kullanım durumu gibi görünen paylaşılan bir “otorite noktası” olarak kullanıldığında olası bir sorun kategorisini kesti.
Iron Gremlin

5
Aynı file://zamanda biraz daha esnektir. Yerel bir yolla kullanamayacağınız bazı özellikleri (sığ klonlar gibi) kullanmanızı sağlar.
Austin Hemmelgarn 17:18

1
@IronGremlin Bu "paylaşılan otorite noktası" fikrini genişletebilir misiniz? Git uzmanı değilim ve bununla ne demek istediğinizi merak ediyorum.
Orbit'teki Hafiflik Yarışları

2
@LightnessRacesinOrbit - Bu oldukça yoğun bir konudur, fakat temelde git dağıtılır, böylece herkes kendi geçmişini alır. A, B'yi tarihin versiyonundan isteyebilir, ancak C bunu kimse söylemediği sürece bilmiyor. 'Yetkili' tarihçeyi saklamak için tek bir havuza sahip olmak, D'nin tarihler için bir açıklık evi olduğu anlamına gelir. Böylece, A, D'ye değişiklikleri anlatır ve B ve C, aralarında yanal kanallar yapmak yerine, güncel kalmak için D ile konuşmayı bilir. OP'nin sunucusu C ve flash sürücü D ise, sunucunun A / B etkileşimlerinin dışında kalmamasını sağlar.
Iron Gremlin

6
@LightnessRacesinOrbit Burada, çıplaklığın yetkili olmak zorunda olmadığına dikkat etmek önemlidir, sadece bu bağlamda kullanışlıdır. Örneğin, çalışan bir ağaçtan yoksun olması nedeniyle daha küçük bir disk alanı (veya bant genişliği) kapladığı için de faydalıdır. Bu, şimdi olduğundan daha önemli bir cehennemdi, ama yine de ortaya çıkıyor.
Iron Gremlin

46

Bir günü tek bir bilgisayarda, hiçbir özel ihtiyaç vardır. git initİstediğiniz dizinde koşun ve Git ile normalde yaptığınız gibi çalışın.

Bir havuzu birden fazla bilgisayar arasında senkronize etmek için birkaç yöntem vardır.

Yöntem 1a (hiç ağ yok): USB çubuğunda bir “çıplak havuz” oluşturabilir, daha sonra diğer herhangi bir uzak depoda olduğu gibi onu itip çekebilirsiniz. Başka bir deyişle, yerel yollarla depo işlemleri, SSH veya HTTPS URL'leriyle yapılan işlemlerden farklı değildir.

  1. 'Uzak' bir depo oluşturun:

    $ git init --bare /mnt/Stick/Repositories/Large_Project.git
    
  2. 1. bilgisayardaki her şeyi ona itin:

    $ cd ~/Large_Project
    $ git remote add usb /mnt/Stick/Repositories/Large_Project.git
    $ git push usb master
    
  3. 2. bilgisayarda, her zamanki gibi.

    $ git remote add usb /mnt/Stick/Repositories/Large_Project.git
    $ git pull usb
    

(Doğrudan bir URL'den veya yoldan da itebilir / alabilir / çekebilirsiniz.)

Yöntem 1b (dahili ağ): Kullanılabilir SSH dahili bir sunucunuz varsa ve Git kurulmuşsa, yukarıdakiyle aynı şeyi yapabilirsiniz , [user@]host:pathya da ssh://[user@]host/pathsözdizimini kullanarak sadece bir SSH adresi belirtin .

  1. git init --bare <somepath.git>Belirlenen sunucuda (SSH üzerinden) çalıştırarak 'uzak' bir depo oluşturun .

  2. 1. bilgisayarda, daha önce gösterildiği gibi.

    $ git remote add origin myserver.example.com:Gits/Large_Project.git
    

    Veya eğer tercih ederseniz:

    $ git remote add origin ssh://myserver.example.com/Gits/Large_Project.git
    
  3. Bilgisayar 2'de, yine yöntem 1a ile aynı.


Yöntem 2: Verilen bir liste listesini tek bir dosyada arşivleyen 'transfer paketleri' oluşturabilirsiniz.

Maalesef, paket komutları en son ne paketlendiğini otomatik olarak hatırlamıyor, bu nedenle manuel etiketleme veya not tutma gerekiyor. Ben sadece git-bundle kılavuzundan örnekleri alacağım.

  1. Bilgisayar 1'de tüm dalın bir demetini oluşturun:

    $ cd ~/Large_Project
    $ git bundle create /mnt/Stick/Project.bundle master
    $ git tag -f last-bundled master
    
  2. Bilgisayar 2'de paketten bir havuzmuş gibi çekin:

    $ cd ~/Large_Project
    $ git pull /mnt/Stick/Project.bundle
    

Sonraki paketlerin bütünü paketlemesi gerekmez master- last-bundled..masterbunun yerine yalnızca yeni eklenen paketleri paketleyebilirler .

  1. Bilgisayar 1'de yeni eklenen taahhütlerin bir demetini oluşturun:

    $ cd ~/Large_Project
    $ git bundle create /mnt/Stick/Project.bundle last-bundled..master
    $ git tag -f last-bundled master
    
  2. Yukarıdaki ile aynı.


Aslında benim amaçlarıma göre kötü olmaz, ayrıca git de hiçbir şey "birincil" değildir, çünkü her depoda tüm tarih vardır, bu yüzden bir şey kötüye gittiğinde onu yeniden yaratabilirsiniz
Tutu Kaeen

manual tagging or note-keeping is needed, repo çok büyük olmadığı sürece bir seçenek: git bundle create my.bundle --allher şeyi içermesi gerekir
birdspider

Bu cevabı daha çok beğendim, çünkü kabul edilmiş cevap da aynı şeyi söylüyor.
Rystraum

"Çıplak" seçeneğinin önemi nedir?
Orbit'teki Hafiflik Yarışları

1
'Çalışan bir ağaç' olmadan (düzenlenebilir dosyalar) yalnızca veritabanı olan (normalde .git/gizli klasörde bulacağınız) bir depo oluşturur . Yapacağınız depolar için tercih edilen formdur git push.
Grawity

20

git bundle create

Yöntemlerden biri havuzu arasında veri alışverişi için harici depolama kullanmaktır git demeti . Bu şekilde, ara Git depoları için değil, her aktarım için yalnızca tek dosyalarınız olur.

Her "git push" bir dosya oluşturulmasına dönüşür, "git fetch" bu dosyadan bir şeyler alır.

Demo oturumu

İlk depoyu oluşturmak ve ilk "ittirmeyi" yapmak

gitbundletest$ mkdir repo1

gitbundletest$ cd repo1

repo1$ git init
Initialized empty Git repository in /tmp/gitbundletest/repo1/.git/
repo1$ echo 1 > 1 && git add 1 && git commit -m 1
[master (root-commit) c8b9ff9] 1
 1 file changed, 1 insertion(+)
 create mode 100644 1

repo1$ git bundle create /tmp/1.bundle master HEAD
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 384 bytes | 384.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)

ikinci depoya "klonlama" (yani ikinci bilgisayar):

gitbundletest$ git clone /tmp/1.bundle repo2
Cloning into 'repo2'...
Receiving objects: 100% (3/3), done.

gitbundletest$ cd repo2/

repo2$ cat 1
1

Bazı değişiklikler yapın ve bunları başka bir paket dosyasına “itin”:

repo2$ echo 2 > 1 && git add 1 && git commit -m 2
[master 250d387] 2
 1 file changed, 1 insertion(+), 1 deletion(-)

repo2$ git bundle create /tmp/2.bundle origin/master..master origin/HEAD..HEAD
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 415 bytes | 415.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)

"çekerek" ilk depoda değişiklik yapar:

repo2$ cd ../repo1

repo1$ git pull /tmp/2.bundle 
Receiving objects: 100% (3/3), done.
From /tmp/2.bundle
 * branch            HEAD       -> FETCH_HEAD
Updating c8b9ff9..250d387
Fast-forward
 1 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

repo1$ cat 1
2

İlk paketin aksine, ikincisi sadece kısmi Git geçmişi içerir ve doğrudan klonlanamaz:

repo1$ cd ..

gitbundletest$ git clone /tmp/2.bundle repo3
Cloning into 'repo3'...
error: Repository lacks these prerequisite commits:
error: c8b9ff94942039469fa1937f6d38d85e0e39893a 
fatal: bad object 250d38747656401e15eca289a27024c61e63ed68
fatal: remote did not send all necessary objects

Her bir paketin hangi ürün grubunu içermesi gerektiğini elle belirtmeniz gereken paketlerin kullanımında dezavantaj vardır. Aksine git push, git bundleönceki pakette olanı izlemiyorsa, manuel olarak ayarlamanız gerekir, refs/remotes/origin/masteraksi takdirde paketler olabileceğinden daha büyük olur.


--allHer şeyi elde etmek için bayraktan bahsetmeyi unutmayın . Eğer depo yeterince küçükse, her seferinde her şeyi transfer ettiğiniz için bu en basit işlemdir! Sadece bellek çubuğunu kaybetmeyin - muhtemelen en büyük güvenlik sorunu!
Philip Oakley

7

Önce Git'i kurmanız gerekiyor . Ardından, yeni bir depo oluşturmak için kopyaladığınız klasörün içinde çalıştırın:

git init

Ardından sürüm kontrolü yapmak istediğiniz dosyaları git addekleyebilir -a(tüm dosyalar için ekleyebilir ) ve değişiklikleri yapmaya başlayabilirsiniz ( git commit).

Yerel geçmişinizde ( git log) çalışabileceğiniz için herhangi bir uzaktan kumandaya basmanız gerekmez .

Daha fazla bilgi için kontrol edin:


İnternet olmadan iterek / çekerek

git pushKomutu kullanarak , SSH'yi itmek mümkündür (yerel bağlantı kullanarak, intranet):

git remote add server ssh://[user@]host.xz[:port]/path/to/dev/repo.git/
git push server

veya klasöre iterek:

git push /mnt/usb/my_repo

Bu, deponuzun iki kopyasının olduğunu varsayar.

Çekme ile aynı, örn.

git pull /mnt/usb/my_repo

yama

Yama uygulamak için patchveya komutunu kullanabilirsiniz git apply.

Bakınız: Git deposundan yama veya fark dosyası oluştur ve başka bir git deposuna uygula .


5

Git'i yerel olarak da kullanabilirsiniz. Daha sonra taahhütleriniz yalnızca yerel olarak depolanır ve hala onunla sürüm kontrolüne sahipsiniz (ve farklı / birleştirme vb.), Ancak depoya başka herhangi bir bilgisayardan erişemezsiniz.

git initYerel klasörünüzde çalıştırarak yerel bir Git havuzu başlatabilirsiniz . Burada açıklandığı gibi .


3
Biliyorum, ama başka bir bilgisayarda çalışmak ve hiçbir internet erişimi olan sunucusundaki dosyalara uygulamak istediğiniz
Tutu Kaeen

2
@TutuKaeen Depoyu bir flash sürücüde bulundurmak ve sadece farklı bilgisayarların sabit sürücülerine klonlamak / senkronize etmekle ilgili yanlış bir şey görmüyorum. Ancak, "internet erişimi olmayan sunucu" garip geliyor, bir sunucunun amacı bir hizmet sunmaktır, çoğunlukla hizmet ağlarla ilgilidir (ancak her zaman değil, gerçekten de).
AnonymousLurker

2
@dhae - Git'i yerel olarak nasıl kullanacağınız konusunda daha fazla ayrıntı sağlamak için lütfen bir dakikanızı ayırın. Sadece bunun yapılabileceğini gösteren bir cevabın yardımı değil.
Ramhound

2
@anonymousLurker hizmet veren çok önemli bir kurumda kapalı ağa veri sunuyor. Veriler çok hassas olduğu ve sadece çalışanlar için olduğu için sadece internete hiçbir şey sunmuyor.
Tutu Kaeen

1
@TutuKaeen: Herhangi bir ağ erişimine sahipse , kendi Git sunucunuzu her zaman SSH ile çalıştırabilirsiniz. Git'in GitHub'dan daha fazlası var.
Grawity
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.