GitHub Stacked PRs

 (github.github.com/gh-stack)
9 puan yazan GN⁺ 16 일 전 | 1 yorum | WhatsApp'ta paylaş
  • GitHub’un, büyük kod değişikliklerini küçük ve incelenebilir PR birimlerine bölerek sıralı şekilde yönetmeyi sağlayan yeni özelliği
  • Her PR bağımsız olarak incelenir ve tüm stack tek tıkla birleştirilebilir
  • GitHub arayüzü ve gh stack CLI üzerinden stack oluşturma, gezinme, rebase etme, birleştirme desteklenir; stack map ile hiyerarşik yapı görselleştirilir
  • Yapay zeka kodlama ajanı entegrasyonu sayesinde büyük diff’ler otomatik olarak stack birimlerine ayrılabilir veya stack tabanlı geliştirme yapılabilir
  • Amaç, büyük PR’lerin karmaşıklığını ve çakışma riskini azaltırken inceleme verimliliğini ve ekip geliştirme hızını artırmaktır

Başlıca özellikler

  • Stack tipi PR yönetimi

    • Birden çok PR, sıralı bir stack yapısı halinde düzenlenir ve her PR doğrudan altındaki PR’ın branch’ini temel alır
    • Sonunda ana branch’e ulaşan bir zincir yapısı oluşur
    • GitHub tüm stack’i algılar ve arayüzde stack map gösterir; böylece inceleme yapanlar her katmanda kolayca gezinebilir
    • Branch koruma kuralları son hedef branch’e uygulanır ve CI testleri stack içindeki tüm PR’ler için çalıştırılır

  • Basitleştirilmiş stack yönetimi

    • GitHub arayüzünde stack içindeki PR’ler arasında geçiş yapılabilir, her katmanın durumu görülebilir ve tüm stack için zincirleme rebase (cascading rebase) çalıştırılabilir
    • Tek tıkla tüm stack veya yalnızca bir kısmı birleştirilebilir
    • Birleştirme sonrası kalan PR’ler otomatik olarak rebase edilir; böylece en alttaki henüz birleştirilmemiş PR, varsayılan branch’i hedefleyecek şekilde ayarlanır

  • Güçlü CLI desteği

    • gh stack CLI ile stack oluşturma, rebase etme, branch push etme, PR oluşturma, katmanlar arasında geçiş işlemleri terminalden yapılabilir
    • CLI komut örnekleri
      • gh extension install github/gh-stack : eklentiyi kurar
      • gh stack alias : kısayol komutlarını ayarlar
      • gs init <branch> : ilk branch’i oluşturur
      • gs add <branch> : yeni katman ekler
      • gs push : tüm branch’leri push eder
      • gs submit : tüm stack için PR oluşturur

  • Yapay zeka ajanı entegrasyonu

    • npx skills add github/gh-stack komutuyla yapay zeka kodlama ajanı stack işlemleri yapacak şekilde eğitilebilir
    • Büyük diff’ler otomatik olarak stack birimlerine ayrılabilir veya baştan itibaren stack tabanlı geliştirme yapılabilir

Stack tipi PR’lere neden ihtiyaç var?

  • Büyük PR’ler inceleme zorluğunun artmasına, birleştirmenin gecikmesine ve çakışma riskine yol açar
    • İncelemeyi yapan kişiler bağlamı kaybedebilir, geri bildirim kalitesi düşebilir ve tüm ekibin hızı yavaşlayabilir
  • Stacked PRs bunu çözmek için değişiklikleri küçük ve odaklı bir PR zincirine böler
    • Her PR bağımsız olarak incelenebilir ve tüm değişiklikler sıralı biçimde birikir

Başlarken

İlgili okumalar

