Kaynak kontrol sistemimizden ekibimin temel bir yeterliliğinden daha fazla olmasını beklemeli miyim?

Şirketim Subversion'dan Git'e üç ay önce geçti. Geçiş öncesinde haftalarca önceden haberimiz vardı. Git'i daha önce (ya da başka herhangi bir DVCS'den önce) hiç kullanmadığımdan, Pro Git'i okudum ve biraz zaman harcadım, kendi depolarımı toplayıp etrafta dolaştım, böylece değiştirdiğimizde minimum acı ile çalışmaya devam edebilecektim. Şimdi varsayılan olarak 'Git adam' değilim.

Birkaç istisna dışında, takımımın çoğu Git'in nasıl çalıştığını bilmiyor. Örneğin, dalları hala kaynak kodun tam kopyaları olarak görüyorlar ve hatta repoyu birden fazla klasöre (dal başına bir tane) klonlayacak kadar ileri gidiyorlar. Genellikle Git'e korkutucu bir kara kutu olarak bakarlar.

Günlük çalışmamızdaki kaynak kontrolün temel niteliği göz önüne alındığında (Git'in bize verdiği saçma güç miktarından bahsetmemeye gerek yok), onunla belirli bir yeterlilik seviyesine ulaşamayan herhangi bir devin bir sorumluluk olduğu kanaatindeyim .

Ekibimin en azından Git'in içeride nasıl çalıştığını ve en temel çekme / birleştirme / basma işlemlerinin ötesinde nasıl kullanılacağını anlamalarını beklemeli miyim? Yoksa sadece hiçbir şeyden bir şey mi çıkarıyorum?

Profesyonellik, doğal olarak, geliştiricinin, yeni ve yabancı olmasına rağmen (hatta istenmeyen) bile, ekibinin standart araçlarına aşina olmasını zorunlu kılar.

Ancak, yazınızdaki birkaç şey beni durdurur.

Geçiş öncesinde haftalarca önceden haberimiz vardı.

Haftalar? Kaynak kontrolünü değiştirmek çok önemlidir. Böyle bir değişikliğe yol açan aylarca haber verilmiş olmalı .

Birkaç istisna dışında, takımımın çoğu Git'in nasıl çalıştığını bilmiyor.

Yani, şirketiniz o zaman çok az kişi, ne zaman anladıysa, bir kaynak kontrol sistemine geçti?

Başka bir bağlam olmadığı sürece, tüm hareketin düşünülmediği sanılıyor (hareket, seçim değil - ben büyük bir git hayranıyım).

Git'i çalıştığım yerle tanıştırıyoruz ve doğal olarak direniş oldu. Yeni bir proje içindi, şimdi iki depo tutuyoruz.

Sorunun bir kısmı, kullandıkları kişi kendileri için çalıştığında, insanların farklı bir SCM'ye geçiş yapmanın faydalarını görmeyecek olmasıdır. Projelerimizdeki kullanım örneklerini ve Git'in nasıl kolaylaştıracağını göstereceğimiz birkaç saatlik bir oturum için ekibimizle birlikte oturduğumuzda yardımcı oldu . Örneğin, bize yardımcı olan şeyler:

• Deneyi teşvik etmek için yerel şubeler
• Kolayca hataları izlemek için Git bisect
• sık sık başkalarını rahatsız etmeden taahhütler
• Dallar arasında hızlı geçiş

Bunların her biri, önceki SCM'mizle karşılaştığımız bir sorunu çözdü ve böylece insanlar Git'i daha fazla takdir edebildi.

Diğer bir şey ise, insanların gitmelerini ve bunun hakkında kitaplar okumasını bekleyemeyeceğinizdir, çünkü çok az şey olacaktır. Belki işlerini bitirmeleri, başka sorumlulukları veya çeşitli nedenleri olması gerekir.

Bu nedenle, 'Git uzmanı' olarak oturup oturup insanların kullanması için mümkün olduğunca kolay hale getirmeniz gerekiyor. SCM sistemiyle uğraşmak yerine kod yazmak istiyorlar.

Git'in CLI şifreli ve önemsiz problemleri (sen ve ben) insanların çalışmasını engelleyeceğiz. İşte ekibimizde olanlar: (sizce bunlar oldukça yetenekli geliştiricilerdir)

• Windows'ta SSH ile Git yaygın bir sorundu.
• İnsanlar birleşir, birleşir, ama birleşmez. Yani grafik çok kafa karıştırıcı bir karışıklık olurdu
• Windows'taki performans sorunu "git durumu" 15 saniye sürdü
• Yeni bir dalın nasıl çekileceği çözülemedi. Üzerinde çalıştıkları her şeyden ayrılacak olan bir "git checkout -b" yapacaklardı
• Tutulmadaki EGit ezici bir mönüye sahipti. Herkese ilk başta komut satırını kullanmalarını söyleyerek bitti
• Önceki öğeye dayanarak, git mergetool birleştirme ve kurma
• "Git add" ve "git commit" ve "git push" arasındaki farklar hakkında karıştı.

Hala biraz direnç alıyoruz, ancak insanlar kesinlikle faydalarını görebiliyorlar. Rehberlik için birkaç Git kişisine sahip olmak ve yardım etmeye istekli olmak çok önemlidir. Ayrıca reset / rebase / - amend / etc gibi hoş şeyler öğretmekten de kaçınırdım. çoğu insan Git'i SVN gibi kullanacağından, eğer isterlerse keşfetmelerini sağlamak daha iyidir.

Git-mania'ya karşı uzman

Temel yeterlilik gibi bir terim, farklı insanlar için farklı anlamlara gelebilir. Birçok insan git-mania gibi görünüyor (yanlış bir şey olmadığı için değil). Birçoğumuz, kendimizin ve diğer insanların kaynak kontrolüne olan dikkatsizliği yüzünden gerçekten kötü bir şekilde yakıldık.

Neden Önemlidir? (Çok)

Kaynak kontrol araçları kritiktir, çünkü suiistimal sadece bir kişiyi değil tüm takımı yavaşlatabilir. Git kötüye kullanımı, SVN, CVS ve diğer sistemleri kötüye kullanmaktan daha az problemli olmalıdır. Tarihsel olarak, dosyaları kilitleyen sistemlerin beceriksiz kullanımı özellikle sorunluydu ve şirketler, ayrı derleme ekipleri kiraladılar; böylece birileri belaya girdiğinde, yarayı depoya götürebilecek kaynak kontrolü dışında neredeyse hiçbir şey yapmayan akıcı bir uzman vardı. Bu kısmen git'in arkasında bulduğun tutkuların bir kısmını açıklar.

Temel yeterlilik neye benziyor?

Bazı somut kriterler şunlardır:

• Belgelere atıfta bulunmadan:

  • Dosya ekleyebilir, değişiklik yapabilir, güncellemeleri itebilir ve çekebilir.
  • Durum ve revizyon aktivitesini görebilir.
  • Dallanma ve hızlı bir şekilde hata yapmadan birleştirilebilir.
  • Ödeme uygun şekilde kullanabilir miyim.
  • Grubun yorum kriterlerini karşılayan taahhüt yorumları oluşturun.
  • Çalışan kopya ve arşiv arasındaki değişiklikleri değiştirin.

• Dokümantasyon ile:

  • Yerel repo için kullanıcı ve kimlik bilgileri ekleyin.
  • yerel bir depoya init.
  • Uzak repoyu yönet.
  • Yok sayılan dosyaları yapılandırın, PKI ortak / özel anahtar çiftleri oluşturun.
  • Dosyaları taşıyın ve silin.
  • Belirli bir hatayı tanıtan değişikliği bulmak için bisect kullanın.

Hataların önlenmesi için sağlam bir zihinsel model ve yönetilen kod kritik öneme sahiptir.

Gelişmiş uzmanlık / uzmanlık için ne eklersiniz?

Akıcı kullanım, geliştiriciler ve muhtemelen ekibinizin diğer bazı üyeleri için esastır. Git gibi araçlar genel gider ve neredeyse otomatik olabilecekleri bir seviyede öğrenilmelidir. Yılda binlerce kez tekrarlanan git komutları kullanılarak üretilen zaman ve dikkat dağınıklığını azaltmak yüksek değere sahiptir.

Her zaman uzman kullanıcılar olacak ve neredeyse her komutu hemen hemen her seçenekle kullanan ekibinizin bazı üyeleri olacaktır. Benim tavsiyem, ekip üyelerinin, öğrenim için ROI, projede başka bir şey yapma değerinin altına düşene kadar öğrenmeyi devam ettirmeye teşvik edilmesi ve ana sınırlama mevcut durumdan atılan kalemlere ayak uydurmaya devam etmesidir. sürat.

GIT, bir işi yapmak için adil bir araçtır ve en büyük sorunlarından biri, birçok GIT habercisi, tüm GIT kullanıcılarının, nasıl çalıştıklarının en iyi noktalarını anlayan kaporta uzmanları altında olmasını beklemeleridir. Bu GIT'in en büyük zayıflığı - onu kullanmak için nasıl çalıştığını bilmeniz gerekiyor. GIT ile ilgili tarif yok, GIT uzmanı olmanız veya kullanmamanız bekleniyor. Pro-GIT'i kuruluşunuzun bir "goto" GIT guruya (veya iki) ihtiyaç duyması harika. Çünkü her geliştirici GIT Guru olmak istemiyor - bu da sorun değil.

Takımın GIT'i nasıl kullandığını bilmesi gerekir (aslında GIT'in nasıl çalıştığını değil, iş akışının kullanmasını gerektiren GIT bölümlerini nasıl kullanacaklarını bilmeleri gerekir). Her geliştiriciden, kullandıkları her araçla ilgili her ayrıntıyı bilmesini beklemek zarar vericidir. İş akışınızı destekleyen bir tarif defteriniz yoksa, GIT'i dağıtmadınız, geliştiricilere bıraktınız.

