Neden herkes Git'i merkezi bir şekilde kullanıyor?

Git'i son iki şirketimde versiyon kontrolü için kullandım. Duyduğuma göre şirketlerin yaklaşık% 90'ı Git'i diğer sürüm kontrol sistemlerine göre kullanıyor.

Git'in en büyük satış noktalarından biri, ademi merkeziyetçi olmasıdır, yani tüm depolar eşittir; merkezi bir depo / hakikat kaynağı yoktur. Bu Linus Torvalds'ın şampiyon olduğu bir özellikti .

Fakat her şirketin Git'i merkezi bir biçimde kullandığı, sanki SVN veya CVS kullanacağı gibi görünüyor. Her zaman insanların çekip itdikleri bir sunucuda (genellikle GitHub'ta) merkezi bir depo vardır. Git'i amaçlandığı gibi ademi merkeziyetçi bir şekilde kullanan, (uygun görüldüğü gibi sınırlı tecrübelerime sahip olan) hiç kimseyi görmedim veya duymadım, yani diğer meslektaş depolarına uygun gördükleri şekilde bastırıp çekerek.

Benim sorularım:

1. Neden insanlar pratikte Git için dağıtılmış bir iş akışı kullanmıyor?
2. Modern versiyon kontrolü için dağınık bir şekilde çalışabilme becerisi çok mu önemli, yoksa sadece kulağa hoş geliyor mu?

Düzenle

Asıl soruma doğru tonu alamadığımı fark ettim. Dağıtılmış bir sürüm kontrol sistemi (DVCS) çok açık bir şekilde üstün olduğunda, neden birilerinin merkezi bir şekilde çalışacağını soruyor gibiydim . Aslında, demek istediğim, DVCS'ye hiçbir fayda göremiyorum . Yine de insanların üstünlüğünü vaaz ettiklerini duyuyorum, gerçek dünya benim görüşüme katılıyor gibi görünüyor.

Ahh, ama aslında sen olan merkezi olmayan bir şekilde budala kullanarak!

Git'in selefini mindshare'deki svn ile karşılaştıralım. Subversion, yalnızca bir tane “repo”, bir gerçek kaynağıydı. Bir taahhütte bulunduğunuzda, diğer tüm geliştiricilerin de taahhüt ettiği tek ve merkezi bir depodaydı.

Bu tür çalıştı, ancak en büyüğü korkunç birleşme çatışması olan çok sayıda soruna yol açtı . Bunlar, çözmek için can sıkıcıdan kabusa kadar her yerde olduğu ortaya çıktı. Ve tek bir doğruluk kaynağıyla, herkesin çalışmasını çözülene kadar çığlık atma noktasına getirme alışkanlığı vardı. Birleştirme çatışmaları kesinlikle git ile var olur, ancak bunlar iş durdurucu olaylar değildir ve çözülmesi daha kolay ve daha hızlıdır; genellikle herkesten ziyade sadece çelişen değişikliklerle ilgili olan geliştiricileri etkiler.

O zaman tek başarısızlık noktası var ve ortaya çıkan görevli sorunları var. Merkezi svn deponuz bir şekilde ölürse, yedeklemeden geri yükleninceye kadar hepiniz mahvolursunuz ve yedekleme yapılmadıysa, hepiniz iki kez vidalanırsınız. Ancak "merkezi" git repo ölürse, yedekten veya hatta CI sunucusundaki reponun diğer kopyalarından, geliştiricilerin iş istasyonlarından vb. Geri yükleyebilirsiniz. Bunu tam olarak dağıtıldıkları için yapabilirsiniz. ve her geliştiricinin deponun birinci sınıf bir kopyası vardır.