1 yorum

 
GN⁺ 16 일 전
Hacker News görüşleri

  • Benim ihtiyacım olan şey "stacked PR" değil, tekil commit yönetimi için bir UI

    • Yalnızca bazı commit'leri bağımsız olarak merge etmek ya da belirli commit'leri incelemesi tamamlanmış olarak işaretlemek istiyorum
    • Commit düzeyinde interactive rebase/squash/edit yapmak istiyorum ama GitHub UI'ında bu mümkün değil
    • Commit mesajlarına veya belirli commit'lere yorum bırakma özelliğine ve zorunlu push'lar arasındaki değişiklikleri diff of diff ile görselleştiren bir özelliğe ihtiyaç var
      Git zaten commit kavramına sahip; bunun üstüne neden bir de “stacked PR” diye bir soyutlama ekleniyor, anlamıyorum
    • Bu, Phabricator'un oluşturduğu stacked diff workflow'unun GitHub'a taşınmış hali
      Henüz merge edilmemiş işlerin üstünde yeni işler yapmayı kolaylaştırıyor ve büyük değişiklikleri inceleyen kişilerin bunları küçük parçalara ayırıp bağımsız incelemesine olanak tanıyor
      Özellikle büyük monorepo'larda veya kurumsal ortamlarda faydalıydı
    • Ama ben git geçmişini sürekli yeniden yazmayı riskli buluyorum
      Tekrar tekrar squash, rebase ve force push yapmak kendi ayağına sıkmak gibi geliyor
      git merge --no-ff, git log --first-parent, git bisect --first-parent ile de yeterince benzer etki elde edilebilir
    • Meta'da kullanılan SuperSmartLog(SSL) en iyi uygulamaydı
      interactive smartlog dokümanı olarak açıklandı ve bir VSCode uzantısı da var
      Buna rağmen çok yaygınlaşmamış olması üzücü
    • Benim tercih ettiğim workflow, PR/MR'yi “atomik değişiklik” olarak görmek
      Commit'leri ise o PR'ı tamamlamaya giden evrimsel süreç olarak kullanmak
      1. PR çok büyükse commit'lere ayırırım
      2. PR'ın nasıl geliştiğini commit'lere kaydederim (“foo'yu bar yaptım” gibi gerekçeler dahil)
    • Anlattığın şey aslında Gerrit

  • Phabricator ve Mercurial kullandıktan sonra GitHub'a dönmek taş devrine dönmek gibi hissettiriyor
    Stacked diff akışını yeniden sunan jujutsu veya bu yeni özellik sevindirici
    Sadece monorepo'larda değil, uzun soluklu feature geliştirmede de incelemeleri küçük ve hızlı tutmayı sağlıyor

    • Git'in DVCS savaşını kazanmış olması gerçekten sevindirici
      Mercurial hep “git'ten daha hızlı” derdi ama pratikte ya daha yavaştı ya da bozuluyordu
      Git çirkin ama hızlı ve güvenilir
    • GitHub inceleme deneyiminden hâlâ hoşlanmadığım için Gerrit kullanıyorum
      Büyük değişiklikleri incelerken (ör. vendor dependency güncellemeleri) GitHub'ın dosya inceleme deneyimi iyi değil
    • Phabricator'un inceleme UI'ını çok özlüyorum

  • Sonunda geldi!
    GitHub'ın “PR=branch” modeli bana hiç mantıklı gelmiyordu
    Phabricator/Gerrit tarzı stacked commit benim düşünme biçimime daha uygun
    Artık CLI'ı kurmam gerekecek

    • GH CLI bağımlılığı biraz can sıkıcı ama GA olduğunda UI desteği de gelir umarım
    • Benim zihinsel modelimde branch ile stacked PR arasındaki fark çok net değil
      Branch, sadece commit'e bir bayrak dikmek gibi; birden fazla noktayı korumak ancak önceki parçalar bağımsız merge edilebiliyorsa anlamlı

  • Mevcut durumda Squash & Merge UX sorununu çözüp çözmediklerini merak ediyorum
    Ben manuel olarak main <- PR A <- PR B <- PR C şeklinde yığıyorum,
    PR A önce merge edilirse PR B tam bir conflict cehennemine dönüyor
    GitHub UI hedef branch'i otomatik olarak main'e çeviriyor ve garip conflict'ler çıkıyor
    Bana sadece “işi düzgün yapan” bir araç lazım

    • Conflict'lerin nedeni muhtemelen PR A'nın squash merge edilmiş olması
      gh stack sync bunu rebase --onto ile çözebilmeli
    • Pratikte bu işlem CLI ve sunucuda git rebase --onto ile yapılıyor
      Örnek: PR1(main<-A,B), PR2(main<-A,B,C,D), PR3(main<-A,B,C,D,E,F)
      PR1 ve PR2 squash merge edilirse main artık S1(A+B), S2(C+D) olur
      Sonrasında git rebase --onto S2 D branch3 ile conflict yaşamadan düzenlenebilir
    • Benim workflow'umda A merge edildiğinde B de zaten merge edilmiş olmalı
      git rebase --update-refs --onto origin/main A C ile çözülebilir
      GH CLI bu süreci otomatikleştiriyor
    • Bu sorun git'in mantıksal bir sınırı, bir bug değil
    • Ben de bunun sinir bozucu ve sezgisel olmaktan uzak olduğuna katılıyorum
      Ama çözüm eninde sonunda commit'leri elle rebase ederek düzenlemekten geçiyor

  • Tek başına geliştirirken stacked PR'a neredeyse hiç ihtiyaç olmuyor ama küçük parçalara ayırma alışkanlığı yine de önemli
    AI araçları (ör. Claude Code) tek seferde büyük diff'ler ürettiği için,
    ajanların işi kendi kendine mantıksal birimlere bölmesi ilginç olabilir

    • PR zaten birden fazla commit'ten oluşabiliyor; dolayısıyla ajan bunu iyi gezinemiyorsa stacked PR'da da zorlanacaktır
    • Ben Claude ile jj'yi birlikte kullanıp çalışma stack'ini trunk üzerinde inceleme dostu şekilde yeniden düzenletiyorum
    • Küçük branch'leri birbirine bağımlı hâle getirirsen, önceki branch güncellendiğinde senkronizasyon cehennemi doğuyor
    • İlgili ajan entegrasyonu rehberine web sayfasından bakılabilir

  • git-spice'a da bakmaya değer
    GitLab vb. ile uyumlu ve ben normal git komutları yerine tamamen git-spice kullanıyorum

  • GitHub'ın sonunda UI'a stack özelliği eklemesi güzel
    GitLab'ın glab stack özelliğine benziyor
    Yalnız merge süreci biraz tuhaf olabilir — stack'in alt kısmını merge edince geri kalanı rebase olur ve CI yeniden çalışır
    Üç patch'ten alttaki ikisini merge etmek istediğinde, her biri için test beklemen gerekir

    • Mevcut tasarımda, alttaki iki PR'ın CI'ı geçerse tek seferde merge edilebiliyor
      Sonrasında üstteki stack rebase ediliyor ve CI yeniden tetiklenebiliyor
      Dokümana bu kısmı daha açık yazmayı planlıyoruz

  • Ben stacked PR ihtiyacını pek anlamıyorum
    Git'te zaten patch set'leri ayrı ayrı inceleyip uygulayabilirsin
    PR modeli ise bunu tek bir paket hâline getiriyor
    Stacked PR da bu sorunu aşmak için eklenmiş başka bir soyutlama gibi duruyor

    • Çalıştığım takım PR'ı başlı başına “uygulanabilir en küçük birim” olarak görüyordu
      İç commit'ler sadece geliştirme geçmişi; merge edilirken hepsi squash ile tek bir şeye dönüştürülüyordu
      Böylece geliştirme sırasında özgürce commit biriktirip merge anında temiz bir değişiklik bırakabiliyorsun
    • Phabricator'da commit ile diff bire bir olduğu için çok daha doğaldı
      GitHub'ın uygulaması biraz sonradan eklenmiş bir özellik gibi hissettiriyor
    • PR zaten atomik değişiklik birimi; stacked PR ise bunun üstüne yeni PR'lar inşa etmeyi sağlıyor
      Yani işi incelemeye uygun birimler hâlinde aşamalı olarak yığma yapısı sunuyor

  • Graphite adlı bir startup zaten stacked PR'lara odaklanıyor
    Ben Graphite kullanıyordum; GitHub'ın da benzer bir şey yapması sevindirici

    • Şirkette de Graphite kullanıyoruz ve memnunuz

  • Stacked PR'ları seviyorum ama GitHub'ın bu uygulaması bana garip bir yaklaşım gibi geldi
    Bence her branch'in parent'ını göstermesi yeterli olurdu
    CLI'dan çok UI desteğine ihtiyaç var

    • Ama parent branch merge edildikten sonra rebase gerçekten acı verici
      CLI bu süreci otomatikleştirirse iyi olur
    • CLI isteğe bağlı; stacked PR'lar UI üzerinden de oluşturulabiliyor
      Branch zinciri kullanılmasının nedeni, diff'in yalnızca o branch'teki değişiklikleri göstermesi
    • Aslında bu orijinal git'te de mümkündü
      Sadece UI ve görselleştirme eksikti
    • Sıradaki adımın UI iyileştirmeleri olmasını umuyorum