Kaynak kontrolü olmayan birden fazla kişiyle uygulama geliştirmenin en etkili / verimli yolu nedir?

Durumuma giriş

Küçük bir web geliştirme şirketinde çalışıyorum. Ben dahil dört ASP.NET geliştiricisinden oluşan bir ekibimiz var. Neredeyse tüm projelerimiz (>% 98) tamamlanması yaklaşık 1-4 hafta süren tek kişilik projelerdir. Kaynak veya sürüm kontrolü kullanmıyoruz. Sahip olduğumuz tek şey, yerel bir sunucudaki tüm projelerin en son kaynağını (== canlı uygulamanın kaynağı) içeren paylaşılan bir klasördür.

Birden fazla kişiyle aynı proje üzerinde çalışmamız gereken nadir durumlarda ... Karşılaştırmanın Ötesinde. Günde bir veya iki kez, geliştiriciler birbirlerine derleyen bir sürümleri olup olmadığını soruyorlar ve daha sonra kodlarını Karşılaştırmanın Ötesini kullanarak senkronize ediyorlar. Sadece iki kişi bir proje üzerinde çalışırken, bu "oldukça iyi" çalışır, ancak üçüncü bir geliştirici sürece girer girmez yönetilemez bir çöp parçası haline gelir. Özellikle herkes veritabanında değişiklik yapmaya başladığında.

Ben (ve geliştiricilerimin bir ya da iki tanesi) birkaç kez patronuma Git, Mercurial veya TFS gibi bir tür kaynak ve sürüm kontrolü kullanmaya başlamamız gerektiğini söyledim (patronumuz çok Microsoft düşüncelidir). Ne yazık ki, patronum bir kaynak ve sürüm kontrol sistemine geçmenin avantajını görmüyor, çünkü gözlerinde her şey şimdi iyi çalışıyor ve yeni bir sistem kurmak ve herkesin emin olmasını sağlamak için zaman ve para yatırmak istemiyor nasıl kullanılacağını bilir. Avantajlarını (basitleştirilmiş işbirliği, uygulamanın farklı sürümleri, kod değiştirmenin daha güvenli bir yolu gibi ...) açıkladıktan sonra bile, bunun hala ihtiyacımız olan bir şey olduğunu düşünmüyor.

Dört geliştiriciden sadece ikisi (ben dahil) kaynak kontrolü (Git) konusunda deneyim sahibidir. Ve bu deneyim çok sınırlıdır. Bir Github deposunu bilgisayarıma nasıl kopyalayacağımı, bazı değişiklikler yapmayı, bunları taahhüt etmeyi ve Github'a geri itmeyi biliyorum. Bu kadar.

Sorunumun / endişemin açıklaması

Birkaç hafta içinde standartlarımız için oldukça büyük bir proje üzerinde çalışmaya başlayacağız. Muhtemelen tamamlanması birkaç ay süren 2-3 geliştiriciyi alacaktır. Proje sorumlusu olacağım (proje yöneticisi ve baş geliştirici) ve her şeyden ben sorumlu olacağım. Karşılaştırma Ötesinde yaklaşımımızla ilgili sorunlardan payımı aldım ve sorumluluğum olacak bu büyük proje ile bu yola girmek istemiyorum.

Şüphe ettiğim için

• kendi Git sunucumuzu kurduk,
• herkese Git ile çalışmasını öğretin ve
• Git'i bu büyük projede başarıyla istihdam etmek,

Herhangi birinizin birden fazla kişinin aynı proje üzerinde kaynak veya sürüm kontrolü kullanmadan işbirliği yapmasına izin vermenin iyi yollarını bilip bilmediğini merak ediyorum.

Güncelleme

Yanıtları ve yorumları için herkese teşekkür ederim. İşte plan:

