Git'in en iyi uygulamaları bana saatler süren rework kazandırdı

Son zamanlarda bir NodeJS uygulaması için sertifika yükseltme görevinde çalışıyordum. Bu özellik geliştirme için iki yıl önce son dokunuldu. Uygulamaya yalnızca dahili olarak kullanılmasına rağmen, bu uygulamaya açılan tüm canlı yayınlar derhal dikkat gerektirecektir.

Uygulamanın eski. Core-NodeJS-Infra modülleri iki yıldan fazla bir süredir güncellenmedi. Alt servisler kullanımdan kaldırılmıştır. Akış aşağı hizmetleri arama biçimimiz değişmiştir. Sıkı son tarih, pastanın üzerindeki bir kirazdır. Roller-coaster yolculuğu olacağını biliyordum.

Uygulamayı çalıştırmak için üç gün geçirdim.

Kızılötesi modüller güncellendi? Kontrol.

Alt servisler iyi çalışıyor mu? Kontrol.

UI akışları iyi çalışıyor mu? Kontrol.

Ekip üyelerimizden biri bir yıl önce yükseltme için uygulamaya dokundu. Çatal koyduğum yerdeki deponun kendisinin de çatallı bir depo olduğunu belirtti. Başka bir takım bu repo üzerinde çalışmıştı ve sonra ekibimiz orijinal repo üzerinde bu noktadan sonra çalıştı - ancak ekip üyem hangi noktadan itibaren ne olduğunu bilmiyor. Bu yüzden biraz karışıklık oldu!

Doğru repoyu gösteren ve bana “yalan söyleyen” bir “Mülkiyet” aracımız var. Yani durum şöyle oldu:

Forkception

Evet, Forkception'dı! WTF ve FML ağzımdan çıkan ilk iki düşüncedir. Canlı depoda çalışmalıydım ama bunun yerine eski bir çatal üzerinde çalıştım. Ne kadar da aptalım!

İlk düşünce - üç günlük çalışmam boşa gitti ve yeni başlamam gerekiyor.

İkinci düşünce? Eski arkadaşım Git'e soracağım. Bana çok uzun zamandır yardım ediyor.

Ben - “Hey Git? Başım büyük belada ve bu sorunu çözmek için yardımınıza ihtiyacım var. ”

Git - “Hey! Tamam, öyleyse önce canlı olandan başlamalıyız. Şube denilen yeni bir yükseltme oluşturun ve o dalı canlı koda işaretleyin. Bunun için bir git hard reset kullanabilirsiniz.

Ben - “Tamam yaparım.”

Bu noktada durum böyle gözüküyor.

Git özelliklerini kullanma

Git - “Geliştirme ve yükseltme arasında neyin değiştiğini bilmemiz gerekiyor. Yükseltme ve geliştirme arasında farklı olan dosyaları listeleyebilir misiniz? Bu dosyaları tek tek kontrol edin ve ne tür değişiklikler olduğunu anlayın. ”

Ben - “Harika. Üç çeşit değişiklik görüyorum. Farklı bir şekilde aramam gereken bir S1 servisi var. Farklı bir son nokta kullanarak aramam gereken bir S2 servisi var. Farklı parametreler kullanarak çağırmam gereken bir S3 servisi var. Ayrıca yükseltme dalındaki package.json dosyasının zaten yükseltilmiş olan bazı paketlerine sahip olduğunu görüyorum. Bu yüzden sadece birkaç paketin değiştirilmesi gerekiyor. ”

Git - “Değişiklikleri ayırdığınız için harika. Şimdi bana geliştirme dalının Git günlüğünü göster. Umarım bazı temel Git uygulamalarını takip etmişsinizdir, örneğin her iş için her zaman oluşturulabilir kod vardır. Taahhüt mesajı neyi değiştirdiğinizi göstermelidir. ”

Geliş günlüğünde Git günlüğü

Ben - “Evet, geliştirme dalında toplam dört komisyonum var. Bir taahhüt, projenin inşa edilebilir hale getirilmesiydi. Üç servis çağrısının her biri için bir tane var. ”

Git - “Mükemmel! Doğru şekilde en iyi uygulamaları takip etmiş gibisin. Package.json 'u güncel hale getirerek proje oluşturmayı dengeleyerek başlayalım. Yükseltme şubesine çıkış yapın ve package.json - package-copy.json dosyasının bir kopyasını alın. Şimdi, Git değiştirmeyi kullanarak / package.json'ı develop / package.json ile yükseltin ve package.json ile package-copy.json arasındaki farkı çalıştırın. Canlı kod zaten değiştirilmiş paketlerden bazılarına sahip olduğundan ve farklı sürümleri olduğundan, farklılığa bakarak yükseltmeniz gerekir. ”