Diğer taraftan, git repo beri olduğu sen taahhüt zaman, senin kaydedilmesini yerel repo gidin kendi başına birinci sınıf bir repo. Onları başkalarıyla veya gerçekliğin merkezi kaynağına paylaşmak istiyorsanız, bunu açıkça bir uzaktan kumandaya basarak yapmalısınız. Diğer geliştiriciler daha sonra birisinin onları mahvedecek bir şey yapıp yapmadığını görmek için svn'yi sürekli kontrol etmek yerine, uygun olduğunda bu değişiklikleri aşağı çekebilir.

Doğrudan diğer geliştiricilere baskı yapmak yerine, değişiklikleri başka bir uzak repo üzerinden dolaylı olarak zorlamanız da önemli değil. Bakış açımızdan önemli olan kısım, reponun yerel kopyasının kendi başına bir repo olmasıdır. Svn'da, merkezi gerçeğin kaynağı sistemin tasarımı tarafından zorlanmaktadır. Git'te, sistemin bu kavramı bile yoktur; bir gerçekliğin kaynağı varsa, dışarıdan karar verilir.

Oluşturduğunuz yapı sunucusu (Ne zaman vardır , doğru CI kullanarak?) Bir yapı oluşturur, nereden alır? Tabii ki, iddia edebileceğiniz bir entegrasyon yapısının "tek bir gerçek repo" ya ihtiyaç duymadığını, ancak kesinlikle bir dağıtım yapısına (yani, müşteriye verdiklerinize) ihtiyacı olduğunu.

Başka bir deyişle: parçalanma. Bir repoyu "repo" olarak seçtiyseniz ve çekme isteklerini onaylayan koruyucuları atadıysanız, "bana bir yazılım derlemesi verin" veya "takıma yeniyim, kod nerede?"

DVCS'nin gücü, eşler arası yönü kadar değil, hiyerarşik olduğu gerçeğidir . Çalışma alanımı değiştiririm, sonra yerel olarak çalışırım. Bir özelliği tamamladıktan sonra, taahhütlerimi birleştirip onları uzaktan kumandama zorluyorum. Daha sonra, bir çekme isteği oluşturmadan önce bir proje geçici kodumu görebilir, geri bildirimde bulunabilir, vb. İşlemleri görebilir ve proje yöneticisi bunu One True deposuna birleştirir.

Geleneksel CVCS ile ya taahhüt edersiniz ya da yapmazsınız. Bu, bazı iş akışları için iyidir (farklı projeler için her iki VCS türünü de kullanırım), ancak bir kamu veya OSS projesi için yüzünde düz düşer. Önemli olan DVCS'nin daha fazla iş olan birden fazla adıma sahip olması, ancak yabancılardan gelen kodları, denetlenenlere daha iyi görünürlük sağlayan yerleşik bir işlemle kodlamak için daha iyi bir yol sağlamaktır. Merkezi bir şekilde kullanmak, hala yapabileceğiniz anlamına gelir Daha iyi bir kod paylaşma mekanizması sağlarken, projenin şu andaki haliyle bu altın standarda sahip olmak.

Sana "herkesi" define bilmiyorum, ama takımım ve "bir sunucuda merkezi repo" vardır da biz bu merkezi repo yoluyla gitmeden diğer iş arkadaşlarınızın repo dan çekin zaman zaman. Bunu yaptığımızda hala bir sunucu üzerinden geçiyoruz, çünkü yerle ilgili yamaları e-posta ile göndermemeyi tercih ediyoruz, ancak merkezi repo üzerinden değil. Bu, genellikle bir grup belirli bir özellik üzerinde işbirliği yaptığında ve birbiriyle güncel kalmak istediğinde gerçekleşir, ancak bu özelliği henüz herkese yayınlama konusunda hiçbir ilgisi yoktur. Doğal olarak, gizli silo çalışanları olmadığımız için bu durumlar uzun sürmez, ancak DVCS en uygun olanı yapma esnekliği sağlar. Bir özellik dalı yayınlayabiliriz ya da zevkinize göre yayınlayamayız