1. Tüm teknik çalışanların kaynak kontrolünü uygulama konusunda aynı şekilde hissetmelerini sağlamak için geliştiricilerle bir toplantı yapın. Herkes arkasındayken daha güçlü bir noktaya değineceğiz.
2. Fikri patrona sunun ve ona gerçekten kaynak kontrolüne ihtiyacımız olduğunu söyleyin .
3. Mümkün olan en kısa sürede uygulayın.

Lütfen sürüm kontrolünü yüklemek için bir gün ayırın ve projedeki herkese onu kullanmayı öğretin. O kadar zor değil. Şahsen Git'i kullanmadım, ancak diğer sürüm kontrol sistemlerini kurdum ve kullandım ve çalışmak o kadar da zor değil. Geliştirme ortamınızla bütünleşen bir tane seçtiğinizden emin olun. Bu, kullanımı neredeyse kesintisiz hale getirecektir.

Bu zaman kaybetmeyecek.

Zaman olacak birisi üzerinde yazma veya silme bazı kod çok daha mal olacak zaman kaybeder.

Sürüm kontrolünüz yoksa, projenizi yedeklemek ve herkesin hangi sürüme sahip olduğu ve sunucuda hangi sürümün olduğu hakkında endişelenmek için çok fazla zaman harcayacaksınız.

Patronunuzu, herhangi bir sürüm dışı kontrol çözümünü kurup izlemeniz ve birkaç günlük kayıp işi yeniden yazma maliyetini eklemeniz için gereken süreyi tahmin etmeye ikna etmeniz gerekiyorsa. Aynı kaynak dosya üzerinde çalışan 3 geliştiricinin düzenlemelerini manuel olarak birleştirmenin maliyetini ve bu birleştirmeyi yanlış almanın ek maliyetini eklemeyi unutmayın. İyi sürüm kontrolü size bunu ücretsiz verir

Daha sonra bunu sürüm kontrolü alma maliyetiyle karşılaştırın (açık kaynak koduna giderseniz) ve kurma - 3 adam gün.

Projede daha sonra bir hatanın erkenden birden fazlasına mal olacağını unutmayın. Herkesin yapabileceği bir hata nedeniyle tüm projeyi yeniden yapmanız gerekiyorsa , yeniden yazma süresinden çok daha pahalıya mal olacak, patronunuza firmasının itibarına mal olabilir.

Kaynağı bir klasörde paylaşırsanız, orada repo'ları da paylaşabilirsiniz. Patron, içinde bir .git klasörü olması dışında bunu bilmiyor.

Asla işinizi düzgün yapmak için izin istememelisiniz - Seth Godin.

Kaynak kontrolünü kurun, nasıl kullanılacağını öğrenin ve patronunuza söylemeyin. Normalde itaatsizlik yönetimini savunmuyorum, ama bu durumda patronunuz aptal oluyor. Git'in öğrenmesi çok uzun süreceğini düşünüyorsanız, svn gibi daha basit bir sürüm kontrol sistemi ile başlayın - git'in yaptığı tüm harika şeyleri yapmaz, ancak temel bir anlayış kazanmak daha da kolaydır.

Bir şey uygulamadan önce ortasına kadar ve ciddi belada olana kadar beklemeyin. Sadece yap ve işi bitir.

Eklemek için düzenlendi: Sorunuzun asıl sorduğu şey 'bir kaynak kontrol sistemi kullanmadan kaynak kontrolünü nasıl yaparım'. Gereksinimi fark ettiniz ve bence buradaki herkes size gerçekten aynı şeyi söylüyor: Kaynak kontrol sistemi olmadan kaynak kontrolü yapmanın mantıklı bir yolu yok.