Git'e nasıl çalışacağımı bildiğim sürece, GIT'in nasıl çalıştığını bir maymun vermiyorum.

Evet.

“Şirket” in hangi aracı seçtiğine bakılmaksızın, geliştirme ekibinizin aracı nasıl kullanacağını öğrenmek için biraz zaman harcaması gerekir. Hiçbir şey, bir araçtan korkan veya görmezden gelen bir grup geliştiriciden daha fazla üretkenlik yaratamaz. Eğer yanlış kullanıyorlarsa veya ona karşı çalışıyorlarsa, sorunlar ortaya çıkacak ve erkeğe giderken, pisliği temizlemekle görevlendirileceksiniz.

Git, birçokları için zorlu bir geçiştir, bu nedenle zorunlu bir oturma oturumu eğitim seansı olabilir. Bu, insanların sahip olduğu sorunların çoğunu gidermeye yardımcı olmalıdır.

Git'i sadece kişisel bir ortamda kullandım, profesyonel olarak değil, sahip olduğu gücü ve merkezi olmayan bir kaynak kontrolü fikrini sevsem de önemli sorunları var. Git sızdıran soyutlama var ve basit şeyler yapmak için birden fazla komut gerekiyor (örneğin bir değişiklik yapmak için: git add, git commit, sonra git push). Ayrıca belgelerin bazıları eksik ve / veya rebase komut açıklamasında olduğu gibi kafa karıştırıcıdır ... "Bağlantı noktası yerel yerel, güncellenmiş akış yukarı kafasına taahhüt eder". Bunun ne anlama geldiğine dair hiçbir fikrim yok ve şu anda kararları hareket ettirebileceğini ve tarihini onunla yeniden yazabileceğini bilmeme rağmen (başka bir sıkıntı ... neden bunu yapmana izin verilmeli? ??) açıklama. Takımınızla ilgili bazı okumalar ve sizin tarafınızdan verilen bazı eğitimler düzenli olduğunu düşünüyorum.

Eğitim ve anlayış minimum gereksinimlerdir. Sorumlu biri, ekibinizin onu nasıl kullanacağı konusunda bir plan olduğundan emin olmalıydı. Kurallar olmadan yeni bir programlama dili benimsemezsiniz. Sürücünün eğitimi, yolun belirlenmiş kuralları dahil edildiğinde çok daha etkilidir.

Hayır; Aşağıdakileri beklemenin mantıklı olduğunu düşünüyorum:

1. Günlük işleri (taahhüt, itme, çekme, dallanma, birleştirme, ikiye ayırma vb.) Elle tutmadan yapın.
2. Rutin olmayan görevleri tekrarlanan talimatlar olmadan yapın. (Birkaç tekrarlama tamamdır - isimleri gerçekten yapışmadan önce 2-3 kez birisiyle tanışmalıyım.)

Eğer # 1'i yapamazlarsa, katılımınızın eğitim kısmı muhtemelen yetersizdi. # 2 yapamıyorlarsa, önce çok üzülmeden önce her şeyi yeterince net bir şekilde açıkladığınızdan emin olun.