Neden sürüm kontrolünü kullanmalıyım? [kapalı]

Yazarın bunu söylediği bir blog okuyordum

"Kod, bir sürüm kontrol sistemine eklenmedikçe mevcut değildir. Yaptığınız her şey için sürüm kontrolünü kullanın. Herhangi bir sürüm kontrolü, SVN, Git, hatta CVS, ustalaşın ve kullanın."

Hiçbir zaman herhangi bir sürüm kontrolü kullanmadım ve o kadar da harika bulmuyorum. Google'da araştırdım ve daha önce baktım, ancak lütfen istersen çocukların şartlarına koymam gerekiyor.

Şu anda anladığım kadarıyla, SVN gibi şeyler, bir grup kullanıcı veya diğer geliştiricilerin aynı koda erişebilmeleri için kodunuzu çevrimiçi depolamak içindir. Bazı kodu güncelledikten sonra, yeni sürümü gönderebilirsiniz ve SVN, güncellediğiniz yeni kodların yanı sıra eski kodun kopyalarını da saklayacaktır.

Temel fikir bu mu yoksa tamamen yanlış mı anlıyorum?

Eğer haklıysam, eğer:

• Kod üzerinde çalışan başkalarına sahip olmayın.
• Başkalarının koda sahip olmasına izin vermeyi planlamayın.

Sen hiç:

• Kodda bir değişiklik yaptınız, bunun bir hata olduğunu fark ettiniz ve geri dönmek mi istiyorsunuz?
• Kodu mu kaybettiniz veya çok eski bir yedeğiniz mi var?
• Bir ürünün birden çok sürümünü bulundurmanız mı gerekiyor?
• Kodunuzun iki (veya daha fazla) sürümü arasındaki farkı görmek ister misiniz?
• Belirli bir değişikliğin bir kod parçasını kırdığını veya düzelttiğini kanıtlamak mı istiyorsunuz?
• Bazı kodların geçmişini gözden geçirmek mi istiyorsunuz?
• Başka birinin kodunda değişiklik mi göndermek istiyorsunuz?
• Kodunuzu paylaşmak veya başkalarının kodunuz üzerinde çalışmasına izin vermek mi istiyorsunuz?
• Ne kadar işin nerede, ne zaman ve kim tarafından yapıldığını görmek istediniz mi?
• Çalışma koduna müdahale etmeden yeni bir özelliği denemek mi istiyorsunuz?

Bu gibi durumlarda ve şüphesiz diğerlerinde, bir sürüm kontrol sistemi hayatınızı kolaylaştırmalıdır.

Bir arkadaşı yanlış aktarmak: Medeni bir çağ için medeni bir araç.

Yalnız çalışsanız bile kaynak kontrolünden yararlanabilirsiniz. Diğerlerinin yanı sıra, şu nedenlerle:

• Hiçbir şey kaybetmezsin. Kodu bir daha asla yorumlamadım. Ben basitçe siliyorum. Ekranımı karıştırmaz ve kaybolmaz. Eski bir kaydı kontrol ederek onu kurtarabilirim.

• İstediğiniz zaman deneyebilirsiniz. Sorunu çözmezse, geri alın.

• Hataların ne zaman ve nerede ortaya çıktığını öğrenmek için kodun önceki sürümlerine bakabilirsiniz. git bisectbu bakımdan harika.

• Dallanma ve birleştirme gibi daha "gelişmiş" özellikler, birden çok paralel geliştirme çizgisine sahip olmanızı sağlar. Parazit olmadan aynı anda iki özellikte çalışabilir ve çok fazla güçlük çekmeden ileri geri geçiş yapabilirsiniz.

• "Nelerin değiştiğini" görebilirsiniz. Bu basit gelebilir, ancak bu kendimi çok kontrol ederken bulduğum bir şey. Tek kişilik iş akışıma çok sık başlarım: dün ne yaptım?