Sadece özetiniz var, ama patronunuz bir zaman ve para argümanı yapıyor gibi görünüyor ve teknik bir üstünlük argümanı yapıyorsunuz. Zaman ve para tartışması yapmanız gerekiyor. Bir şeyler yapmanın git yolunu öğrenin ve kaydedebileceği bir süre takip edin, daha sonra patronunuza bir günlük sunun "28.03.2011, Joe'nun derlenebilir bir yapıya geri dönmesi için 30 dakika beklemek zorunda kaldı bu yüzden birleştirme yapabilirdik, git birleştirme komutu son taahhüdüne karşı yaklaşık 5 saniye olurdu ".

Bir sunucunun eğitimi ve kurulumu iş engelleri ise, "sunucu" için paylaşılan klasörlerle yalnızca bir ekip üyesinin git'i kullanmasını sağlamak da dahil olmak üzere bir git iş akışı oluşturmak için sonsuz sayıda yol vardır.

İş arkadaşlarınıza, paylaşmak için iyi bir noktada olduğunda kodlarını belirli bir paylaşılan klasöre kopyalamaları talimatını verin. Her biri için bir depo tutabilir ve tüm kaynak kontrol öğelerini kendiniz yapabilirsiniz ve onları eğitmek için yeterince emin olduğunuzda daha fazla ve daha fazla kaynak kontrol sorumluluğunu onlara aktarabilirsiniz. Bu, bunu yapmanın ideal yolundan çok uzaktır, ancak şu an sahip olduğunuzla karşılaştırıldığında, bu bile birleştirme işlemlerinde zaman kazandıracaktır. Patronunuzu daha az takım öğrenme eğrisi ile ikna etmek daha kolaydır ve istediğiniz tüm geri alma ve sürümleme avantajlarını elde edersiniz.

Çok fazla veritabanı çalışması yapmıyorum, ancak bildiklerime göre veritabanı şeması değişikliklerinin birleştirilmesi kaynak denetimi tarafından çok iyi işlenmiyor. Bu birleştirmeler zorsa, tüm veritabanı değişikliklerinin tek bir ağ geçidi denetleyicisinden geçtiği bir işlem değişikliğini dikkate almak isteyebilirsiniz.

Bu delilik. Kendi başınıza çalışsanız bile bir VCS kullanmalısınız. Bir şirkette VCS kullanmamak yasaktır. Sadece yap. Şimdi! Gerçekten ... En başından beri ileri şeylere ihtiyacınız yok. GitHub ve GitLab'ın kullanımı çok basittir, ancak patronunuz ısrar ederse (Windows'ta Git'i kurmak ve kullanmak zor olmasa da) Windows uyumlu bazı barındırma hizmetleri bulabileceğinizden eminim.

Sorduğunuz düşünce imkansız . Birden fazla kişi herhangi bir kaynak denetimi kullanarak olmadan aynı proje üzerinde çalışıyorsanız, hızlı sorunların çok var olacak ve kurşun geliştirici olacağından, sen onlarla uğraşmak zorunda kalacaktır.