Fakat zamanın% 90'ı, elbette, merkezi depodan geçiyoruz. Herhangi bir değişiklik veya belirli bir meslektaşın işini umursamadığımda, her bir N'den ayrı olarak değişiklik yapmak yerine, "merkezi meslektaşımın onayladığı tüm meslektaşlarımın değişikliklerini çekmek" daha uygun olur ve daha iyi ölçeklenir. meslektaşlar. DVCS, "ana repodan çekme" işleminin en yaygın iş akışı olmasını engellemeye çalışmıyor, yalnızca mevcut iş akışı olmasını engellemeye çalışıyor.

"Dağıtılmış", tüm depoların gityazılım söz konusu olduğunda teknik olarak eşdeğer olduğu anlamına gelir , ancak geliştiricilerin ve iş akışlarımız açısından hepsinin eşit öneme sahip olduğunu takip etmez. Müşterilere veya üretim sunucularına bıraktığımızda, bunu yapmak için kullandığımız repo, dizüstü bilgisayarlarında yalnızca bir geliştirici tarafından kullanılan bir repodan farklı bir öneme sahiptir.

"Gerçekten merkezi olmayan" "hiçbir özel repolar var" anlamına geliyorsa o zaman bunu Linus olgusu açısından o göz önüne alındığında, şampiyon için ne anlama geldiğini sanmıyorum gelmez özel repo korumak olan olandan, şeylerin büyük düzeni daha önemli Dün yaptığım bazı rasgele Linux klonları ve sadece bazı küçük yamalar geliştirmek için kullanmayı planlıyorlar ve yamayı kabul ettikten sonra siliyorlar. gitrepoyu benimkine ayırmaz , ama Linus onu ayrıcalıklı kılar . Onun "şu anki Linux hali", benim değil. Yani doğal olarak değişiklikler eğilimindedirLinus'tan geçmek için. DVCS'nin merkezileştirilmiş VCS üzerindeki gücü, fiili bir merkez olması gerekmiyor, değişikliklerin herhangi bir merkezden geçmesi gerekmiyor, çünkü (izin verilen çatışmalar) herhangi bir şeyi birleştirebilir.

DVCS sistemleri aynı zamanda zorlanır , çünkü bunlar merkezi olmayan bir şirket olup, bir şey yapmak için yerel olarak mutlaka tam bir geçmişe (yani bir repo) sahip olmanız gerektiği gerçeğine dayanan bazı kullanışlı özellikler sunmak zorundadır. Ancak bunun hakkında düşünürseniz, merkezi bir VCS'yi, tarihin tamamen eski olmasına izin verilen salt okunur işlemler için tüm geçmişi saklayan yerel bir önbellekle yapılandıramazsınız. Bunun temel bir nedeni yoktur. ama hiçbir zaman Performance kullanmamıştım). Ya da prensipte yapılandırmak olabilir gitile senin.git/ağ bağlantınız olmadığında çalışmadığını gösteren SVN'nin "özelliğini" taklit etmek için uzaktaki bir dosya sisteminde dizin. Aslında, DVCS tesisatın merkezi bir VCS'de elde edebileceğinizden daha sağlam olmasına zorlar. Bu (çok hoş geldiniz) bir yan etkidir ve DVCS tasarımını motive etmesine yardımcı olmuştur, ancak teknik düzeydeki bu sorumluluk dağılımı, tüm insan sorumluluğunu tamamen merkezsizleştirmekle aynı değildir .

DVCS'nin doğası ile ilgili ilginç olan şey, eğer başkaları dağıtık bir şekilde kullanıyorsa, doğrudan sizinle etkileşime girmediği sürece muhtemelen bilemezsiniz. Kesin olarak söyleyebileceğiniz tek şey, siz ve doğrudan takım arkadaşlarınızın git bu şekilde kullanmadığınızdır. Bu şirket genelinde bir politika gerektirmez. Niye yüzden, soracaktır size merkezi olmayan bir şekilde budala kullanılır?