Sadece devam et ve dene. Temel özelliklerle yavaşça başlayın ve ilerledikçe başkalarını da öğrenin. Kısa süre içinde, hiçbir VCS'nin olmadığı "karanlık çağlara" geri dönmek istemeyeceğinizi göreceksiniz.

Yerel bir VCS istiyorsanız, kendi subversion sunucunuzu kurabilirsiniz (geçmişte yaptığım şey), ancak bugün kullanmanızı tavsiye ederim git. Çok daha basit. Sadece cdkod dizininize gidin ve çalıştırın:

git init

Kulübe hoşgeldin.

Sürüm kontrolü, yalnızca tek bir geliştirici olarak kullanıyor olsanız bile, kesinlikle gerekli olduğunu söyleyebileceğim nadir bir araçtır. Bazı insanlar bunun yaşayıp ölmek için bir araç olduğunu söylüyor, bu iddiaya katılıyorum.

Bilmeseniz bile, muhtemelen şu anda sürüm kontrolünü kullanıyorsunuz. "XXX Php Kodu (Aralık)" veya "XXX.php.bak.2" yazan klasörleriniz var mı? Bunlar şunlardır zaten sürüm kontrolü formlar. İyi bir sürüm kontrol sistemi bunu sizin için otomatik olarak halledecektir. Zaman içinde herhangi bir noktaya geri dönebileceksiniz (verileri kontrol ettirdiğiniz) ve bu verilerin tam bir kopyasını görebileceksiniz.

Ayrıca, yıkım gibi bir sistemi benimserseniz ve uzak bir depo kullanırsanız (sahip olduğunuz bir sunucuda olduğu gibi), tüm kodunuzu saklayabileceğiniz bir yeriniz olur. Kodunuzun bir kopyasına başka bir yerde mi ihtiyacınız var? Sorun değil, sadece kontrol edin. Evde sabit sürücü çökmesi mi? Sorun değil (en azından kaynak kodunuzla).

Şu anda sürüm kontrolünü kullanmasanız bile, muhtemelen kariyerinizin bir noktasında onu kullanacaksınız ve şimdi ilkelerle daha rahat olmaktan yararlanabilirsiniz.

Yalnız çalışırken bile, bu hiç oldu mu? Uygulamanızı çalıştırıyorsunuz ve bir şey çalışmıyor ve "dün işe yaradı ve yemin ederim o sınıfa / yönteme dokunmadım" diyorsunuz. Düzenli olarak kod kontrol ediyorsanız, hızlı sürüm farkı, son gün tam olarak nelerin değiştiğini gösterir.

İşte tek başınıza çalışsanız bile kaynak kontrolünün kullanışlılığını gösterebilecek bir senaryo.

Müşteriniz sizden web sitesinde iddialı bir değişiklik yapmanızı istiyor. Birkaç hafta sürecektir ve birçok sayfada düzenlemeler içerir. Çalışmaya başla.

Müşteri arayıp sitede acil ancak daha küçük bir değişiklik yapmak için yaptığınız şeyi bırakmanızı söylediğinde bu görevi% 50 tamamlamış olursunuz. Daha büyük görevle işiniz bitmedi, bu yüzden canlı yayına hazır değil ve müşteri daha küçük bir değişikliği bekleyemez. Ama aynı zamanda daha büyük bir değişiklik için küçük değişikliğin işinizle birleştirilmesini de istiyor.

Belki de web sitesinin bir kopyasını içeren ayrı bir klasörde büyük görev üzerinde çalışıyorsunuzdur. Şimdi, küçük değişikliğin hızlı bir şekilde uygulanabilecek şekilde nasıl yapılacağını bulmanız gerekiyor. Öfkeli çalışıyorsun ve hallediyorsun. Müşteri, daha fazla ayrıntılandırma talebiyle geri arar. Bunu da yap ve yerleştir. Herşey iyi.