Projenin inşa edilebilir hale getirilmesi

Ben - “Bunu deneyeyim. Tamam, inşa ediyor ve çalışıyor. ”

Git - “Harika! Şimdi servis aramaları üzerinde çalışalım. Geliştirme branşındaki her servis çağrısı değişikliği için bir taahhüdünüz olduğunu görüyorum. Vişne toplama zamanı. En az karmaşık servis çağrısından en karmaşık servis çağrısından seçim yapın. Çakışmaları seç, birleştir ve çöz. Her kiraz seçiminden sonra ve her bir işlemden önce projenin inşa edilebilir durumda olup olmadığını kontrol ettiğinizden emin olun.

Ben - “S1 yapıldı. S2 yapıldı. S3 yapıldı. Teşekkürler Git ”

Git - “Bir şey değil. Ancak, Git taahhüt uygulamalarını takip ederek ve Git'e yalnızca bir kod saklama alanı olarak muamele etmemenize yardımcı olan sizsiniz. ”

Burada ne yaptım?

İlgili Değişiklikleri Yap

Bir an için bir duraklama yapın ve bu değişikliğin bu taahhütte yerine getirilmesi gerekip gerekmediğini düşünün. “Değişim: servis-s1 uç noktaları” ve hizmet-s2 değişikliklerine sahip olan bir taahhüt sadece karışıklık yaratacaktır.

Yarım Yapılmış İşi Taahhüt Etme

Sık sık “erken, sık sık taahhüt et” mantrasını duyduk. Yukarıdaki örnekte, aynı hizmetin farklı uç noktaları için bir taahhütte bulunabilirsiniz. Buna Sosis Yapma denir.

Ancak, git rebase interaktif modunu kullanarak küçük işlerimi kişisel olarak eziyorum. Bu, sertifikalandırılabilen bir mantıksal değişikliğe sahip olmamda bana yardımcı olur ve kodunuzu da gözden geçirmek için Güvenilir bir Alıcıya yardımcı olur. Bu büyük ölçekli projeler için çok tercih edilir.

Kabul Etmeden Önce Kodunuzu Test Edin

Git'i durum makinesi olarak düşünmeliyiz ve herhangi bir makine herhangi bir durumda inşa edilebilir durumda olmalıdır.

İyi Taahhüt Mesajları Yaz

Bu çok önemli bir bölüm. Her zaman bir an için duraklar ve sadece üç ay sonra bu taahhütteki değişimin sadece taahhüt mesajına bakarak anlayamayacağımı düşünürüm.

Sonuç

Ortalığı çabucak çözebildim. Bazı iyi uygulamaları takip ettiğim için bu WTF ve FML anlarından çıkabiliyordum. Bir nedenden dolayı varlar ve gıdada tuz gibiler - değerlerini yalnızca kullanılmadıklarında farkedersiniz.

Hatalar er ya da geç bilinçsizce gerçekleşir. Ancak Git'in etrafındaki bazı uygulamaları bilinçli bir şekilde takip ettiğinizden emin olun.

Git tarihinin içinde gezinmeye yardımcı olan Git semantic taahhüt mesajlarının hayranıyım. Çünkü dürüst olalım, herkesin her işlem mesajı için aynı kelimeleri kullanmasını bekleyemezsiniz. Ancak, mesaj tipi beklenebilir.

Bu, her taahhütten sonra projenizin inşa edilmesini sağlamaya yardımcı olur - ki bu gerçekten faydalıdır.

VSCode Git için hasta desteği var. Çatışmaları görmek ve bazen sadece tek bir tıklamayla çözmek çok kolay. Aşağıdaki örneğe bakın

Referanslar

  • Git Best Practices
  • VSCode'da Süper Müthiş Sürüm Kontrol Entegrasyonu
  • Git Semantic Commit Mesajları
  • Git İpucu : Başka bir daldaki belirli dosyalar nasıl birleştirilir?
  • Git İpucu : Git - git-cherry-pick Belgeleri
  • Git İpucu : Git - git-reset Belgeleri

İçerik iyileştirme konusunda bana yardımcı olan arkadaşlarım Saurabh Rajani ve Anish Dhargalkar'a özel teşekkürler.