Git ile birden çok makinede çalışma


15

Bu biraz garip gelebilir, ancak Git'te bir şekilde birbirine bağlı birden fazla makineden çalışmanın iyi bir yolunu merak ediyorum. İki seçeneğim var gibi görünüyor ve her iki tarafta da faydaları görüyorum:

  • Paylaşmak için git kendisini kullanın, her makinenin kendi repo'su vardır ve aralarında getirmeniz gerekir.
    • Diğeri çevrimdışı olsa bile her iki makinede de çalışabilirsiniz. Bu tek başına bence oldukça büyük.
  • Makineler arasında ağ üzerinden paylaşılan bir repo kullanın.
    • Kodlarınız her zaman güncel olduğundan, makineleri her değiştirdiğinizde git pull'larına gerek yoktur.
    • Bu makinede bir dosya paylaşımında çalıştığınızdan, artık erişilemeyen diğer barındırmayan makinenizden kodu zorlamayı unuttuğunuzdan asla endişelenmeyin.

Sezgim, herkesin genellikle ilk seçenekle gittiğini söylüyor. Ancak gördüğüm dezavantaj, diğer makinelerinizden kodlara her zaman erişemeyebileceğiniz ve kesinlikle tüm WIP şubelerimi her günün sonunda github'a itmek istemiyorum. Ayrıca bilgisayarlarımı her zaman açık bırakmak istemiyorum, böylece doğrudan onlardan getirebiliyorum. Son olarak küçük bir nokta, birden çok dalı güncel tutmak için tüm git komutlarının sıkıcı olabilmesidir.

Bu durumun üçüncü bir kolu var mı? Belki de bu işlemi kolaylaştırmaya yardımcı olan bazı üçüncü taraf araçları mevcuttur? Bu durumla düzenli olarak ilgileniyorsanız, ne önerirsiniz?


git merkezi olmayan bir sürüm oluşturma aracıdır ve git klonlama yaparken her zaman deponuzun yerel bir kopyasını oluşturur, "merkezi" veya "benzersiz" bir depo hakkındaki kavram, git dünyasında küresel anlamda mevcut değildir.
user827992

2
@ user827992 Bu gerçeğin% 100 tamamen farkındayım. Merkezileştirme hakkında bir şey önerdiğimi sanmıyorum. Bahsettiğim tek şey, bir dosya paylaşımını kullanıyorsanız, bir makine, dosyaları fiziksel olarak depolaması anlamındadır. Dvcs'den tamamen ayrı bir kavram.
Tesserex

Bu konu stackoverflow.com/questions/1550378/… bazı iyi düşünceler içeriyor. Şubenin
taahhüt

Yanıtlar:


14

Her iki önerilen çözümünüzle de her gün ilgileniyorum. Bunları iyi idare etmek için iki temel kavram vardır.

  1. Konu dallarını kullanın. Üretim tarihinin bozulmamış olması gerektiğine inanıyorum. Sonuç olarak productionşubemin geçmişini mantıklı, tekrarlanabilir ve hata ayıklanabilir hale getirmek için çok zaman harcıyorum . Bununla birlikte, birden fazla makine kullanırken, ara sıra devam etmekte olan işleri yapmanız gerekir. Bir konu dalı kullanın. Şunları yapabilirsiniz pullve pushaz çabayla iki makinede bu dal ve birleşmeye hazır olduğunda masterveya production daha sürdürülebilir bir geçmişi oluşturmak için rebase.
  2. Başka kullanıcılarla da paylaşmıyorsanız, ağ üzerinden paylaşılan bir repo kullanmak iyidir. Komut dosyaları için yaratıcı bir şekilde scriptshavuz adı verilen paylaşılan bir havuz kullanıyoruz . İlk başta repo sık sık değişmediği için iyi bir fikir gibi görünüyordu, ancak zamanla oldukça kabus oldu. Bir başkasının çalışmasının üzerine yazmak kolaydır ve depoyu kimin içinde çalıştığını kimin dağıttığını kontrol etmek için çok fazla hava trafiği harcarsınız.

