GitHub Stacked PR için herkese açık önizlemeyi başlattı

 (github.blog)
1 puan yazan GN⁺ 1 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Büyük değişiklikleri küçük ve incelenebilir katmanlara bölen Stacked pull requests, tüm depolara herkese açık önizleme olarak kademeli sunuluyor
  • Her PR, doğrudan altındaki katmanı hedefliyor; böylece ekip arkadaşları dar kapsamlı diff'leri paralel ve bağımsız olarak inceleyebiliyor
  • En üstteki güncel PR birleştirildiğinde, altındaki henüz birleştirilmemiş katmanlar da tek seferde uygulanıyor; yalnızca bir kısmı birleştirilirse üstteki PR'ler otomatik olarak rebase ediliyor ve hedefleri değiştiriliyor
  • Mevcut PR incelemeleri, zorunlu kontroller, branch koruması ve birleştirme gereksinimleri aynen geçerli; stack'ler GitHub.com, CLI, mobil uygulama ve GitHub Copilot'ta yönetilebiliyor
  • Herkese açık önizleme birkaç gün içinde tüm depolara yayılacak, Merge queue desteği ise sonraki haftalarda kademeli olarak sunulacak

Küçük değişiklikleri üst üste koyan PR yapısı

  • Büyük değişiklikler, küçük ve odaklı birden fazla PR'a bölünüyor; her PR sıralı bir değişiklik katmanı oluşturuyor
  • İlk değişiklik için branch ve PR oluşturulduktan sonra bunun üzerine yeni branch ve PR'ler ekleniyor; her PR doğrudan altındaki katmanı hedefliyor
  • Tek ve büyük bir PR'ı inceleme veya birden fazla branch'i sürekli elle rebase etme zahmetini azaltıyor
  • Next.js ekibi, büyük özellikleri yayınlarken bile tek tek değişiklikleri küçük tutabildikleri için PR incelemesinin kolaylaştığını belirtiyor

Stack oluşturma ve çalışma ortamı

  • CLI eklentisi şu komutla kuruluyor
gh extension install github/gh-stack
  • Stack'ler GitHub.com, GitHub CLI ve GitHub mobil uygulamasında oluşturulup yönetilebiliyor
  • GitHub Copilot gibi kodlama ajanlarında gh-stack skill'i kullanılabiliyor

Katman bazında bağımsız inceleme

  • Stack içindeki bir PR açıldığında, tüm değişiklikler değil yalnızca ilgili katmanın diff'i incelenebiliyor
  • PR'ın üst kısmındaki stack haritasından mevcut değişikliğin tüm çalışma içinde nerede konumlandığı görülebiliyor
  • Ekip arkadaşları farklı katmanları paralel olarak inceleyebildiği için sonraki işler, inceleme tamamlanana kadar beklemek zorunda kalmıyor
  • Mevcut branch koruma kuralları ile katman bazında inceleme birlikte uygulanarak her adımın kalitesi korunuyor
  • TED, yapay zeka kullanımının geliştirme verimliliğini artırmasının ardından büyüyen PR'lerin inceleme darboğazı yarattığını, değişiklikleri bağımlılık sırasına göre küçük mantıksal birimlere ayırarak inceleme hızını ve doğruluğunu artırdıklarını söylüyor

Stack'in tamamını veya bir kısmını birleştirme

  • Hazır durumdaki en üst PR birleştirildiğinde, o PR ve altındaki tüm birleştirilmemiş katmanlar tek seferde uygulanıyor
  • Alttaki katmanlardan bir veya birkaçını seçip stack'in yalnızca bir kısmı önce birleştirilebiliyor
    • Üstteki PR'ler açık kalıyor
    • Birleştirilen değişikliklere göre otomatik olarak rebase ediliyor ve hedef branch'leri değişiyor
  • Mevcut branch koruması, zorunlu kontroller ve birleştirme gereksinimleri uygulanmaya devam ederek main dalına giren değişiklikleri denetliyor
  • Yalnızca tüm stack değil, tek bir katman veya bazı katmanlar da seçilerek birleştirilebiliyor

Herkese açık önizleme ve destek takvimi

  • Stacked pull requests, birkaç gün içinde tüm depolara herkese açık önizleme olarak kademeli biçimde dağıtılıyor
  • Merge queue desteği ise sonraki haftalarda aşamalı olarak sunulacak
  • Ayrıntılı kullanım bilgileri stacked pull requests dokümantasyonunda yer alıyor; geri bildirimler stacks discussion üzerinden toplanıyor

