Profesyonel uygulama geliştiricileri GIT ve Subversion gibi sürüm kontrol sistemlerini nasıl kullanır?

Yeni başlayan bir geliştiriciyim ve en başından beri projelerinin ihtiyaçlarını karşılamak için GIT ve Subversion gibi profesyonel kullanım araçlarını (bu araçlar hakkında çok iyi bir anlayışım yok) nasıl merak ediyorum. Eğer kullanırlarsa, böyle bir şeyi nasıl kurarım?

Uygulamalarım o kadar büyük değil ve henüz bir takımda çalışmıyorum, bana çok yardımcı olacaklar mı?

Bu sitede araçların nasıl kullanılacağı hakkında sorular var, ancak başlangıç ​​desteğine ihtiyacım var.

Kaynak kontrolü her yerde bulunur - hatta kullanmıyorsanız kendinize profesyonel bir geliştirici diyemeyeceğinizi söyleyebiliriz. Yalnız gelişirken bile, kaynak kontrolü hala birkaç fayda sağlar. Sonunda hem bir tarih hem de kapsamlı bir geri alma yolu sağlar. Ayrıca, yeni sürümü beğenmediyseniz, her zaman daha önce sahip olduğunuza geri dönebileceğinizi bilerek, çok daha fazla deneme yapmanızı sağlar.

Bununla birlikte, Subversion veya Git gibi bir kaynak kontrol sistemi içinde bile iş akışları, takımdan takıma büyük ölçüde değişir. Başlamak için en iyi yer muhtemelen bir kaynak kontrol sistemi seçmek ve standart iş akışlarına aşina olmaktır (iş hayatınızı profesyonel yaşamınız boyunca değiştirmek zorunda kalacağınız kafanızda tutmak).

Başlamak için Git'i tavsiye ederim. Ben bir Git hayranıyım, ancak daha özellikle Git'i seçmek, sunucusuz çalışarak başlamanıza ve sadece sizin için anlamlı olduğunda bir sunucu kurmanıza izin verir. Subversion, bir sunucu gerektirir ve bir sunucu kurmak son derece zor olmasa da, bu tür şeylere aşina olmadığınızda göz korkutucu olur.

Genel olarak kaynak kontrolü için bazı iyi kurallara iyi bir genel bakış: http://scottonwriting.net/sowblog/archive/2008/11/13/163320.aspx

