GitHub PR'lerini cherry-pick etmeyi deneyin

• Şirket içinde mono-repository kullanmaya başlayalı 4 ay oldu
• mono-repository ile birlikte anılan anahtar kavram olan trunk-based development da birlikte uygulanıyor
• trunk-based development stratejisine göre main branch'ine commit atıp, release branch'ine cherry-pick yapılan bir akış kullanılıyor
• LinkedIn teknik blogu içeriğini temel alarak bir GitHub Action yapılandırıldı, ancak bu yapı CONFLICT durumlarını otomatik çözemiyor. CONFLICT oluştuğunda kullanıcının local ortamında doğrudan git cherry-pick komutunu çalıştırması gerekiyor
• Bu cherry-pick komutuna yardımcı olan gh eklentisini bizzat geliştirdim.

Kullanım

gh cherry-pick -pr <pr_number> -onto <target_branch> [-merge auto|squash|rebase] [-push]  

• -merge seçeneğiyle PR merge commit'inin mi yoksa PR'nin orijinal commit'lerinin mi cherry-pick edileceği seçilebiliyor
  • Belirtilmezse veya -merge=auto seçeneği kullanılırsa, PR'nin hangi stratejiyle merge edildiği otomatik olarak incelenip uygulanıyor
• -push seçeneğiyle cherry-pick başarılı olduğunda otomatik remote push desteği sağlanıyor

İzlenimler

• Sürekli olarak dış süreçler ve durumlarla etkileşen bir program geliştirirken, ayrı bir test repository oluşturarak test veri seti üretildi
  • Geçmişte libgit2 projesine ve refined-github'a katkı yapmış olmanın faydası oldu
• CLI deneyimini iyileştirmek için yapılan çeşitli çalışmalar
  • docker-cli'yi tek başıma yeniden yapmaya çalışırken edindiğim deneyim yardımcı oldu
• CLI programı geliştirmenin beklenenden çok daha fazla emek gerektirdiği görüldü
  • Pipeline yapısında çok sayıda state değerini yönetmek
  • Kullanıcıya sezgisel bir input arayüzü sunmak
  • Input validation'ı mümkün olduğunca erken aşamada sağlamak
  • Kullanıcının sistemini başlangıç durumuna geri döndürmek gibi konular..
  • Bir gün içinde yapılabileceği tahmin edilmişti, ancak tamamlanması yaklaşık 5 gün sürdü (GitHub Actions Workflow iyileştirmesi için geliştirme paralel ilerlese de yine de beklenenden çok daha fazla zaman aldı)

[qncnxnlrla]

Merhaba~ main (trunk) branch'ine merge edilmiş bir commit'in revert edilmesi gerektiğinde bunu nasıl ele alıyorsunuz?

• main branch'inde revert ederseniz release branch'ine de cherry-pick edilir mi?
• revert kullanmadan düzeltme commit'i mi eklersiniz?

Biriken commit sayısı fazla olduğunda conflict oluşursa cherry-pick'in zor olabileceği durumlar vardır diye düşünüyorum; böyle vakaları nasıl yönettiğinize dair deneyiminiz olup olmadığını merak ediyorum!

[a1eng0]

Merhaba~ Yanıt bıraktığınız için teşekkürler!

main(trunk) branch'ine merge edilmiş commit için revert gerektiğinde bunu nasıl ele alıyorsunuz?

Main branch'ine açılan revert PR'da cherry-pick'i belirtiriz. Orijinal PR linkinde tüm cherry-pick geçmişi kaldığı için takip etmesi zor olmuyor. Ayrıca ayrı bir mekanik kontrol de yapmıyoruz hehe

Çok fazla commit birikmişse ve conflict çıkarsa cherry-pick'in zor olduğu durumlar

Öncelikle trunk-based development yapıldığında her PR küçük birimlerden oluştuğu için conflict sık çıkmıyor. Eğer conflict oluşursa kodu elle yazmak gerekiyor. Çok eski sürümleri desteklemekten doğan ve kod yapısının büyük ölçüde değişmesine yol açan durumları önlemek için release'i sık sık yapıyor, böylece eski sürüm desteğini hızlıca deprecate ediyoruz!

[lamanus]

Neden buna ihtiyaç duyulduğunu tam anlayamadığım bir strateji...

[a1eng0]

release-from-trunk içinde tanıtılan içeriği okursanız, anlamanıza yardımcı olabilir diye düşünüyorum haha