Bu yüzden işyerinde GIT sattırma sürecindeyim. İhtiyacım olan ilk şey, herkesi GIT'in halihazırda yapmaya alıştıkları şeyde daha iyi olduğuna ikna etmek. Şu anda Perforce kullanıyoruz. Benzer bir satış yapan başka kimse var mı? Herhangi bir iyi bağlantı / tavsiye?
En büyük kazançlardan biri, ağ ile bağlantısı kesilmiş olarak onunla çalışabilmemizdir. Bir başka kazanç IMO, ekleme / ödeme işlemlerinin işlenme şeklidir. Daha fazla puan açığız! Ayrıca toplamda yaklaşık 10-20 geliştiricimiz var.
Yanıtlar:
Perl 5 yorumlayıcı kaynak kodu şu anda Perforce'dan git'e dönüştürme sürecinden geçiyor. Belki Sam Vilain'in git-p4rawithalatçısı ilgileniyordur.
Her durumda, her merkezi VCS üzerinde sahip olacağınız en büyük kazançlardan biri ve en çok dağıtılanlar da ham, kabaran hızdır . Tüm proje geçmişinin elinizin altında, sadece bir saniyenin kesirleri kadar uzakta, deneyimleyene kadar ne kadar özgürleştirici olduğunu hayal edemezsiniz. Her bir kesinleştirme için tam bir fark içeren tüm proje geçmişinin bir commit günlüğünü oluşturmak bile bir saniyenin kesirleri ile ölçülebilir. Git o kadar hızlı ki şapkan uçacak. Ağ üzerinden gidip gelmek zorunda olan VCS'lerin, bir Gigabit Ethernet bağlantısı üzerinden bile rekabet etme şansı yoktur.
Ayrıca git, taahhütler yaparken dikkatli bir şekilde seçici olmayı çok kolaylaştırır, böylece çalışma kopyanızdaki (hatta tek bir dosyadaki) değişikliklerin birden fazla işleme ve ihtiyacınız olursa farklı dallara yayılmasına izin verir. Bu, çalışırken daha az zihinsel not almanıza olanak tanır - işinizi o kadar dikkatli planlamanıza, hangi değişiklikleri yapacağınıza önceden karar vermenize ve başka herhangi bir şeyi ertelemenize gerek yoktur. İstediğiniz değişiklikleri, başınıza geldiklerinde yapabilirsiniz ve yine de, taahhüt etme zamanı geldiğinde - neredeyse her zaman oldukça kolay bir şekilde - çözebilirsiniz. Zula burada çok yardımcı olabilir.
Buldum ki, bu gerçeklerin doğal olarak git kullanmadan öncesine göre çok daha fazla odaklanmış taahhütler yapmama neden olduğunu gördüm. Bu da geçmişinizi genel olarak daha kullanışlı hale getirmekle kalmaz, aynı zamanda gibi katma değerli araçlar için özellikle yararlıdır git bisect.
Eminim şu anda düşünemeyeceğim daha çok şey vardır. Ekibinizi git üzerinden satma önerisiyle ilgili bir sorun, yukarıda ima ettiğim gibi, birçok avantajın birbiriyle ilişkili olması ve birbirini etkilemesidir, öyle ki, git'in özelliklerinin ve faydalarının bir listesine basitçe bakmak ve bunların nasıl olduğunu anlamak zordur. iş akışınızı değiştirecek ve hangi değişikliklerin iyi niyetli iyileştirmeler olacağı. Bunu hesaba katmanız ve ayrıca açıkça belirtmeniz gerekir.
İş yerinde Perforce kullanıyorum. Ayrıca Git kullanıyorum çünkü kod üzerinde çalışırken ve sunucuya bağlanamadığımda hala bir çeşit sürüm kontrolü istiyorum. Hayır, çevrimdışı çalışmayı uzlaştırmak aynı şey değil. Git'in büyük bir fayda olduğunu bulduğum yer:
Bu benim 2 sentim. Perforce'un savunmasında, müşteri destek kurallarını ve Hızlandırılmış Görüntü İzleme araçlarını söylemeliyim. Git ile hızlandırılmış görünümü nasıl elde edeceğimi bilmiyorum. Ancak kolaylık ve kazanılan zaman için git ile her gün giderdim.
Perforce'dan geçiş yapmak beni çok ikna etmemi ister. Kullandığım iki şirkette fazlasıyla yeterliydi. Her ikisi de farklı ofislere sahip şirketti, ancak ofisler bol altyapı ile kurulmuştu, bu nedenle ayrık / bağlantısız özelliklere sahip olmaya gerek yoktu.
Kaç geliştiriciden bahsediyorsun?
Gerçek soru şudur: Kuruluşunuzun ihtiyaçlarını karşılamayan, git'in sağlayabileceği performans nedir? Ve benzer şekilde, git'in performansa kıyasla hangi zayıf yönleri var? Buna kendin cevap veremezsen, burada sormanın faydası olmaz. Şirketiniz için bir iş vakası bulmanız gerekiyor. (Örneğin, belki de daha düşük toplam sahip olma maliyetiyle (bu, ara öğrenme aşaması için üretkenlik kaybı, daha yüksek yönetici maliyetleri (en azından başlangıçta), vb.)
Bence zorlu bir satış yapmaktasınız - perforce, değiştirmeye çalışmak için oldukça iyi bir şey. Pvc'leri veya güvenliğini başlatmaya çalışıyorsanız, hiç akıllıca değil.
Bence / post değiştirme sırasında insanları mutlu tutmak açısından, erken geçilmesi gereken şeylerden biri, yerel bir şubenin Git'te ne kadar özel olabileceği ve onlara hata yapmaları için ne kadar özgürlük tanıyacağıdır. Hepsini mevcut koddan birkaç özel dalı klonlayın ve ardından deneyler yaparak oraya gidin. Bazı dosyaları yeniden adlandırın, öğeleri teslim edin, başka bir daldan gelen şeyleri birleştirin, geçmişi geri sarın, bir değişiklik kümesini diğerinin üzerine yeniden sıralayın, vb. Yerel olarak en kötü kazalarının bile meslektaşları için hiçbir sonucu olmadığını gösterin. İstediğiniz şey, geliştiricilerin kendilerini güvende hissettikleri, böylece daha hızlı öğrenebilecekleri (Git'in önemli olan dik bir öğrenme eğrisine sahip olduğu için) ve sonunda geliştiriciler olarak daha etkili olmaları için bir durumdur.
Merkezi bir araç öğrenmeye çalışırken, belli ki, depodaki diğer kullanıcılar için sorunlara neden olan bazı saçmalıklar yapmaktan endişeleneceksiniz. Utanma korkusu tek başına insanları denemekten caydırmak için yeterlidir. Özel bir "eğitim" havuzuna sahip olmak bile yardımcı olmuyor çünkü geliştiriciler, üretim sisteminde eğitim sırasında hiç görmedikleri bir durumla kaçınılmaz olarak karşılaşacaklar ve bu yüzden endişelenmeye geri dönecekler.
Ancak Git'in dağınık yapısı bunu ortadan kaldırır. Yerel bir şubede herhangi bir deneyi deneyebilirsiniz ve çok yanlış giderse, sadece dalı bir kenara atın ve kimsenin bilmesine gerek yok. Herhangi bir şeyin yerel bir dalını oluşturabildiğiniz için, gerçek canlı depoda gördüğünüz bir sorunu kopyalayabilirsiniz, ancak "yapıyı bozma" veya başka bir şekilde kendinizi aptal yerine koyma tehlikesi yoktur. Kesinlikle her şeyi kontrol edebilirsiniz, yaptığınız anda, işleri küçük paketlere ayırmaya çalışmak yok. Yani sadece bugün dört saat harcadığınız iki büyük kod değişikliği değil, aynı zamanda yarı yolda hatırladığınız o yapı düzeltmesi ve bir iş arkadaşınıza bir şeyi açıklarken bulduğunuz dokümantasyondaki yazım hatası vb. Ve proje yön değiştirdiği için büyük değişiklikler terk edilirse,
Beni kişisel olarak satan emir ikiye böldü . Bu özelliğin şu an için başka bir sürüm kontrol sisteminde mevcut olduğunu düşünmüyorum.
Bununla birlikte, insanlar kaynak kontrolü için bir GUI istemcisine alışkınlarsa, git'ten etkilenmeyeceklerdir. Şu anda tam özellikli tek istemci komut satırıdır.
git log --graph) ihtiyacınız var çünkü Git revizyon geçmişleri doğrusal olmama ve resim olmadan görselleştirilmesi zor olma eğilimindedir. GitX ve SourceTree'yi GUI'ler olarak kullanıyorum, ancak gitk (şimdi Git ile birlikte geliyor) bir tutam içinde geçirilebilir.
Kişiler hangi Perforce özelliklerini kullanıyor?
Soruyorum çünkü eğer herkes komut satırından alıp koyuyorsa, git bunu kapsıyor ve diğer tüm RTS de öyle.
Görünüşe göre GitHub artık şirketlere git eğitim kursları sunuyor . Blog gönderilerini bununla ilgili olarak aktarın :
Geçtiğimiz haftalarda birkaç kez Google kampüsüne gittim, Git'te Android'lerin eğitilmesine yardımcı oldum. Shawn Pearce benden (onu Git ve EGit / JGit ihtişamından tanıyor olabilirsiniz - Junio şehir dışındayken bakımı devralan kahramandır), Andriod üzerinde çalışan Google mühendislerini geçiş sürecinde eğitmesine yardım etmesini istedi. Perforce'dan Git'e , böylece Android kitlelerle paylaşılabilir. Bunu yapmaktan çok mutlu olduğumu söyleyebilirim.
[…]
Logical Awesome, artık tüm şirketlere bu tür özel eğitim hizmetini resmi olarak sunuyor . Git'e geçmeyi düşünüyorsanız, kuruluşunuza eğitim ve planlama konusunda yardımcı olabiliriz.
Vurgu benim.
Perforce'u uzun süredir kullanıyorum ve son zamanlarda GIT'i de kullanmaya başladım. İşte benim "objektif" görüşüm:
Performans özellikleri:
GIT özellikleri:
Genel olarak Açık Kaynaklı / Dağıtılmış projeler için GIT'i her zaman tavsiye ederim çünkü daha çok bir P2P uygulaması gibidir ve herkes geliştirmeye katılabilir. Örneğin, Perforce ile uzaktan geliştirme yaparken 4GB Projeleri 1Mbps üzerinden haftada bir kez senkronize ettiğimi hatırlıyorum. Bu nedenle çok fazla zaman boşa gitti. Ayrıca bunu yapmak için VPN kurmamız gerekiyordu.
Küçük bir şirketiniz varsa ve P4 sunucusu her zaman açık olacaksa Perforce'un da çok iyi bir seçenek olduğunu söyleyebilirim.
Bir süredir Git kullanıyorduk, yakın zamanda Git sunucumuzun sabit diski çöktü ve son durumuna geri dönemedik. Birkaç günlük duruma geri dönmeyi başardık. Sunucu yedeklendiğinde. Takımdaki herkes değişikliklerini çekti / itti ve işte, sunucu mevcut durumuna geri döndü.
Perforce ve git (ve en çok bahsedilen) arasındaki önemli bir fark, büyük ikili dosyaların ilgili işlemeleridir.
Örneğin, bir video oyunu geliştirme şirketindeki bir çalışanın blogunda olduğu gibi: http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html
Bununla birlikte, önemli olan, git ve perforce arasındaki hız farkının, dokümantasyondan şimdiye kadar inşa edilmiş her ikiliye kadar her şeyi içeren devasa bir 6gb deponuz olduğunda (ve son olarak, oh evet! Gerçek kaynak geçmişi) genellikle büyük şirketlerin Perforce çalıştırma eğiliminde oldukları ve bu nedenle tüm önemli işlemleri bodrumdaki devasa sunucu bankasına aktarmak için kurdular.
Perforce'un bu önemli avantajı, yalnızca Perforce ile hiçbir ilgisi olmayan bir faktörden, onu işleten şirketin söz konusu sunucu bankasını karşılayabileceği gerçeğinden kaynaklanıyor.
Ve sonuçta, Perforce ve git farklı ürünlerdir. Git, yalnızca bir VCS olacak şekilde tasarlandı ve bunu Perforce'den çok daha iyi yapıyor (daha fazla özelliğe sahip olması ve özellikle başka birinin sözleriyle kullanımı daha kolay olması, Perforce'da dallanma, açık kalp ameliyat, sadece uzmanlar tarafından yapılmalıdır: P) ( http://stevehanov.ca/blog/index.php?id=50 )
Perforce kazancını kullanan şirketlerin diğer avantajları, yalnızca Perforce yalnızca bir VCS olmadığından, aynı zamanda bir dosya sunucusundan ve derlemelerin performansını test etmek için bir dizi başka özelliğe sahip olduğu için geldi.
Son olarak: Git açık kaynak kodlu ve önyüklemesi çok daha esnek olduğundan, önemli işlemleri merkezi bir sunucuya yükleyerek pahalı donanım yığınlarını çalıştırmak için git'e yama uygulamak o kadar zor olmaz.
Sanırım GIT'in kazandığını bildiğim tek şey, tüm dosyalarda "satır sonlarını koruma" yeteneği, perforce ise bunları Unix, Dos / Windows veya MacOS9 formatına ("\ n", "\ r \ n "veya" \ r).
Windows ortamında veya karma bir işletim sistemi ortamında Unix betikleri yazıyorsanız, bu gerçek bir acıdır. Kuralın dosya başına uzantı temelinde belirlenmesi bile mümkün değildir. Örneğin, .sh, .bash, .unix dosyalarını Unix formatına ve .ccp, .bat veya .com dosyalarını Dos / Windows formatına dönüştürür.
GIT'de (bunun varsayılan mı, bir seçenek mi yoksa tek seçenek mi olduğundan emin değilim) "satır sonlarını koruyacak" şekilde ayarlayabilirsiniz. Bu, bir dosyanın satır sonlarını manuel olarak değiştirebileceğiniz anlamına gelir ve ardından GIT bu formatı olduğu gibi bırakır. Bu bana bir şeyler yapmanın ideal yolu gibi görünüyor ve bunun neden Perforce ile bir seçenek olmadığını anlamıyorum.
Bu davranışı elde etmenin tek yolu, dosyaları ikili olarak işaretlemektir. Gördüğüm kadarıyla, bu eksik bir özelliği geçici olarak çözmek için çirkin bir hack olurdu. Tüm komut dosyalarında, vb. Yapmak zorunda kalmanın sıkıcı olmasının yanı sıra, muhtemelen çoğu fark, vb. De kırılacaktır.
Şu anda kararlaştırdığımız "çözüm", Unix ortamlarına her konuşlandırıldıklarında betiklerden tüm şaryo dönüşlerini kaldırmak için bir sed komutu çalıştırmaktır. Bu da ideal değil, özellikle bazıları WAR dosyalarının içinde konuşlandırıldığından ve sed hattının paket açıldığında yeniden çalıştırılması gerektiğinden.
Bu sadece GIT'e büyük bir avantaj sağladığını düşündüğüm ve yukarıda bahsedildiğini düşünmediğim bir şey.
DÜZENLEME: Perforce'u biraz daha uzun süre kullandıktan sonra, birkaç yorum daha eklemek istiyorum:
A) Perforce'da gerçekten özlediğim bir şey, değiştirilen, kaldırılan ve eklenen dosyalar dahil olmak üzere açık ve örnek bir farktır. Bu git diffkomutla GIT'de kullanılabilir , ancak Perforce'da dosyaların değişiklikleri kaydedilmeden önce teslim alınması gerekir ve ana düzenleyicileriniz (Eclipse gibi) dosyaları düzenlediğinizde otomatik olarak teslim alacak şekilde ayarlamış olabilirsiniz. bazen dosyaları başka şekillerde düzenleyebilir (not defteri, unix komutları vb.). Ve oldukça can sıkıcı olabilen Eclipse ve p4eclipse kullanıldığında bile yeni dosyalar otomatik olarak eklenmiyor gibi görünüyor. Bu nedenle, tüm değişiklikleri bulmak için, tüm çalışma alanında bir "Farklılık ..." çalıştırmanız gerekir; bu, öncelikle çalışması biraz zaman alır ve ikinci olarak, çok karmaşık dışlama listeleri oluşturmadığınız sürece her tür alakasız şeyi içerir. bu beni bir sonraki noktaya götürüyor
B) GIT'de .gitignore dosyasını çok basit ve yönetmesi, okuması ve anlaması kolay buluyorum. Bununla birlikte, çalışma alanı Perforce'da yapılandırılabilen listeleri görmezden gelir / dışlar, hantal ve gereksiz şekilde karmaşık görünür. Joker karakterler çalışırken herhangi bir istisna elde edemedim. Gibi bir şey yapmak isterim
-//Server/mainline/.../target/... //Svend_Hansen_Server/.../target/...
Sunucu / ana hat içindeki tüm projelerdeki tüm hedef klasörleri dışlamak için. Ancak, bu beklediğim gibi çalışmıyor ve her proje için şöyle bir satır ekledim:
-//Server/mainline/projectA/target/... //Svend_Hansen_Server/projectA/target/...
-//Server/mainline/projectB/target/... //Svend_Hansen_Server/projectB/target/...
...
Ve bin klasörleri, .classpath ve .projet dosyaları ve daha fazlası için benzer satırlar.
C) Perforce'da oldukça kullanışlı değişiklik listeleri var. Ancak, bir grup değişiklik yaptığımı, hepsini kontrol ettiğimi ve bir değişiklik listesine koyduğumu, ardından bu değişiklik listesini göndermeden önce başka bir şey üzerinde çalıştığımı varsayalım. Daha sonra ilk değişiklik listesinde yer alan dosyalardan birinde bir değişiklik yaparsam, o dosya yine de bu değişiklik listesinde olacaktır ve değişiklik listesini yalnızca ilk olarak eklediğim değişiklikleri içerdiğini varsayarak gönderemem ( aynı dosyalar olacaktır). GIT'de, bir dosya eklerseniz ve bunlar üzerinde başka değişiklikler yaparsa, bu değişiklikler eklenmez (ve yine de birgit diffve önce yeni değişiklikleri de eklemeden dosyayı teslim edemezsiniz. Elbette bu, değişiklik listesinin yalnızca bir dizi eklenmiş dosyaya sahip olduğunuzda olabileceği gibi yararlı değildir, ancak GIT'de değişiklikleri gerçekleştirebilirsiniz, çünkü bu aslında onları zorlamaz. Onları zorlamadan önce diğer değişiklikler üzerinde çalışabilirdiniz, ancak daha sonra eklediğiniz başka hiçbir şeyi eski değişiklikleri de zorlamadan zorlayamazsınız.
Git ile hiç deneyimim yok, ancak aynı zamanda dağıtılmış bir VCS olan Mercurial ile de sahibim. Bu gerçekten projeye bağlıdır, ancak bizim durumumuzda dağıtılmış bir VCS, temelde sık sık bozulan yapıları ortadan kaldırdığı için projeye uygundur.
Bazıları bir istemci-sunucu VCS'ye daha uygun olduğu ve diğerleri dağıtılmış bir VCS'ye sahip olduğu için gerçekten projeye bağlı olduğunu düşünüyorum.
İşte git hakkında sevmediğim şeyler:
Öncelikle, dağıtılan fikrin gerçekliğe aykırı olduğunu düşünüyorum. Aslında git kullanan herkes, Linus Torvalds bile bunu merkezi bir şekilde yapıyor. Çekirdek dağıtılmış bir şekilde yönetildiyse, bu aslında "resmi" çekirdek kaynaklarını indiremeyeceğim anlamına gelirdi - bir tane olmazdı - Linus'un sürümünü mü yoksa Joe'nun sürümünü mü istediğime karar vermem gerekirdi. veya Bill'in versiyonu. Bu açıkça saçma olurdu ve bu yüzden Linus'un merkezi bir iş akışı kullanarak kontrol ettiği resmi bir tanım var.
Malzemelerinizin merkezi bir tanımını istediğinizi kabul ederseniz, sunucu ve istemci rollerinin tamamen farklı olduğu anlaşılır, bu nedenle istemci ve sunucu yazılımlarının aynı olması gerektiği dogması tamamen sınırlayıcı hale gelir. İstemci ve sunucu verilerinin aynı olması gerektiği dogması , özellikle kimsenin umursamadığı ancak herkesin klonlamak zorunda kalacağı on beş yıllık bir kod tabanında açıkça saçma hale geliyor.
Tüm bu eski şeylerle aslında yapmak istediğimiz şey, onu bir dolaba tıkmak ve orada olduğunu unutmaktır, tıpkı normal VCS'nin yaptığı gibi. Git'in her şeyi ağ üzerinden her gün ileri geri taşıması çok tehlikelidir, çünkü onu budamak için sizi rahatsız eder. Bu budama, birçok sıkıcı karar gerektirir ve ters gidebilir. Yani insanlar muhtemelen tarihin çeşitli noktalarından bir dizi anlık görüntü deposu tutacaklar, ancak ilk başta kaynak kontrolü bunun için miydi? Bu sorun, birisi dağıtılmış modeli icat edene kadar mevcut değildi.
Git, insanları tarihi yeniden yazmaya aktif olarak teşvik ediyor ve yukarıdakiler muhtemelen bunun bir nedenidir. Her normal VCS, geçmişi yeniden yazmayı yöneticiler dışında herkes için imkansız hale getirir ve yöneticilerin bunu düşünmek için hiçbir nedeni olmadığından emin olur. Yanılıyorsam düzelt ama bildiğim kadarıyla git normal kullanıcılara yazma erişimi vermenin hiçbir yolunu sağlamıyor, ancak geçmişi yeniden yazmalarını yasaklıyor. Bu, kin besleyen (veya hala öğrenme eğrisiyle mücadele eden) herhangi bir geliştiricinin tüm kod tabanını çöpe atabileceği anlamına gelir. Bunu nasıl sıkılaştırırız? Peki, ya tüm geçmişin düzenli yedeklerini yaparsınız, yani geçmişin karesini alırsınız ya da tüm farkları e-posta ile alıp elle birleştirecek bazı zavallı çocuklar dışında hepsine yazma erişimini yasaklarsınız.
İyi finanse edilen büyük bir proje örneğini ele alalım ve git'in onlar için nasıl çalıştığını görelim: Android. Bir keresinde android sisteminin kendisiyle oynamaya karar verdim. Gitlerine ulaşmak için repo adlı bir dizi komut dosyası kullanmam gerektiğini öğrendim. Depoların bir kısmı istemcide ve bazıları sunucuda çalışır, ancak her ikisi de, varlıkları gereği git'in her iki kapasitede de eksik olduğunu göstermektedir. Bir hafta kadar kaynakları alamadım ve sonra tamamen pes ettim. Birkaç farklı depodan gerçekten büyük miktarda veri çekmem gerekirdi, ancak sunucu benim gibi insanlarla tamamen aşırı yüklenmişti. Repo zaman aşımına uğradı ve zaman aşımına uğradığı yerden devam edemedi. Git bu kadar dağıtılabilirse, onların o tek sunucudaki yükü hafifletmek için bir tür eşler arası şey yaptım. Git dağıtılabilir, ancak bir sunucu değil. Git + repo bir sunucudur, ancak repo dağıtılamaz çünkü bu sadece geçici bir hack koleksiyonu.
Git'in yetersizliğinin benzer bir örneği gitolittir (ve görünüşe göre pek iyi çalışmayan atası). Gitolite işini git sunucusunun dağıtımını kolaylaştırmak olarak tanımlıyor. Yine, bu şeyin varlığı, git'in bir istemci olduğu kadar bir sunucu olmadığını da kanıtlıyor. Dahası, asla olmayacak, çünkü eğer ikisinden biri haline gelirse, kurucu ilkelerine ihanet etmiş olur.
Dağıtılmış şeye inanmış olsanız bile, git yine de bir karmaşa olurdu. Mesela şube nedir? Bir depoyu her klonladığınızda örtük olarak bir dal oluşturduğunuzu söylerler, ancak bu tek bir depodaki bir dal ile aynı şey olamaz. Yani dallar olarak adlandırılan en az iki farklı şey var. Ancak daha sonra bir depoda geri sarabilir ve düzenlemeye başlayabilirsiniz. Bu ikinci tür dal gibi mi, yoksa yine farklı bir şey mi? Belki de ne tür bir repoya sahip olduğunuza bağlıdır - oh evet - görünüşe göre repo da çok net bir kavram değil. Normal ve çıplak olanlar var. Normal bir parçayı zorlayamazsınız çünkü çıplak kısım kaynak ağacıyla senkronize olmayabilir. Ama bunu düşünmedikleri için çıplak bir tanesine aktaramazsınız. Bu yüzden normal bir tane cvsimport yapmalısınız, bunu, geliştiricilerin vurduğu çıplak bir dosyaya kopyalayın ve bunu, hala cvs'de kontrol edilmesi gereken bir cvs çalışan kopyasına aktarın. Kimler rahatsız olabilir? Tüm bu komplikasyonlar nereden geldi? Dağıtılmış fikrin kendisinden. Sonunda gitolitten kurtuldum çünkü bana bu kısıtlamalardan daha fazlasını dayatıyordu.
Git, dallanmanın hafif olması gerektiğini söylüyor, ancak birçok şirketin halihazırda ciddi bir sahtekar şube sorunu var, bu nedenle dallara ayırmanın katı polislik ile önemli bir karar olması gerektiğini düşünmüştüm. Performansın gerçekten parladığı yer burası ...
Perforce olarak nadiren dallara ihtiyaç duyarsınız çünkü değişiklik setlerini çok çevik bir şekilde halledebilirsiniz. Örneğin, olağan iş akışı, ana hat üzerinde bilinen en son iyi sürümle senkronize etmeniz ve ardından özelliğinizi yazmanızdır. Bir dosyayı değiştirmeye çalıştığınızda, o dosyanın farkı "varsayılan değişiklik kümenize" eklenir. Değişiklik kümesini kontrol etmeye çalıştığınızda, otomatik olarak ana hattaki haberleri değişiklik kümenizle birleştirmeye çalışır (etkili bir şekilde yeniden oluşturur) ve sonra taahhüt eder. Bu iş akışı, anlamanıza bile gerek kalmadan uygulanır. Böylece Mainline, daha sonra kolayca seçebileceğiniz bir değişiklik geçmişi toplar. Örneğin, eskisini, örneğin öncekinden öncekini geri döndürmek istediğinizi varsayalım. Sorun teşkil eden değişiklikten önceki ana senkronize edersiniz, etkilenen dosyaları değişiklik kümesinin bir parçası olarak işaretlersiniz, sonraki ana senkronize edin ve "her zaman benim" ile birleştirin. (Orada çok ilginç bir şey vardı: senkronizasyon aynı şeye sahip olmak anlamına gelmez - eğer bir dosya düzenlenebilirse (yani aktif bir değişiklik kümesindeyse), senkronizasyon tarafından engellenmez, ancak çözülme tarihi olarak işaretlenir.) suçlu olanı geri alan bir değişiklik listesi. Sonraki haberlerde birleşin ve istediğiniz etkiyi elde etmek için ana hattın tepesine yerleştirebileceğiniz bir değişiklik listeniz var. Hiçbir noktada tarihi yeniden yazmadık. Sonraki haberlerde birleşin ve istediğiniz etkiyi elde etmek için ana hattın tepesine yerleştirebileceğiniz bir değişiklik listeniz var. Hiçbir noktada tarihi yeniden yazmadık. Sonraki haberlerde birleşin ve istediğiniz etkiyi elde etmek için ana hattın tepesine yerleştirebileceğiniz bir değişiklik listeniz var. Hiçbir noktada tarihi yeniden yazmadık.
Şimdi, bu sürecin yarısını varsayarsak, birisi size koşar ve her şeyi bırakıp bazı hataları düzeltmenizi söyler. Varsayılan değişiklik listenize bir ad verin (aslında bir sayı), sonra onu "askıya alın", şimdi boş olan varsayılan değişiklik listesindeki hatayı düzeltin, uygulayın ve adlandırılmış değişiklik listesini devam ettirin. Farklı şeyler denediğiniz bir anda birkaç değişiklik listesinin askıya alınması tipik bir durumdur. Kolay ve özeldir. Şube rejiminden gerçekten istediğinizi, erteleme ya da ana hatta birleşmekten vazgeçme cazibesi olmadan elde edersiniz.
Sanırım git'te benzer bir şey yapmak teorik olarak mümkün olabilir, ancak git, onayladığımız bir iş akışını öne sürmek yerine pratik olarak her şeyi mümkün kılıyor. Merkezi model, geçersiz bir genelleme olan dağıtılmış modele göre bir dizi geçerli basitleştirmedir. O kadar genelleştirilmiş ki, temelde sizden repo gibi, bunun üzerine kaynak kontrolü uygulamanızı bekliyor.
Diğer şey ise çoğaltma. Git'te her şey mümkündür, bu yüzden kendiniz çözmelisiniz. Perforce olarak, etkin bir durum bilgisiz önbellek elde edersiniz. Bilmesi gereken tek yapılandırma, ana birimin nerede olduğudur ve istemciler kendi takdirlerine göre ana veya önbelleği işaret edebilir. Bu beş dakikalık bir iş ve yanlış gidemez.
Ayrıca kod incelemelerini, bugzilla referanslarını vb. İleri sürmek için tetikleyiciler ve özelleştirilebilir formlarınız var ve elbette gerçekten ihtiyaç duyduğunuz zamanlar için şubeleriniz var. Anlaşılır değil, ancak yakın ve kurulumu ve bakımı son derece kolay.
Sonuç olarak, herkesin yaptığı gibi merkezi bir şekilde çalışacağınızı biliyorsanız, bunun için tasarlanmış bir araç da kullanabilirsiniz. Git, Linus'un korkunç zekasıyla birlikte insanların koyun gibi birbirlerini takip etme eğilimi nedeniyle abartılıyor, ancak asıl varoluş nedeni aslında sağduyuya dayanmıyor ve onu takip ederek git, kendi elleriyle (a) yazılım ve (b) verilerin hem istemcide hem de sunucuda aynı olması gerektiğine dair iki büyük dogma ve bu her zaman merkezi işte karmaşık ve sakat hale getirecek.
Hatalı kod satırı yönetiminin yerine GIT kullanılması yaygındır. Perforce'un dezavantajlarının çoğu, kötü dallanma stratejilerinin bir sonucudur. Diğer merkezi araçlar için de aynı. Bir ton dal oluşturmanız gerekiyorsa, yanlış bir şeyler yapıyorsunuz demektir. Geliştiricilerin neden bu kadar çok dal oluşturması gerekiyor?
Ayrıca, bağlantısız çalışmak neden bu kadar önemli? Birinin trende çalışabilmesi için mi? Bugünlerde kablosuz bağlantı kuramayacağınız tek yer burası. Ve çoğu trende bile yeterli WiFi var.