Düzenlemenizi ele almak için, belki de farklılıkları değerlendirmek için gerçek bir merkezi sürüm kontrolüyle çalışma konusunda biraz tecrübe edinmelisiniz, çünkü ince gözükse de, bunlar yaygındır. Bunlar ekibimin gerçekte iş yerinde yaptığı ve VCS'yi merkezileştirdiğimizde yapamadığımız şeylerdi:

• Her mikro hizmet için “merkezi” depoya erişimi olan çok küçük çekirdek geliştiriciler listesine sahip olun. Diğer herkes çatallardan çalışabilir ve çekme istekleri ile gönderebilir.
• Taahhüt Can çok saatte genellikle birkaç kez bir veya iki kez günde karşı daha sık.
• Herhangi bir sebeple iş arkadaşlarınızla geçici olarak koordine etmek için şubeler oluşturabilir, ona basıp günde birkaç kez itebilir, daha sonra daha büyük bir grupla paylaşmaya hazır olduğunuzda ezebilirsiniz. Geleneksel bir CVCS'de bunun gibi bir şey için geçici bir şube oluşturma izni almanın ne kadar zor olduğu hakkında bir fikriniz var mı?

Söylemek için yaşlı gibi görünme riski altında, ne kadar kolay olduğunu gerçekten bilmiyorsunuz.

Bence sizin sorunuz, (anlaşılabilir) daima bağlı bir zihniyetten geliyor. yani merkezi 'gerçek' ci sunucusu her zaman (veya her zaman neredeyse) kullanılabilir durumdadır. Bu, çoğu ortamda geçerli olsa da, bundan en az bir tanesinde çalıştım.

Bir Askeri Simülasyon projesi ekibim birkaç yıl önce üzerinde çalıştı. Tüm kodu (Biz söz ediyoruz> US $ 1b kod temeli) vardı makinelerde olmak (eğer yoksa kanun / uluslararası anlaşma ile, koyu takım elbiseli adamlar gelip) fiziksel olarak izole herhangi İnternet bağlantısı . Bu, her birimizin normalde 2 PC'ye sahip olduğu anlamına geliyordu; biri kodu yazmak / çalıştırmak / test etmek, diğeri Google işlerine, E-postayı kontrol etmek vb. Ve bu makinelerin ekibinde yerel olarak bir ağ vardı , açıkçası İnternete hiçbir şekilde bağlı değildi.

“Merkezi gerçeğin kaynağı”, bir ordu üssünde, tamamen kül olan bir yeraltı penceresiz odasında (güçlendirilmiş bina, yada-yada) bir makineydi. O makinenin internet bağlantısı da yoktu.

Periyodik olarak, git yüz deposuyla (tüm kod değişikliklerimizi içeren) bir diski ordu üssüne (fiziksel olarak) götürmek, birinin yüzlerce kilometre ötedeki uzaklığını taşımak için birinin işi olacaktır.

Üstelik çok sayıda ekibin bulunduğu çok büyük sistemlerde . Genelde her birinin kendi “merkezi” deposu olacaktır, bu daha sonra gerçek (tanrı katmanı) “merkezi” merkezi repo'ya geri döner. Aynı sabit diskli git repo dash'i kodlarıyla da yapan en az 1 müteahhit olduğunu biliyorum.

Ayrıca, eğer Linux çekirdeğinin ölçeğinde bir şey düşünürseniz ... Geliştiriciler sadece Linus'a çekme isteği göndermez. Temel olarak repo hiyerarşisi - her biri birisinin / bir takımın "merkezi" olduğu bir şey.

Git'in bağlantısı kesilmiş olması, bağlı model kaynak kontrol araçlarının ( örneğin SVN, örneğin ) kullanılamadığı veya kolayca kullanılamadığı ortamlarda kullanılabileceği anlamına gelir .