Kişisel deneyimlerime göre, kaynak kontrolü olmayan bir proje üzerinde çalışmak iki geliştiriciden imkansız hale geliyor . Üç değil. Dört değil. İki. Muhtemelen bazı durumlarda durumu iki geliştirici ile yönetebilirsiniz : bu geliştiriciler çok organize ve profesyonel ise, iyi etkileşime giriyorlarsa, kolayca değiş tokuş yapabilirlerse (aynı saatte aynı odada bulunurlar, her biri insan hatalarından kaçınabiliyorlarsa (aynı anda başka bir kişi tarafından değiştirilen dosyayı yanlışlıkla değiştirerek, bu kişi tarafından yapılan değişiklikleri siler).

Benim durumumda, iki kişinin sürüm kontrolü olmayan bir projeye katılmaları söz konusu olduğunda, her zaman aşağı yukarı bir felaketti . En iyi durumlarda, bir kişi ikincisine değiştirilmiş dosyalar gönderiyordu ve bu ikincisi değişiklikleri manuel olarak uygulamak için bir fark aracı kullandı. En kötü durumlarda, bir kişi yaptığı değişiklikleri izledi, ardından ikinci kişi kaynak kodunu her değiştirdiğinde yeniden uyguladı. Sonuç: büyük zaman, para ve üretkenlik kaybı.

Şimdi, benim bakış açımdan ve kendi deneyimlerime göre, yaşadığınız soruna üç çözüm görüyorum:

• Kullanımı kolay bir sürüm kontrolü yükleyin . CollabNetSubversion'ı SVN sunucusu olarak yükledim, güvenlikle ilgilenmiyorsanız, kurulumu oldukça hızlı ve kolaydır . Visual Studio kullanıyorsanız, geliştiricilerin kaynak kodunu Visual Studio içinden kolayca güncelleştirmelerini / işlemelerini sağlamak için AnkhSvn yüklenebilir.

• Patronunuzu Joel testinin işini çok iyi bilen bir kişi tarafından yazıldığına ikna edin ve Joel testi bir sürüm kontrolü yapılmasını önerirse bunun arkasında iyi bir neden vardır. Sonuçta, geliştiricilerin kod yazmak için IDE / sözdizimi vurgulama araçlarına ihtiyaç duymadığına da karar verebilir. Windows Not Defteri gayet iyi, değil mi? Ve ayrıca, neden internet erişiminiz var? Tek ihtiyacımız olan Windows 3.1 çalıştıran çok ama çok eski bir bilgisayar.

• Sürüm kontrolü dışında her şeyin mükemmel ve profesyonel olduğuna dair bazı şüphelerim olduğu için bu şirketten çıkın .

Daha büyük bir projede VCS kullanmamak, çünkü bir tane kurmak için zaman harcamak istemiyorsanız yalınayak uzun bir yolculuk yapmak gibidir, çünkü ayakkabı giymek için zaman harcamak istemezsiniz.

Herhangi bir VCS, hiçbir şeye sahip olmaktan daha büyük büyüklük sıralarıdır.

Bir VCS kurmanın kolay ve kolay bir yolu TortoiseSVN'yi elde etmektir (C # kullanıyor gibi göründüğünüz için Windows'da olduğunuzu varsayıyorum). Seçtiğiniz yerel bir klasörde bir havuz oluşturursunuz (bu dosyaya gidin, sağ tıklayın> TortoiseSVN> Burada Depo Oluştur). Bu klasörü ağınızda paylaşın (tercihen her zaman kullanılabilen bir makinede olmalıdır) ve url ile ödeme yapın file://computername/path/to/that/repository. İndirme hariç tutulur, bu kurulumun tamamlanması bir dakikadan fazla sürmez.

Cevabınız patronunuza basit bir bağlantıdır ... bu sayfayı ona postalayın ve profesyonellerden "çıkma" kelimelerinin kaç kez ortaya çıktığını vurgulayın.

"Aptal" kelimesi muhtemelen birçok kez görünse de, patronunuzun olmadığından eminim. Bunun mutlak değeri ona açık değil. Ona sorulması gereken soru, işle ilgili sorunun hangi yanıta neden olacağıdır.

Kaynak kontrolü yalnızca bir projedeki geliştirici sayısının> 0 olduğu durumlarda gereklidir. Birinin sürekli entegrasyon hakkında aynı şeyi söyleyebileceğini düşünmeye başlıyorum ...