Şimdi, onu büyük bir değişiklik için devam eden çalışmayla birleştirmeniz gerekiyor. Acil iş için neyi değiştirdiniz? Not tutmak için çok hızlı çalışıyordun. Ve artık iki dizini kolayca ayırt edemezsiniz, çünkü her ikisi de başladığınız temel çizgiye göre değişir.

Yukarıdaki senaryo, tek başınıza çalışsanız bile kaynak kontrolünün harika bir araç olabileceğini göstermektedir.

• Uzun vadeli görevler üzerinde çalışmak için şubeleri kullanabilir ve ardından tamamlandığında şubeyi ana hatta birleştirebilirsiniz.
• Nelerin farklı olduğunu görmek için tüm dosya kümelerini diğer dallarla veya geçmiş revizyonlarla karşılaştırabilirsiniz.
• Zaman içindeki çalışmaları takip edebilirsiniz (bu arada raporlama ve faturalandırma için harikadır).
• Herhangi bir dosyanın herhangi bir revizyonunu tarihe veya tanımladığınız bir kilometre taşına göre kurtarabilirsiniz.

Yalnız çalışma için Subversion veya Git önerilir. Herkes birini veya diğerini tercih etmekte özgürdür, ancak her ikisi de herhangi bir sürüm kontrolü kullanmamaktan daha iyidir. İyi kitaplar Mike Mason'ın " Subversion kullanarak Pragmatik Sürüm Kontrolü, 2. Baskı " veya Travis Swicegood tarafından " Git Kullanarak Pragmatik Sürüm Kontrolü " dir.

Orijinal yazar: Bill Karwin

Tek bir geliştirici kaynak kontrolü olarak bile büyük bir fayda sağlar. Kodunuzun geçmişini saklamanıza ve istediğiniz zaman yazılımınızın önceki sürümlerine geri dönmenize olanak tanır. Bu, korkusuzca deneme esnekliği sağlar, çünkü her zaman kaynak kodunuzun çalışan başka bir sürümüne geri yükleyebilirsiniz.

İlk kod satırınıza kadar dev bir "geri al" düğmesine sahip olmak gibidir.

Sürüm kontrolünü kullanmaya başladıktan sonra yaşamak neredeyse imkansızdır. Birden fazla geliştiricinin aynı kod tabanı üzerinde çalışması kaçınılmazdır ... ama aynı zamanda tek bir geliştirici için oldukça yararlıdır.

Kodunuzdaki değişiklikleri izler ve önceki sürümlere geri dönmenizi sağlar. Herhangi bir şey bozulursa değişikliklerinizi geri alabileceğiniz bilgisiyle denemeler yapmaktan sizi özgür kılar.

Güvenlik (kodunuzun yedeğini alma anlamında) ve kodunuzun sürümlerini (değişikliklerinizi sık sık yapma alışkanlığı edindiğinizi varsayarak) elde edersiniz. Kimse sizinle kod üzerinde çalışmasa bile ikisi de çok iyi şeyler ...

Sürüm kontrolü, tek başınıza çalışıyor olsanız bile önceki sürümleri kontrol etmek için harikadır. Örneğin, yanlışlıkla bir kodu veya bir dosyayı silerseniz, onu geri alabilirsiniz; veya yeni bir hatanın neden ortaya çıktığını görmek için önceki sürümleri karşılaştırabilirsiniz. Birden fazla yerde çalışan bir kişi olmanız da iyidir.

Benim kişisel favorim git.

Koda dokunacak tek kişi siz olsanız bile, sürüm kontrolünü kullanmanın birçok nedeni vardır.