Kendiniz çalışırken, iyi bir iş akışına ihtiyacınız yoktur. Erken, sık sık. Sürümleri kullanıma sunmaya başlarsanız, sürümlerinizi etiketleyin. Deneyler veya uzun ıraksak çalışmalar için dallar oluşturun (Git, Subversion'dan daha ucuz ve daha basit hale getirir).

Çok basit bir düzeyde kaynak kontrol sistemleri (SVN, Git vb.) Dosyaların değişiklik geçmişini korumanıza izin verir. Bu, kodunuzun zaman içinde nasıl değiştiğini görmenizi ve istemeyebileceğiniz değişiklikleri geri almanızı sağlar (örneğin değişiklik beklendiği gibi çalışmaz, kodu daha önce bilinen bir duruma geri döndürebilirsiniz). Bu, kendi başınıza geliştirmenin bile kullanmaya başladığınızda sizin için çok değerli olacağı bir şeydir.

Bir takımdaki diğer kişilerle çalışırken, birden çok kişi aynı dosyayı değiştirebildiğinden ve değişiklikler çakışmazsa (örneğin 2 kişi dosyanın farklı bölümlerini değiştirdiğinde) faydalar daha da artar otomatik olarak. Herhangi bir çelişki varsa, değişikliklerinizi meslektaşlarınızın yanında görebilir ve onlarla değişiklikleri nasıl birleştireceğinizi tartışabilirsiniz.

Ayrıca, kodun bir sürümünü yayınlarken kod tabanının anlık görüntülerini (genellikle etiket olarak adlandırılır) oluşturabilirsiniz, böylece ana kaynak henüz yayınlanmamış yeni özelliklerle taşınsa bile sorunları kolayca hata ayıklayabilirsiniz.

İşte birkaç yararlı kaynak:

Subversion ve Tortoise SVN'yi Visual Studio ve .NET ile kurma ve çalıştırma

Subversion ile Sürüm Kontrolü

Yeni Başlayanlar İçin Eğiticiler

Çok temel bir seviyeden başlamanıza yardımcı olabilecek harika öğreticiler (video ve metin) vardır. Git'in konuyu tanıtmak için harika bir yaklaşımı var gibi görünüyor , yeni başlayanlar ilk önce size nedenini anlatan ve tuş komutlarının adlarını ve işlevlerini hatırlamanıza yardımcı olmak için tekrarlama, tanım ve grafik kullanan nazik bir şekilde .

SVN

SVN'nin CVS daha iyi yapılması amaçlanmıştır. CVS (eşzamanlı Sürüm Sistemi) bir seferde bir dosya üzerinde çalıştı, SVN genellikle bir seferde bir dizin veya dizin ağacı üzerinde çalıştı. SVN (ve CVS veya diğer sistemler) iş yerinde kullanıyorsanız önemli olabilir, ancak benim düşüncem, geç bir modeli tercih edeceğiniz gibi, her birkaç yılda bir kaynak kontrolü yapmak için gerekenleri anlamamızı önemli ölçüde geliştirmemizdir. bilgisayar, geç bir model kaynak kontrol aracı tercih etmelisiniz. Sistemlerin değiştirilmesi büyük bir yatırımdır ve kod geçmişi kaybolabilir, ancak birçok sistem için kodunuzun yanı sıra geçmişin ve emekliye ayrılan sistemin oluşturduğu diğer eserleri taşımanıza izin veren dönüştürücüler vardır.

Profesyonel Kaynak Kontrolü Profesyonel İhtiyaçları Karşılar

"GIT ve Subversion gibi profesyonel araçlar projelerinin ihtiyaçlarını karşılamak için nasıl kullanıyor?" "Takımlar hala mümkün olduğunca çabuk çalışırken birbirlerinin yoluna girmeden nasıl birlikte çalışırlar?" sorusuyla yakından ilgilidir.

Bazı geliştiriciler, diğer geliştiricilerin kullanacağı kod üreten kodlarla ve yenilikçiliğe karşı farklı istikrar düzeylerine ihtiyaç duyan çeşitli paydaşlarla kod sık sık değişmektedir. Kaynak kontrol sistemleri, ekip tarafından kullanılmak üzere kodu depolayarak, her değişikliği zamanla değişen sürümlerle bağlamda tutarak ve genellikle değişiklik gruplarını diğer değişiklik gruplarından izole etmeye hizmet eden kodun kontrollü kopyaları olan dallarla tutar.

Bir şeyleri tekrar bir araya getirmek, birçok ekip üyesinin çalışmalarını birleştirmek, SVN ve daha eski sistemlerde merkezi ve zor bir iştir. Git kullanan ekipler için birleştirme, birkaç uzman yerine tüm ekibin etkisi için daha basit ve daha erişilebilir hale gelir. SVN'de dallanma kişisel bir mesele olabilir, ancak birleştirme genellikle takım üzerinde acı verici etkilere sahipti ve kodun ana hatta geri hareketi, izin alma, kırılmayı önleme ve görevin gerektirdiği çaba düzeyi açısından acı verici olabilir. .

Yerleşik bir kaynak kontrol havuzundan profesyoneller, kök nedenlerine ilişkin sorunları teşhis etmek gibi diğer ihtiyaçları karşılayabilirler. Eskiden çalışmakta olan kodun sürümleri ve geçerli sürümde oluşan yeni bulunan sorunlar varsa, sorun ortaya çıktığında kesin olarak belirlemek için geçmişte ileri ve geri adım atmak mümkündür. SVN'de bu özellik olgunlaşmamış, ancak Git'te son çalışan / ilk başarısız sürümü arama git bisect adı verilen bir komut tarafından destekleniyor. Sorun, iki sürüm arasındaki kaynak değişikliklerinden birinin, tüm kod tabanının aranmasından potansiyel olarak çok daha kolay bir tanıdan kaynaklanacaktır.

Rahatsız ettiğim için üzgünüm, bunun kaynak kontrolünü kullanma yolunda size yardımcı olacağını umuyoruz.

Ekibim, evde yetiştirilen bir ekip versiyonu kontrol sistemi kullanıyor. (Ne yazık ki, Git henüz IBM i "yerel" kaynak dosyalarında çalışmıyor gibi görünüyor) Ama kişisel olarak, bu sistemden kaynak aldıktan sonra, proje tamamlanana ve tekrar kontrol edene kadar geliştirme sırasında Git'i kullanıyorum. ekibi VCS.

Oylamada dedikleri gibi ... erken, sık sık taahhütte bulunun. Yeni özellikler üzerinde çalışırken, taahhüt ediyorum. Derlemeler arasında işlem yapıyorum ve derleme hatalarını düzeltmeye yönelik her girişimde, test ve hata ayıklama sırasında her değişiklik yaptığımda. Bu, bir tema üzerinde çeşitli varyasyonları denemeyi kolaylaştırır ve gerektiğinde, özellikle de birkaç dosya arasında bir değişiklik koordine edildiğinde, kolayca geri çekilebilir.

Git gelişime yaklaşım tarzımı geliştirdi.