En iyi çözüm, her makinede yerel bir depo bulundurmak ve aralarındaki konu dallarını uzaktan kumanda ile paylaşmaktır. Bu şubelere istediğiniz sıklıkta devam eden çalışmalar yapın. rebaseOnları daha anlaşılır bir tarihe girmeye hazır olduğunuz sürece , pratikte oldukça etkilidir.

Kendinizi gün boyunca birden fazla konu dalı üzerinde çalışırken bulursanız, ancak her birini ayrı ayrı uzaktan kumandaya itmek istemiyorsanız, git push <remote>varsayılan olarak eşleşen tüm dalları buraya iter <remote>. Bu varsayılan Git sonraki bir sürümünde değişecek , ama tarafından bastırdı olabilir ayarı push.defaultbir yapılandırma dosyasında veya eşleştirme belirterek refspec:

git push <remote> :

3

Tüm makineler her zaman açık değilse, gümüş mermi yoktur: makineyi kapatmadan önce değişiklikleri başka bir yere itmeniz gerekir. Özel bir sunucuya geçiyorum, ancak her yerde taşıdığınız bir dropbox veya bir usb anahtarı da olabilir.

Evet, birden fazla şubeyi merkezi bir yere itmek sıkıcı olabilir, ancak bunu yazmak çok zor olmamalıdır. Bunun için bir push.shkomut dosyası kullanıyorum , bu da her makinede çalıştığımda çalıştırıyorum.


2

Buna biraz farklı bir yönden geldim (ve cıva kullanıyorum, ama felsefi olarak aynı). Bu benim fikrim değil, sadece kullanıyorum ve kişisel eşyalarım için çalışıyor.

Bir SkyDrive klasöründe depolarımın bir klonunu oluşturdum (eşit olarak dropbox veya seçtiğiniz başka bir sihirli senkronizasyon aracı olabilir), daha sonra iki makinemdeki örnekleri otomatik olarak yürütme sırasında SkyDrive deposuna itecek şekilde yapılandırdım.

Kutuları değiştirdiğimde, sadece bir çekme ve güncelleme yapma meselesi - teoride çoklu depolarda olmasına rağmen her zaman doğrusal bir şekilde çalışacaksınız.

Buradaki anahtar, SkyDrive deposunun çoğunlukla, her iki makinemde de kodun en son sürümüne daha az veya daha fazla erişime sahip olmasını sağlamak için bir araç sağlamak - ve daha fazlası için de işe yarayacağı - ve bir fazladan yedekleme. "Yapılan" herhangi bir şey Fırın itilir (git kullanarak olsaydım ve oyunun nasıl oynandığını doğru anlıyorsam, o zaman bir rebase yaptığım nokta olurdu).

Gerçekten yapmak istemediğim bir paylaşılan klasörden kaçmak ... bir DVCS kullanıyorsanız, o zaman da avantajın tadını çıkarabilirsiniz.


0

İki alternatifinizden ilki cevaptır. Bu, "DVCS" deki "D" tarafından ima edilir. Her kullanıcının kendi yerel havuz örneği vardır ve havuzlar kendi aralarında yönetilebilir yollarla konuşur.

İkinci alternatifinizi yapabilirsiniz, ancak sorun şu ki, sadece bir depo çalışma dizini var. Yani iş ağacı aynı anda sadece bir durumda olabilir - bir dalda çalışan Joe ve bir başka dalda çalışan Jane yoktur. Böylece geliştiriciler birbirlerinin değişikliklerinin üzerine yazabilir, birbirlerinin işlerini değiştirebilirler. Neden, versiyon kontrolü hiç yok gibi!

Bir ağ sürücüsünde çıplak bir depoya sahip olan ve tek tek kullanıcıların giriş ve çıkış yapmalarını sağlayan bir orta yol var. Bu, Devam Eden Çalışma çalışmanızı (evet, yerel olarak saklarsınız) depoya yayınladığınız çalışmadan ayırır. "Kaydet" değil - "yayınla". Meslektaşlarınızın görmesini ve kullanmasını istediğiniz iş.

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.