• Destek olmak - ya sabit sürücünüz çökerse? Herhangi bir yerde bir kopyanız var mı?
• Revizyon Geçmişi - Şu anda farklı klasörlerde kod kopyalarını tutuyor musunuz? Sürüm kontrolü, zaman içindeki değişikliklerinizi takip etme ve araçları kullanarak farklı revizyonları, birleştirme, değişiklikleri geri alma vb.
• Dallar - bazı değişiklikleri test etme, ne yaptığınızı takip etme ve ardından bunu devam ettirip ana projede birleştirmek veya sadece çöpe atmak isteyip istemediğinize karar verme yeteneği.

Kodunuzu sürüm kontrolü altında tutarsanız, hangi dosyaları değiştirdiğinizi (veya temele eklemeyi unuttuğunuzu) görmenizi gerçekten kolaylaştırır.

Başka hiç kimsenin açıkça bahsetmemiş gibi göründüğü bir şey de sürümlerin etiketlenmesi veya etiketlenmesidir. Yazılımınızın 1. sürümünü kullanan bir istemciniz varsa ve sürüm 2 üzerinde çalışmakla meşgulseniz, istemci bir hata bildirdiğinde ve 1.1 sürümünü oluşturmanız gerektiğinde ne yaparsınız?

Bir kaynak kontrol sistemi, yaptığınız her sürümü etiketlemenize izin verir, böylece daha sonra geri dönebilir, düzeltmeyi yapabilir (ve bu düzeltmeyi yeni sürüm 2 koduyla birleştirebilirsiniz) ve yanlışlıkla bir şeyi teslim edebileceğinizden endişelenmeden yeni bir sürüm oluşturabilirsiniz. hazır değil.

Kaynak kontrolü, modern yazılım geliştirmenin temel bir parçasıdır. Kullanmıyorsanız (kişisel projeler için bile ne kadar çok deneyime sahipseniz o kadar iyi olur) yanlış bir şeyler yapıyorsunuz demektir.

Genellikle bir iş için mülakat yaparken sorduğum ilk sorulardan biri "Kaynak kontrolü için ne kullanıyorsun?" Şimdiye kadar sadece bir yer "Hiçbir şey" dedi, ancak "Çok yakında şimdi ..."

Diğer geliştiricilerin katılıp katılmaması, bir sürüm kontrol sistemi ihtiyacına tamamen ortogonaldir.

Tek geliştirici siz olabilirsiniz ancak yine de şunlardan yararlanacaksınız:

• tüm değişikliklerinizin geçmiş izi
• bu tarihe geri ve ileri gitme yeteneği
• kaynakla deney yapma yeteneği ve hala çalışan bir sürüme sahipken (dallanma)
• bir yedek kopya (özellikle kaynak kontrol sunucusu olarak farklı bir makine kullanıyorsanız ve hatta bu makine düzenli olarak yedekleniyorsa daha da fazlası)

Şimdi, aynı kod tabanı sürüm kontrolü üzerinde gelişen bir grubunuz varsa, hala daha gerekli

• insanlar aynı dosyayı aynı anda düzenleyebilir (belirli sisteme bağlı olarak, ancak aklı başında olanların çoğu bunu yapmanıza izin verir)
• kimin ne zaman koda ne yaptığını anlayabilirsiniz

Daha fazla insan dahil olduğunda, geliştirme tarzına bağlı olarak hangi sürüm kontrol aracını seçeceğiniz daha önemlidir.

Aynı zamanda eski dosyanın yedeklenmesi ile ilgili, bu yüzden ona "Subversion" deniyor. Böylece, çalışmanızın geri dönebileceğiniz (geri alabileceğiniz) ve farklı uygulanmasını (dallanma) yönetebileceğiniz birden çok sürümünü yönetebilirsiniz.

Programınızın çalışan bir sürümüne sahip olduğunuzu fark edebilirsiniz.

Belirli bir süre içinde birkaç yeni özellik eklemeye karar verirsiniz ve bunu yayınlarsınız.

Dokunmadığınızı düşündüğünüz bazı kodları etkileyen hata raporları almaya başlarsınız.