İlgili okumalar

1 yorum

 
GN⁺ 1 시간 전
Hacker News yorumları

  • Önizlemeyi bir süredir kullanıyorum; hâlâ çözülmemiş çok sayıda sorun varken kapsamın genişletilmesi şaşırtıcı.
    Örneğin tüm yığını birleştirme, çeşitli durumlarda tamamen bozuluyor: https://github.com/github/gh-stack/discussions/212
    Tek tek birleştirmek mümkün, ancak squash merge ile zorunlu incelemeleri birlikte kullanırsanız yığındaki her PR için yeniden onay almak gerekiyor; bu da stacked PR’ların en büyük avantajını ortadan kaldırıyor.
    gh stack elle yapılan işleri biraz azaltıyor ama yine de git rebase’i doğru anlamak gerekiyor. Yerel branch uzak branch ile senkronize değilse UI’ın önerdiği gh stack rebase de başarısız oluyor ve araç bunun nedenini söylemiyor.
    Öte yandan stack UI’ını seviyorum; basit olmasına rağmen PR’lar arasındaki ilişkileri yeterince gösteriyor. Zaten PR’ları yığmak için bir nedeniniz olduğu varsayımıyla yalnızca iş akışını kolaylaştırıyor; yeni bir işlev sunan bir araç değil.

    • Squash merge sorununu çözen hata düzeltmelerini aşamalı olarak yayımlıyoruz.
      İçerideki CPRMC (Create Pull Request Merge Commit), çakışma olup olmadığından onayların gerçekten oluşturulacak commit ile eşleşip eşleşmediğine kadar kontrol ederek PR’ın birleştirmeye hazır olup olmadığını belirliyor.
      Birden fazla PR’ı squash merge etmek için ardışık squash commit’lerin hesaplanıp ardından kurallar ve incelemelerle yeniden ilişkilendirilmesi gerekiyor. İlk PR nispeten kolay, ancak ikinciden itibaren ata commit squash edildiği için branch’te özgün hâliyle bulunmuyor; bu da işi karmaşıklaştırıyor. Birden fazla parent olan durumlar ise çok daha zor.
      Şu anda stack merge işlemlerinin %99’u başarılı, ancak bunu çok daha yukarı taşımak ekibin en öncelikli işi.
    • Bugün stacked PR’ın işaret ettiği branch’i silince, ek açıklama olmadan sürekli merging durumunda takılı kalma hatası yaşadım.
      PR sisteminde kısmi bir kesinti mi var diye GitHub durum sayfasını bile kontrol ettim, ancak bunun stacked PR özelliğinin kendi hatası olduğu ortaya çıktı.
    • 2021’den beri tüm sektör tamamen hazırlan, ateş et, nişan al yaklaşımına geçmiş gibi görünüyor.
    • Şirketimizde de son dönemde bu özellik ve merge queue yüzünden çok fazla sorun yaşandı.

  • GitHub Stacked PRs ekibi olarak artık herkesin stack oluşturabilmesi için erişimi daha geniş açtık: https://gh.io/stacks
    Özellikle UI ve CLI hakkında geri bildirim istiyoruz; PR kullanım deneyimini iyileştirecek çok sayıda güncelleme de hazırlıyoruz.
    Actions ve koruma kurallarından CLI ve mobil uygulamalara kadar neredeyse tüm hizmetleri kapsayan, GitHub tarihindeki en büyük lansmanlardan biri olduğu için tasarım kararları ve iç işleyişle ilgili soruları da yanıtlayabilirim.

    • Bugün ilk kez denedim ve sonuç hoşuma gitti.
      Zaten kendi yerel UI’ımızda stacked PR bağımlılıklarını ağaç olarak görüyor, her PR’ın review/CI durumunu yönetiyoruz; bu yüzden GitHub web UI’ında da ağaç ve durum göstergeleri olursa iyi olur.
      Web UI’da stack’in en altındaki PR’ı tek başına birleştirme özelliği desteklenmiyor gibi görünüyor; mevcut iş akışımızı ve kodumuzu paylaşabiliriz, umarım GitHub’ın yerleşik araçlarına da girer.
    • Yakın zamanda fork’lar arasında stacked PR desteği sunmayı planlayıp planlamadığınızı merak ediyorum.
      Açık depolarda faydalı olması için önemli bir özellik gibi görünüyor; bu yüzden public preview’den önce sunulmamış olması şaşırtıcı.
    • Gerrit’ten en çok özlediğim özellik tam olarak buydu.
    • İş bölme birimi olarak ek PR’ları seçmenizin nedenini merak ediyorum.
      Commit bazında inceleme, uygulama ve düzeltme yapılabilen düzgün bir UI yerine, bu yaklaşımın kökeni olan mailing list’lerdeki patch serisi iş akışını göz ardı edip fiilen “patch serilerinin serisini” seçmenizde özel bir içgörü olup olmadığını öğrenmek isterim.

  • GitHub’a yıllar içinde gelen değişiklikler arasında en büyüklerinden biri.
    Dünyanın en büyük kod barındırma platformlarından birine stacked iş akışı eklenince, birçok geliştirici varlığından bile haberdar olmadığı bir yöntemle tanışabilir.
    Stack’lerin daha iyi yazılım ürettiği varsayımı doğruysa, gerçekten çok sayıda geliştiriciye yardımcı olma olasılığı da yüksek.

  • İyi düzenlenmiş commit’leri commit bazında inceleme yöntemiyle karşılaştırıldığında bu stacked PR’ların avantajının ne olduğunu merak ediyorum.
    Daha büyük sorun, büyük ölçekli yapay zeka üretimi PR’lar için ayrı bir inceleme yöntemine ihtiyaç duyulması. Fonksiyon tanımı değişiklikleri, çağrı noktaları, testler sırasıyla göstermek gibi, yalnızca diff’lerin gösterim sırası bile okunabilirliği ciddi biçimde etkiliyor.
    Literate programming’in kod ile düzyazıyı örmesi gibi diff ile açıklamayı birleştiren literate diff veya literate PR gerekebilir; ancak henüz benzer bir araç bulamadım.

    • Phabricator vb. yerlerde stacked diff kullanan kişiler için bu, zaten iyi düzenlenmiş commit’leri tek tek inceleme yöntemidir.
      İnceleme birimi olan PR veya diff, sınırlı tek bir değişiklik olarak kaldığından tartışma o değişikliğe odaklanır; özellik büyüse bile PR’ın kendisi şişmez.
      Ayrıca stack’in her bölümünü farklı kişilere atayabilirsiniz. Harici ekip, aynı ekipten çalışma arkadaşları, değişikliği kullanacak ekip gibi reviewer’ları ayırınca herkesin neyi onayladığı belirsiz olmaz.
      GitHub review’ları change ID getirip rebase sonrasında da yorumları korursa daha da iyi olur.
    • Stack’in ilk PR’ına commit eklerseniz bunu toplam commit sırasının ortasına yerleştirebilirsiniz.
      Sonraki PR’ları rebase edip düzeltmek gerekmesi, büyük tek bir PR’daki sonraki commit’leri düzeltmekle aynıdır; ancak tüm değişikliğe rastgele geçici düzeltme commit’leri eklemek yerine temel değişikliğin commit’lerini bir arada tutmak kolaylaşır.
      Temel değişiklikle ilgili tartışmalar da bir araya gelir; tüm stack’i önceden gösterirseniz reviewer nihai yönü kavrarken çalışma asenkron olarak devam edebilir.
    • Asıl mesele, gerçekten “iyi düzenlenmiş” commit oluşturan kişi sayısının fazla olmaması.
      Commit’leri oyun kayıt noktaları gibi kullanıp fix bug, do work gibi mesajlar bırakıyorlar ve git rebase -i ile temizlemiyorlar; bu yüzden zorunlu squash merge açılmazsa log çöp commit’lerle doluyor.
      Bu geliştiriciler için PR zaten commit’tir; stacked PR sayesinde tek bir değişikliği oluşturan birden fazla commit’e benzer yapıyı sonunda kullanabilir hâle gelirler.
    • Stack kullanınca incelemeye uygun boyutta diff’ler üretmeye devam ederek uzun değişiklik çalışmalarını sürdürebilirsiniz.
      Birleştirilmiş diff’ler mevcut HEAD üzerine rebase edilebilir; bunu destekleyen ekiplerde genellikle branch’ler doğrudan yönetilmez, trunk üzerinde çalışılır ve değişiklikler geldikçe rebase yapılır.
    • PR’da commit’leri tek tek birleştiremezsiniz, ama stack’te bu mümkün.
      Özelliğin ilk 4 parçası hazırsa ve 5’incisinde sorun varsa, tamamını bloke etmek gerekmez.

  • Bağımlı PR’ların doğrusal bir geçmiş yerine ağaç yapısı oluşturduğu durumların ne zaman destekleneceğini merak ediyorum.
    Google’da yığın hâlinde değişiklikler kullanırken bu tür durumlar yaygındı; paralel kodlama ajanlarının arttığı bugünlerde daha da sık ortaya çıkacak gibi görünüyor.

    • İnsanların yönetmesi bile zor bir yapı; yazılımın ve buna bağlı yapay zekanın böyle bir yöntemi teşvik edecek şekilde tasarlanmasının gerçekten doğru olup olmadığını sorguluyorum.

  • Menü geçiş düğmesinin pankek yığını emojisi (U+1F95E) olmasının nedeninin stack özelliği olup olmadığını merak ediyorum.
    Şakacı ifade tarzı kendi başına sorun değil, ama neye baktığınız konusunda güçlü bir şüphe uyandıran bir UI idi.

  • İlk haberi duyduğumdan beri gh stack CLI’ını kullandım ve aracın kendisi çok iyiydi; ancak önizleme onayı alıp eriştiğim web UI beklentilerimin oldukça altında kaldı.
    Onaydan önce bile CLI, işi birden fazla atomik PR’a bölme otomasyonunu kolaylaştırıyordu; fakat push edince bunlar birbirine bağlı olmayan bağımsız PR’lar olarak görünüyordu.
    Onaydan sonra da neredeyse aynı: üstteki küçük gezinme açılır menüsünde aynı stack’teki diğer PR’ların gösterilmesi dışında anlamlı bir UI değişikliği yok.
    Açılır menüden CLI işlevlerinin bir kısmını yapabiliyorsunuz, ama bu web’de dosya düzenleme özelliği gibi tali bir kolaylık; gerçek geliştirme iş akışında merkezde CLI veya IDE eklentileri olacak.
    Bu düzeyde isteğe bağlı bir UI yüzünden genel kullanıma açılmanın neden bu kadar uzun süre ertelendiğini merak ediyorum; stack CLI zaten duyurulduğu zamandan beri genel kullanıma açıktı.

    • Başta asgari özelliklerle başlamamız gerekiyordu, ancak çok daha kapsamlı bir PR UI yenilemesi üzerinde çalışıyoruz.
      Stack’i her zaman farkında olan ve çok tıklamaya gerek kalmadan her katman arasında geçiş yapılabilmesini sağlayacak şekilde stack’i sürekli gösteren bir ekran da buna dahil olacak.

  • jujutsu’nun iyi yanı, bir branch’i güncellediğinizde o branch’ten ayrılmış diğer branch’leri de otomatik olarak rebase etmesi.
    İncelemeyi kolaylaştırmak için işi bölerken sık sık jjye geçiyorum; Git ile oluşturulmuş kopyayla aynı çalışma dizininde birlikte kullanıldığında da sorunsuz çalışıyor.

    • jj absorb da harika.
      Değişiklikleri en yakın ilgili değişikliğe taşıdığı için birden fazla PR’ı etkileyen düzeltmeleri de kolayca ele alabiliyorsunuz.

  • Graphite kullandıktan sonra stack’siz GitHub’a dönmek çok zor geldi.
    GitHub desteğiyle stack’li PR iş akışının yaygınlaşmasını ve devasa PR’ların yerine kolay bir alternatif oluşmasını umuyorum.

    • git-spiceı öneririm.
      Kullanımı kolay, güçlü ve açık kaynak; Graphite ise sunduğu özelliklere göre aşırı karmaşık hissettirdi.

  • PR yığmanın iki durumda faydalı olduğunu anlamıştım.
    Birincisi, birbiriyle ilişkili birden çok depoya yayıldığı ve tek bir PR’da birleştirilemediği durumlar; ikincisi ise ilk PR incelenirken aynı branch’in üzerine devam PR’ları yığıp çalışmayı pipeline hâline getirmek.
    Ama bu özellik ikisini de karşılamıyor; tek bir PR’a commit yığmanın başka bir biçimi gibi görünüyor.
    Genelde atomik ve anlamlı commit’ler oluşturulur, rebase ile inceleyenin anlayacağı iyi bir akış kurulur; inceleyen de isterse commit bazında bakabilir.
    Bu yöntemde kaçırdığım özgün avantajın ne olduğunu merak ediyorum.