(-:

ASP.NET geliştiricileri olarak Subversion, TFS veya Mercurial ile gitmek istediğinizi öneririm - ama dürüst olmak gerekirse, bir şeyle gittiğiniz sürece hangisinin önemli olduğu önemli değildir. Sürüm kontrolü olmadan geliştirme hiçbir anlam ifade etmez - araçlar daha az ya da çok ücretsiz olduğunda ve bunları kullanmak için ek yük en az düzeyde olduğunda.

TFS size çarpıcı bir entegrasyon seviyesi verecektir. DVCS (mercurial veya git) muhtemelen size en fazla esnekliği ve yeteneği verecektir. Bunu yapmamak için iyi bir neden yoktur.

Sıfırdan başlasaydım neredeyse Mercurial'la olurdu.

Sürüm kontrolüne sahip olduktan sonra, bir yapı sunucusuna (TFS, TeamCity) ve oradan sürekli entegrasyona geçebilirsiniz ve bu noktada yumruk kazanmaya başlayabilirsiniz.

Başlangıç ​​noktanıza geri dönmek için:

Proje sorumlusu olacağım (proje yöneticisi ve baş geliştirici) ve her şeyden ben sorumlu olacağım

Böylece sağ, sorumlusu sensin sen sen (siz yapmak için), sürüm kontrolüne ihtiyacımız karar size (yapmanız çünkü) bir yapı sunucu ihtiyacınız olduğuna karar, sen sen ilk günden projenizden konuşlandırılabilir çıkışı olması gerektiğine karar (çünkü bunu her zaman uygulayabiliyorsanız - ve dolayısıyla daha fazla test yapılmasını kolaylaştırırsanız) ve konuşlandırmanın yüksek derecede otomatik olacağı - bunlar projenizin başarısını sağlamak için attığınız adımlardır (bundan sorumlu olduğunuz ...)

Yukarıda belirtildiği gibi, zaten sahip olduğunuz paylaşılan klasöre bir depo koyabilirsiniz. Git, Mercurial veya Bazaar gibi dağıtılmış bir kaynak kontrol sistemi kullanıyorsanız sunucuyu yapılandırmak için zaman harcamanıza gerek yoktur.

Zaten onunla biraz deneyiminiz olduğu için Git'i ya da Visual Studio ile iyi bir entegrasyona sahip olan Mercurial'ı kullanmanızı öneririm.

Gelecekte patronunuz size TFS'ye geçmenizi söyleyecekse, bu hala sürüm kontrolüne sahip olmaktan daha iyidir.

Powerbuilder günlerimde, kaynak kontrolü kullanmadan bir dizi uygulama üzerinde çalışan bir ekibimiz vardı. Oh, Powerbuilder kaynak kontrolü vardı , ama aslında onu kullanarak bir crapshoot - teslim alınmış bir dosya (ve bir LOT çöktü) sırasında PB çöktü, o özel, ikili kaynak kodu dosyası şimdi erişilemez oldu. Dosyada bazı bayraklar belirlendi ve PB'nin başka bir kopyası, dosyayı teslim alan aynı kişi bile yükleyemedi.

Yani yaptığımız şey oldukça basitti. "Hey, Tom, xyz.pbl üzerinde çalışacağım. Bu yüzden değişiklik yapma". Büyük şemada, nadiren herhangi bir sorun yaşadık.

Ekibinizi sürüm kontrolünü benimsemeye ikna edemeyeceğinizi veya patronunuzun alt yarışın rüzgârını aldığını ve takımın durduğunda ısrar ettiğini varsayarsak, alabileceğinizden daha az yaklaşım vardır.

Git veya Mercurial'ı kendi makinenize kurun. Kendi işinizi geliştirin. Ekip çalışmalarını Ötesinde Karşılaştır işlemi ile senkronize ettiğinde, yerel repodaki değişiklikleri yeni bir taahhüt olarak ekleyin. Ekibin senkronizasyonu bir şeyleri bozarsa, yerel repodan önceki bir çalışan sürümü her zaman alabileceksiniz.

Bir DVCS kullanmak, bir sunucuya ve karmaşık kurulum işlemine gerek duyulmamasını sağlar. Mercurial kurulumu ve temel özelliklerle çalışmaya başlaması yaklaşık 30 dakikadan fazla sürmemelidir.

İdeal bir çözüm değildir, ama hiç yoktan iyidir.

Buna ilk tepkim, versiyon kontrolü olmadan zaten ideal bir çalışma sürecine sahip olmanızdı. Hepinizin birleşmeyi yönetmenin iyi bir yolu var gibi görünüyor. Yönetsel açıdan bakıldığında, bu görünüşte iyi bir durumdur. Sürüm kontrolü kullanan ancak geliştirme sürecinin kendisi ile mücadele etmek zorunda olan ekiplerle tanıştım.

Bu yüzden patronunuzu sadece argümanınızı bu sürüm kontrolüne dayandırarak ikna etmek “daha ​​iyi bir süreç” yaratacaktır. Ancak neden sürüm veya kaynak kontrolünü kullanmanız gerektiğine dair çok daha önemli bir argüman var, bu da kolayca paraya hesaplanabilir. Ve bu:

Risk

Mesele, kaynak kontrolünü kullanmanın geliştirme sürecinizi daha iyi hale getirmesi değildir. Kaynak kontrolünüz yoksa ne olacağı daha çok sorundur. Riskler nelerdir?

Birisinin yanlışlıkla koddaki bir işlevi veya tüm dosyayı sildiğini mi söylüyorsunuz? Onarım maliyeti ne kadardır? Umarım birisi bunu kaplar, bu yüzden düzeltme marjinaldir.

Ancak, hiçbir gövdede kayıp dosyanın yedeği yoksa ne olur? Bunu düzeltmek için ne kadar adam saati gerekir? Bu belki günler alabilir ve ortalama insan saatlerinde kolayca hesaplanabilir. Bu şirket için çok mu fazla olurdu? Bu bir şekilde daha hızlı çözülebilir mi?

Evet, bir çeşit kaynak kontrolü ile. Buna karşılık: sürüm kontrolünün ayarlanması ve yedeklenmesi ne kadar zaman alır? Git veya mercurial gibi açık kaynak kodlu olanların çoğu kurulumu fazla zaman almaz. Beyond Compare ile nasıl birleşeceğinizi ve paylaşılan bir klasöre "check-in" yaptığınızı düşünürseniz, insanlara bunu nasıl kullanacaklarını öğretmek o kadar da zor olmaz. Bu bir defalık kurulum maliyetidir. Bu çalışma saatleri risklerinkinden daha az mı olurdu? Bu doğruysa, kaynak denetimini kullanmak bir öncelik olmalıdır.

Bir kaynak sebebinin kaynak kontrolüne sahip olmanın faydalı olduğunu ve risk yönetiminin, patronların çoğunu ikna edecek büyük bir faktör olabileceğini sürece.

Git gibi bir Dağıtılmış Sürüm Kontrol Sistemi kullanın ve referans havuzunu saklamak için paylaşılan klasörler makinenizi kullanın. İşte nedeni:

Her klon bir yedek

Sunucu sabit diski çökerse, herkesin yeni bir sürücüye veya sunucuya dağıtılmaya hazır bir kopyası vardır. Şirketiniz sürüm kontrolü konusunda ciddi olmadığından, yedeklemelerle hemen hemen aynı olabileceğini düşünüyorum.

Ortak referans

Ana dal içeren bir ana depoya sahip olmak, son sözcüğü içeren sürümü bilmenizi sağlar. Bu, "Değişikliklerinizi Franck'ın sürümüne karşı test ettiniz, ancak John'un da var mı? Ve bunları nasıl birleştirdiniz?".

Daha rahat sunun

Müşteri bugün alfa versiyonu istiyor mu? Eh, ustanın yeterince kararlı olup olmadığını test edebilir ve gönderebilirsiniz. Değilse ve düzeltmek için zamanınız yoksa, zamanda geriye gidin ve daha eski ama daha kararlı bir sürüm elde edin. Yalnızca en son sürüme sahipseniz bunu yapamazsınız.

Zamanda geriye gidin ve hatalarınızı düzeltin

Manuel birleştirme işleminizde yalnızca birkaç gün sonra gördüğünüz sorunlar vardı, ancak paylaşılan klasörlerinizin içeriğinin üzerine zaten yazdınız mı? Bir VSC olmadan geçmişiniz yok, bu yüzden yaptığınız hataları kontrol edip düzeltebileceğiniz bir noktaya kolayca geri dönemezsiniz. Kod bir resim gibi değil, bir film gibi: zamanla gelişiyor. Bir filmden resim çıkarabilirsiniz. Bir resimden film çıkaramazsınız.

Hataları daha kolay bulun

Bir hata ortaya çıktı ama gerçekten tanıtıldığı anda fark etmedi, bu yüzden kod "sıcak" iken bunu düzeltemedim. Şimdi hangi değişikliğin getirildiğini gerçekten bilmiyorsunuz, bu yüzden koddaki birkaç farklı yerden gelebilir. Nereye bakacağınızı bulmak saatler sürecek. Git ile, hatanın belirli bir sürümde olup olmadığını söylemek için bir test geliştirebilir ve hatayı git bissectgetiren kesin taahhüdü bulmak için kullanabilirsiniz . Binlerce kod satırı aramak yerine, artık 10 satırın değiştiğini biliyorsunuz ve hatanın tekrar kullanılmadığından emin olmak için testi test paketinizde tutabilirsiniz.

Her geliştirici kendi çalışmasından sorumludur

Takım lideri iseniz ve VCS'niz yoksa, büyük olasılıkla kirli işi, birleştirmeleri yapmanız gerekecektir. Kendi başınıza yaparsanız, muhtemelen tüm değişiklikler hakkında her şeyi bilmiyorsunuz ve hatalar oluşturabilirsiniz. Tam tersine, her zaman kodun birleştirildiği kişilere her zaman birleştirme kodu olduğunda sizinle toplanmalarını isterseniz, o zaman yeni kod üretmek için kullanmayacaklardır.

Bir VCS ile, basit bir iş akışında, geliştirici sadece işine ve bir dış değişiklik kaynağına dikkat etmelidir: ana dal. Ana dalda 1 veya 100 kişi işliyor olabilir, bu aynı. Değişikliklerini zorlayabilmesi için, başkaları tarafından yapılan en son değişikliklere uyarlaması gerekecektir. Kodu zorlamak daha uzun sürebilir, ancak bunun nedeni de zaten zaman alacak bir birleştirme işlemidir.

Aradaki fark, birleştirmenin değişiklikleri yapan, bu kodu en iyi bilen, çünkü yazdığı kişi tarafından yapılmasıdır.

Bu kodu kim yazdı?

Burada bir hata var, ama o kod satırını kim yazdı? Özellikle proje sevral ay sürerse hatırlamak zor. git blamebu satırın kim ve ne zaman yazıldığını size söylerdi, böylece doğru kişiye sorabilirsiniz ve "Bunu yazdığımı hatırlamıyorum" diye bir şey yok.

Proje büyüyor

Müşteri daha fazla özellik istiyor ve çok küçük bir takımsınız, başka bir geliştiriciye ihtiyacınız olacak. Bir VSC olmadan artan birleştirme karmaşıklığını nasıl yönetirsiniz?

Acil değişiklikler

Müşteri aradı ve üretim için kritik bir hata düzeltmesi istedi, ancak şu anda yeni bir özellik üzerinde çalışıyordunuz. Sadece git stashdeğişikliklerinizi bir kenara bırakmak veya yeni bir dalda işlemek ve değişiklikleri zorlamak ve bekleyen işinizi kaybetme korkusu olmadan acil düzeltme üzerinde çalışmaya hazırsınız.

10 dakika önce çalıştı

Yerel olarak bazı değişiklikler yapıyorsunuz ve 10 dakika önce çalışan bir şey çalışmayı bıraktı. Bir VCS olmadan, ya koda ya da en iyi şekilde bakıyorsunuz, referans sürümünün bir kopyasını yapıyorsunuz ve neyi değiştirdiğinizi görmek için farklı oluyorsunuz. Oh bekleyin, çalışmaya başladığımdan beri referans değişti, bu yüzden artık fark edemiyorum. Ve değişikliklerimi dayandırdığım kodun bozulmamış bir kopyasını tutmayı düşünmedim.

Bir VCS ile hemen hemen benzer bir şey yaparsınız git diffve temel aldığınız kodun doğru sürümüne kıyasla değişmiş olursunuz.

Hata ayıklama günlüklerimi saklamalıyım

Yani sen kötü birisin ve loglama kullanmıyor musun? printfO kötü böceğin tüm parçalarını bulana kadar tüm kod tabanınıza serpiştirmek zorunda mıydınız? Şimdi bir tane buldunuz, düzelttiniz, ancak kalan sorunları düzeltmek için özenle hazırlanmış hata ayıklama kodunuzu korumak istiyorsunuz.

Bir VCS olmadan, dosyaları kopyalamanız, hata ayıklama kodunu (bazı düzenleme hataları ekleyebilir) ortadan kaldırmanız, itmeniz ve yedeklediğiniz dosyaları geri koymanız gerekir. Oh, ama yine de bazı hata ayıklama kodları var gibi görünüyor.

Git ile sadece git add --patchve taahhütte koymak istediğiniz birkaç kod satırını seçersiniz ve sadece bunu yapabilirsiniz . Sonra işinizi devam ettirmek ve hala hata ayıklama kodu var. Koda dokunmanız gerekmediği için kopyalama / yapıştırma hatası yok.

Büyük çamur topu

Bir VCS olmadan, insanlar kendi taraflarında çalışır ve size bazen ilgisiz bir sürü değişiklik verir. Kontrol etmek için çok fazla kod olduğunda, bir hata bulmak zor.

Bir VCS, küçük, artımlı değişiklikler yapmanıza ve size bir değişiklik günlüğü vermenize izin verecektir. Changelog önemlidir: insanlar söylemek gerekir neden onlar değişikliği yapıyoruz, değil neyi değişimdir ( Ne sorusu Üyeliğiniz kod değişikliği kendisi tarafından cevaplanır). Bu, örneğin yeni bir özelliğin bazı kodlarını incelediğinizde, alakasız hata düzeltmeleri gibi alakasız karışık değişiklikleri okumak zorunda kalmayacağınız anlamına gelir. Bu, önem verdiğiniz koda odaklanmanıza yardımcı olur.

Size 1'e 1 patates verirseniz ve biri çürürse, hemen bulacaksınız. Şimdi önünüze 100 patates döküp çürük olanı bulmanızı istersem, bu aynı görev değil.

girinti

Umarım iyi bir kodlama stili politikasına sahip olursunuz, aksi takdirde elle birleştirme yaparsanız girinti değişiklikleri sizi çıldırır. Elbette, değişikliklerdeki boşlukları yok sayabilirsiniz (ancak girinti sayıldığında, Python gibi dillerde değil). Ama sonra garip görünen kodu okumak zor olacak.

Sen proje liderisin

Liderseniz, işler yolunda gitmezse suçlanacaksınız demektir. Durumdan rahat kalamazsanız, patronunuz hala doğru iş için doğru aracı kullanmanın buna değdiğini anlayamazsa, en azından tahmin edilebilir bir başarısızlığın lideri olmayı reddederim.

Dropbox kullanın, otomatik sürüm geçmişine sahiptir. Dropbox klasörünü birden fazla kullanıcı arasında paylaşabilirsiniz.

Düzenle

Ayrıca TortoiseSVN-istemcisini indirebilir ve ağ sürücüsünde "yerel depo" oluşturabilirsiniz. Daha sonra insanlar kaynak kodu ağ klasörü konumuna göre kontrol edebilirler.