Örneğin, SVN'yi kullanarak, eski bir sürüme geri dönebilir ve yeni hatanın olup olmadığını kontrol edebilirsiniz. Hatayı ortaya çıkaran bir sürüm bulduğunuzda, çalışan sürümü çalışmayanla karşılaştırabileceğiniz ve neyin değiştiğini görebileceğiniz için düzeltmek daha kolay olacaktır, ardından aramayı daraltacaktır.

Tek geliştirici siz olsanız bile, kaynak kontrolünün birçok kullanımı vardır.

Görünüşe göre biraz daha hafif bir şey arıyorsunuz. Mercurial'e göz atın ( harika referans kitabı ) . Kaynak koddan kişisel yazışmalara kadar her şey için kullanıyorum.

Bazı faydalar:

• Dev Geri Al düğmesi, kodun gerçekten çalıştığı geçen haftanın o halcyon günlerini iade edebilmeniz için
• Atma kodu. Bir şeyi yapmanın en iyi yolunun bu olduğundan emin değil misiniz? Bir dal yapın ve deney yapın. Mercurial gibi bir DVCS kullanıyorsanız, sizden başka kimsenin bunu bilmesine gerek yoktur.
• Senkronize geliştirme. 4 farklı bilgisayarda geliştiriyorum. Akımı korumak için aralarında itip çekiyorum, bu yüzden hangisinde olursam olayım en yeni sürümlere sahibim.

Henüz programınızın eski bir sürümüne ihtiyaç duyduğunuz bir durumda bulunmamış olsanız bile, bir kaynak kontrolüne sahip olmak size büyük değişiklikler yapmak için daha fazla güven verir.

Kaynak kontrolünü kullandıktan sonra kendimi daha agresif yeniden düzenleme yaparken buldum çünkü çalışan bir sürümün kolayca geri yüklenebileceğini her zaman biliyordum.

Ayrıca son zamanlarda sürüm kontrolü ile ilgilenmeye başladım. Sürüm kontrol sistemlerinde, kodunuz için bir havuz kavramına sahipsiniz . Çok sayıda yeni kabuk komutu, bu depo ile etkileşime girebilmeniz için çok hızlı bir şekilde öğrenilir.

Eğer bir dosyaya kodunuzu kaydettikten sonra, daha sonra olabilir işlemek projenizin deposuna bu. Kodunuzu geliştirirken ve değişikliklerinizi gerçekleştirirken, depo bir dizi revizyon geliştirir . Sen tarafından Bunlardan herhangi birini erişebilir kontrolBir revizyonu . Yalnız çalışıyorsanız, kod dosyalarınızı kaybetmediğiniz veya farklı bir makinede çalışmak istemediğiniz sürece çok fazla kontrol yapmanız olası değildir. Bu durumlarda, genellikle tüm dosyaların en son revizyonuna bakarsınız.

Kendi adıma, bir şeyi yeniden düzenlemeye karar verdiğimde artık 'project_old' adlı dosya veya klasörleri tutmuyorum. Yaptığım tüm değişiklikler aşamalı olarak saklanıyor ve bir bütün olarak çalışan bir projeye her zaman geri adım atabileceğim. Şimdi dağıtmak için nadiren FTP kullanıyorum çünkü kodumu sadece ssh aracılığıyla kontrol ediyorum. Yalnızca değiştirdiğim dosyalar indirildi ve sunucuda yeniden yüklemem gerekirse terminal zaten orada.

GIT hakkındaki bu konuşmayı gerçekten öğretici buldum; http://www.youtube.com/watch?v=4XpnKHJAok8

Linus Torvalds'ın bir sürüm kontrol sistemini diğerine göre kullanmak için tartıştığı bir google konuşması. Bunu yaparken, kavramları kullanarak nasıl çalıştıklarını açıklıyor ve ardından bunları uygulamanın farklı yollarını karşılaştırıyor.