Sonuçta bir ürün üretiyorsunuz. Bu ürün kodunuzu tek bir zamanda gösterir. Buna göre, kodunuz bir yerde birleşmelidir . Doğal nokta, ürünün yapıldığı bir ci sunucu veya merkezi sunucudur ve bu merkezi noktanın bir git deposu olduğu mantıklıdır.

Bir DVCS'nin dağınık yönü her zaman açık kaynak geliştirmede çatal şeklindedir. Örneğin, katkıda bulunduğum bazı projeler asıl yazar tarafından terk edildi ve şimdi bakıcıların bazen birbirlerinden belirli özellikleri çektiği bir sürü çatal var. Genel olarak bile, OSS projeleri, rastgele insanlara temel gerçeği deposuna erişimi zorlamak yerine, çekme isteği yoluyla dış katkılar almaktadır.

Belirli bir resmi sürümde somut bir ürün üretirken bu çok yaygın bir kullanım durumu değildir, ancak F / OSS dünyasında istisna değil, normdur.

Niçin herkes git'i merkezi bir şekilde kullanıyor?

Hiç tanışmadık, siz nasılsınız diyorsunuz millet? ;)

İkincisi, Git'te bulduğunuz fakat CVS veya SVN'de bulunmayan daha başka özellikler var. Belki de sadece bu olması gerektiğini farz ediyor tek özelliği için herkes .

Birçok insanın CVS veya SVN gibi merkezi olarak kullanabileceğinden emin olun. Ancak, doğası gereği dağıtılmış bir VCS ile gelen diğer özelliği de unutmayın: tüm kopyalar az ya da çok "tamamlanmış" (tüm dallar ve tüm tarihler mevcuttur) ve tüm dallar bir sunucuya bağlanmadan kontrol edilebilir.

Bence bu unutulmaması gereken bir başka özellik.

Bunu kutudan çıkan CVS ve SVN ile yapamazsınız, ancak Git, eskileri gibi merkezileştirilerek sorunsuzca kullanılabilir.

Bu yüzden değişikliklerimi yerine getirebilirim, belki de devam eden işleri bir araya getirip ezip geçebilirim, sonra da çalışmalarımı ana gelişim dalına alıp yeniden yüklerim.

Git'le birlikte gelen diğer özellikler:

• kriptografik işaret taahhütleri
• rebasing (yeniden sıralama ve squash taahhütleri; sadece mesajı değil, taahhütleri düzenle)
• Kiraz toplama
• tarihi ikiye bölmek
• yerel şubeler ve saklama değişiklikleri (Wikipedia'da "raf" olarak adlandırılır)

Ayrıca Wikipedia'daki bu üç tabloya bakınız - Sürüm kontrol yazılımının karşılaştırılması :

• Özellikleri

• Temel komutlar

• Gelişmiş komutlar

Böylece, belki de ademi merkeziyetçi tarz, insanların onu kullanmasını sağlayan tek özellik değildir .

1. Neden insanlar pratikte Git için dağıtılmış bir iş akışı kullanmıyor?

Bitbucked, GitHub ve daha büyük bir projeye katkıda bulunan ya da daha büyük bir projeye ev sahipliği yapan herkes bunu yapacaktır. Sağlayıcılar "ana" depoyu korurlar, katkıda bulunan klonlar, taahhüt eder ve ardından bir çekme isteği gönderir.

Küçük projelerde veya ekiplerde bile şirketlerde, dağıtılmış bir iş akışı, ya modüller dış kaynak sağladıkları ve dıştan gelenlerin kutsal gelişim şubelerini değiştirmeden, değişikliklerini daha önce gözden geçirmeden değiştirmelerini istemedikleri bir seçenektir.

2. Yetenek dağınık bir şekilde çalışmalı, modern versiyon kontrolü için bile önemlidir, ...

Her zaman olduğu gibi: gereksinimlere bağlıdır.

Herhangi bir nokta geçerliyse, merkezi olmayan bir VCS kullanın:

• Çevrimdışı olarak tarihi işlemek veya yönlendirmek (örneğin tatil sırasında dağ kabinindeki alt modülü bitirmek) istiyorum
• merkezi repolar sağlayın, ancak değişiklikleri gözden geçirmek için (örneğin, büyük projeler veya dağıtılmış ekipler için) "gerçek" veri havuzunu ayrı tutmak istiyorum
• merkezi repoya doğrudan erişimi önlerken (ikinciye benzer şekilde), tarihin ve şubelerin hepsinin zaman zaman (bir kopyasını) vermek istemek
• Bir şeyi uzaktan saklamaya gerek kalmadan veya özel bir veri havuzu kurmak zorunda kalmadan bir şeyleri sürümlendirmek istiyorum (özellikle Git ile bir git init .şeyi sürümlemeye hazır olacak kadar basit )

Biraz daha var ama dördü yetmeli.

... yoksa kulağa hoş geliyor mu?

Tabii kulağa hoş geliyor - yeni başlayanlar için.

Esneklik bir lütuf olduğu kadar bir lanettir. Git son derece esnektir gibi, neredeyse her zaman var uzakta tipik durum için çok esnektir. Özellikle, çoğu Git projesi Linux değildir.

Sonuç olarak akıllı seçim Git'i uygularken bu teorik esnekliğin bir kısmını kaldırmaktır. Teoride depolar herhangi bir grafiği oluşturabilir, pratikte olağan tercih bir ağaçtır. Grafik teorisini kullanarak net faydaları görebiliyoruz: havuz ağacında, herhangi bir iki havuz tam olarak bir atayı paylaşıyor. Rasgele bir grafikte, bir ata fikri bile mevcut değil!

Bununla birlikte, git istemciniz, kesinlikle "tek ata" modeline kesinlikle varsayılandır. Ve düğümlerin tek bir ataya sahip olduğu grafikler (bir kök düğümü hariç) tam olarak ağaçlardır. Dolayısıyla git istemcinizin kendisi ağaç modeline ve dolayısıyla merkezi depolara varsayılandır.

İş mantığı, merkezi bir sunucuyu ödüllendirir. Neredeyse tüm gerçekçi işletme senaryoları için, merkezi bir sunucu iş akışının temel bir özelliğidir.

Sadece DVCS yapma kapasitesine sahip olmanız, birincil iş akışınızın DVCS olması gerektiği anlamına gelmez. Git işte kullanırken, dağıtılmış bitin işleri devam ettirmek için gerekli olduğu garip tuhaf durumlar dışında, merkezi bir şekilde kullanırız.

Şeylerin dağınık tarafı karmaşıktır. Genelde işleri sorunsuz ve kolay tutmak istersiniz. Bununla birlikte, git kullanarak, yoldan doğabilecek tehlikeli durumlarla başa çıkmak için dağıtılmış tarafa erişiminiz olduğundan emin olursunuz.

Bir iş arkadaşının makinemdeki bir git deposundan çıkması için, kök düzeyinde arka plan görevi olarak çalışan bir git cini kullanmam gerektiği anlamına gelir. Kendi bilgisayarımda veya şirket tarafından sağlanan dizüstü bilgisayarımda çalışan çok çalışan kadınlarla çalışıyorum. En kolay çözüm "HAYIR" dır! Bir iş arkadaşımın makinemdeki bir git deposundan çekmesi için internet adresimin sabit olması gerektiği anlamına gelir. Seyahat ediyorum, evden çalışıyorum ve bazen ofisimden çalışıyorum.

Öte yandan, VPN'in şirket sitesine gitmesi ve bir şubenin merkezi repoya itilmesi bir dakikadan az sürer. Ofisteysem VPN'ye ihtiyacım bile yok. İş arkadaşlarım kolayca o daldan çekebilir.

Üçüncü taraftan, yerel git depom tam özellikli bir havuz. Yeni bir iş yapabilir, deneysel işler için yeni bir şube oluşturabilir ve hiçbir yerin ortasından 30.000 feet hızla uçmakta olan bir uçakta çalışırken bile işleri tersine çevirdiğimde çalışmaya geri dönebilirim. Bunu merkezi versiyon kontrol sistemi ile yapmayı deneyin.

karmaşıklık:

Merkezi bir depoda, tipik bir iş akışı olabilir

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and push

O (1) deki geliştiricilerin sayısına göre karmaşıklık.

Bunun yerine, her geliştiricinin kendi ana şubesi varsa, geliştirici 0 olur:

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

Eşler arası yaklaşım O (N) 'dir.

Tutarlılık:

Şimdi Alice'in ana kolu ve Bob'un ana kolu arasında bir birleşme çatışması olup olmadığını düşünün. N geliştiricisinin her biri çatışmayı farklı şekilde çözebilir. Sonuç: kaos. Sonunda tutarlılık elde etmenin yolları vardır, ancak bu gerçekleşene kadar her türlü geliştirici zamanını boşa harcayabilirsiniz.

Basit:

Şirketler merkezi iş akışına sahip merkezi organizasyonlardır.

Her programcının bir patronu vardır ve patronu vb. CTO'ya kadar. CTO, teknik gerçeğin nihai kaynağıdır. Hangi araç şirketi kullanırsa kullanın, bu emir komuta zincirini yansıtmalıdır. Bir şirket bir ordu gibidir - özel sektörün genel oy kullanmasına izin veremezsiniz.

GIT, şirketler için faydalı olan özellikler sunar (örn. Kod incelemesi için istekleri çekme) ve bunları yalnızca GIT'e geçirme imkanı sunar. Merkezi olmayan kısım, sadece ihtiyaç duymadıkları bir özelliktir - bu yüzden onu görmezden gelirler.

Sorunuzu cevaplamak için: Dağıtılmış kısım, açık kaynak gibi dağıtılmış ortamda gerçekten üstündür. Sonuçlar kimin konuştuğuna bağlı olarak değişir. Linus Torvalds tam olarak hücre fareniz değildir, bu yüzden GIT'nin farklı özellikleri onun için github merkezli şirketinize göre önemlidir.

Belki de bordro işlemlerinin merkezileştirilmiş olmasından kaynaklanmaktadır, bu nedenle eğer ödeme almak istiyorsak, merkezi bir kişiyi mutlu etmek zorundayız.

Belki bir ürün yarattığımız içindir, bu yüzden müşteriler için yazılımın bir ana kopyasına ihtiyacımız var.

Belki bir programcının bir çok farklı makineye bağlanmak yerine, herkesin değişimini elde etmek için bir yere gitmesi çok daha kolaydır.

Belki de bunun nedeni hata veritabanının merkezileştirilmiş olmasıdır ve kodla senkronize tutulmalıdır .

Merkezileşmek harika, bir sorun olana kadar… ..

Dağıtılmış bir sistem olan Git, herhangi bir güncel depodan düşük bir maliyetle yeni bir merkez oluşturulmasına izin veriyor (depoyu ağa açmanız yeterli). Git, geliştirici makinelerindeki depolardan güncel olmayan bir yedeklemenin güncellenmesini de sağlar ve böylece merkezin kurtarılmasını kolaylaştırır.

Ağ kapalıyken havuzun yerel bir kopyasında birleştirme vb. İşlemi yapabilmek harikadır, ancak dağıtık bir sisteme gerek yoktur; sadece tüm verilerin yerel bir kopyasını tutan bir sisteme ihtiyacı var. Aynı şekilde, uçan vb.

Günün sonunda dağıtmak için çok az maliyet ve bazı avantajlar var. Dağıtımın maliyetinin büyük kısmı, şubelerin büyük takibi vb. açıkça birincil “kullanım durumu”.