Tüm değişikliklerinizin bir geçmişine sahip olmak için, kendi başınıza çalışıyor olsanız bile, muhtemelen yıkım gibi bir şey isteyeceksiniz. Neden bir değişiklik yaptığınızı hatırlamak için bir zamanlar bir kod parçasının neye benzediğini görmek isteyebilirsiniz.

Kaynak kontrolüne sahip olmak, sık sık kontrol ettiğinizde de yararlıdır. Sık sık kontrol ederseniz, her zaman sık sık geri dönme durumunda olacaksınız. Çoğu zaman, bir sorunu çözmek için tek bir yoldan gitmeye başlayabilir ve sonra gidilecek yanlış yol olduğunu fark edebilirsiniz. Çoğu zaman yanlış yolda havlamaya devam edebilir ve sonunda korkunç bir çözüm üretebilirsiniz - sadece tüm çalışmanızı kaybetmek istemediğiniz için. Sık sık kontrol ederek, "mutluluğun" son noktası çok uzakta değildir, bu nedenle yanlış yola girseniz bile her zaman geri dönüp tekrar deneyebilir ve daha zarif ve basit bir çözüm oluşturabilirsiniz. Bu her zaman iyi bir şeydir, böylece gelecekte yazdıklarınızı anlayabilir ve sürdürebilirsiniz.

Bu, projenin büyüklüğüne ve projenin bölümleri hakkında fikrinizi ne sıklıkla değiştirdiğinize bağlıdır. Doğrusal bir şekilde bir şeyler yaptığınız küçük projeler için, sürüm kontrolü muhtemelen pek yardımcı olmayacaktır (ancak sürüm kontrolü olmayan bir dosyayı yanlışlıkla silerseniz veya bozarsanız, ağlarsınız).

Ancak birkaç hafta önce kendi başına büyük bir hobi projesi yazan bir arkadaşla tanıştım. Kodunun "X1", "X2", "test", "daha hızlı" ve benzeri soneklerle on veya yirmi kopyasına sahipti.

Eğer kod ikiden fazla kopya yaptıysanız, sen lüzum sürüm kontrolü . İyi bir sürüm kontrol sistemi, bir süre önce yaptığınız bir değişikliği, bu değişikliği yaptıktan sonra yaptığınız şeyleri geri almadan geri almanıza olanak tanır. Belirli değişikliklerin ne zaman yapıldığını görmenizi sağlar. Kodunuzu iki "yola" ayırmanıza olanak tanır (örn. Biri yeni bir fikri test etmek için, diğeri testi bitirene kadar "denenmiş ve güvenilen" kodunuzu güvende tutmak için) ve ardından bunları tekrar birleştirmenizi sağlar.

2019'dur. Bu görece geç tarihte Git'in kullanımına itirazlarla karşılaşıyorum; itirazlar burada bazı artışlar görüyorum. Bu tartışma, yalnızca adlandırılmış yedek kopyalar yapmaktan ziyade kaynak kontrolünü kullanmanın zorunluluğunu büyük ölçüde açıklığa kavuşturmuştur. Önemli bir nokta, tek geliştirici projemiz olduğunda bile kaynak kontrolü kullanımıdır. Kimse mükemmel değildir. Hatalar yaparsın. Son derece iyi ve akıllıysanız, daha karmaşık uygulamalar geliştireceksiniz; ama yine de bazı hatalar yapacaksın ve bu sorunu çözecek. Tanrım, pete! Asla Linux kullanmam ama hepimizin Linus Torvalds'ın harika teknik zekasına saygı duyduğumuzu düşünüyorum. Kaynak kontrolünün önemini anladı ve Git'in başlangıcına önemli katkılarda bulundu. Bu, burada verilen tüm nedenlerin özetidir. Torvalds bunu anlıyor: kaynak kontrolü çok önemli: kaynak kontrolünü kullanın. Bu uzun süredir devam eden konu hakkında yorum yapan herkese teşekkürler.