Stacked pull requests: GitHub’da yığın nasıl kurulur ve incelenir

Yığın nedir, ne işe yarar?

Büyük bir özelliği tek pull request’te açtığınızda inceleyen kişi yüzlerce satırı bir arada görür. Yığılmış pull request’ler (stacked pull requests) aynı işi sıraya dizilmiş küçük pull request’lere böler. Bu sıraya yığın (stack), içindeki her pull request’e katman (layer) denir.

GitHub’ın tanımına göre yığın, aynı depodaki iki ya da daha fazla pull request’ten oluşur. En alttaki, yığının ana dalını (trunk) hedefler; bu çoğunlukla main’dir ama bir sürüm dalı da olabilir. Sonraki her pull request, bir altındakinin dalını hedefler. Bir pull request’in hedeflediği dala da onun tabanı (base) denir.

Her pull request yalnızca kendi katmanının diff’ini gösterir: kendi dalı ile bir altındaki dal arasındaki farkı. Sırayı tek bir kural belirler: bir katmanın ihtiyaç duyduğu kod ya aynı dalda ya da daha alttaki bir dalda olur. Ortak tipler ve veritabanı şeması alta, onları kullanan API uçları ve arayüz üste gelir.

Bunun iki faydası var. GitHub’ın belgesine göre küçük bir pull request daha hızlı incelenir; üstünkörü okunması, eskimesi ya da çakışmaya girmesi de daha az olasıdır. Ayrıca sıradaki değişikliğiniz henüz merge edilmemiş bir işe dayanıyorsa onu beklemeniz gerekmez: üstüne yeni bir pull request açarsınız. Kodu bir yapay zekâ ajanı yazıyorsa sıra zaten kendiliğinden çıkar: her görev bir katman olur.

Dalları elle zincirlemek yeni değil; yeni olan, GitHub’ın zinciri tanıması. Özellik 30 Temmuz 2026’da açık önizlemeye girdi, 6 Ekim 2026’da genel kullanıma açıldı; duyuruya göre github.com’daki bütün planlarda kullanılabiliyor.

Özelliğin yaptıklarını GitHub’ın kendi belgelerinden, 14 Ekim 2026 günü okuduğumuz hâliyle aktarıyoruz. Biz pull request inceleyen bir araç, diffox’u yapıyoruz; yerleşik destek gelmeden önce kendi depomuzda yığını elle kurduk. Orada öğrendiklerimiz aşağıda ayrı bir bölümde.

GitHub’da yığın nasıl kurulur?

Komut satırı için GitHub CLI’ın gh stack eklentisi var. Dalları doğru sırayla oluşturur, rebase eder, push eder, pull request’leri açıp yığın olarak birbirine bağlar. Üç katmanlı bir yığın şöyle kurulur:

gh extension install github/gh-stack

gh stack init auth-layer       # ilk dal, ana dalın üzerinde
git add .
git commit -m "Kimlik doğrulama katmanı"

gh stack add api-endpoints     # ikinci dal, ilkinin üzerinde
git add .
git commit -m "API uçları"

gh stack add frontend          # üçüncü dal
git add .
git commit -m "Arayüz"

gh stack submit                # push eder, pull request’leri açar, yığına bağlar
gh stack view                  # dalları, pull request’leri ve durumlarını gösterir

gh stack submit her pull request’i doğru tabanla açar: ilk dal main’i, sonraki her dal bir altındakini hedefler. Ana dalınız main değilse gh stack init --base release auth-layer yazın. Eklentiyi kullanmak zorunda değilsiniz; aynı yığını başka yollarla da kurabilirsiniz:

• Web arayüzü. İlk pull request’i her zamanki gibi açın. İkincisinin tabanını ilkinin dalı yapın ve “Create stack” seçeneğini seçin. Açık pull request’lerinizin tabanları zaten bir zincir oluşturuyorsa GitHub bunu fark eder ve onları yığına çevirmeyi öneren bir bant gösterir.
• Kodlama ajanı. gh skill install github/gh-stack, ajana gh stack ile çalışmayı öğreten beceriyi (skill) kurar; GitHub örnek olarak Copilot’u veriyor.
• Başka araçlar. Dallarınızı Jujutsu, Sapling ya da git-town ile yönetiyorsanız gh stack link komutu aynı dalları GitHub’da yığın olarak açar.

Yığındaki bir pull request’in sayfasında yığın haritası (stack map) görünür. Harita yığındaki bütün pull request’leri ve durumlarını gösterir, istediğiniz katmana tek tıkla geçmenizi sağlar; ana dal haritanın en altındadır.

Dal koruma kuralları ve CI yığında nasıl çalışır?

Elle kurulan zincirin zayıf noktası kurallardı. Üst katmanlar main’i değil, bir özellik dalını hedefler. GitHub’ın belgesi de yerleşik destek olmadan dal koruma kurallarının ve CI kontrollerinin çoğu zaman yalnızca en alttaki pull request’te çalıştığını yazıyor.

Yerleşik yığında ise her pull request, doğrudan hangi dalı hedeflerse hedeflesin, ana dalın kurallarıyla değerlendirilir. Başvuru sayfası dört kural sayıyor: zorunlu inceleme onayları, zorunlu durum kontrolleri, CODEOWNERS ve code scanning.

GitHub Actions da aynı mantığı izler. main’i hedefleyen pull_request olaylarıyla tetiklenen bir workflow, yığındaki her pull request için koşar; workflow dosyasında bir şey değiştirmeniz gerekmez.

Dikkat etmeniz gereken şey CI kullanımı: workflow her pull request için bir kez koştuğundan büyük bir yığın CI kullanımını katlar. Pahalı işleri yalnızca bazı katmanlarda koşturabilmeniz için yığının bilgileri workflow ifadelerinde hazır; belgeye göre github.event.pull_request.stack altında yığının boyutu (size) ve pull request’in sırası (position) bulunur. İkisi eşitse en üst katmandasınız.

Yığın nasıl merge edilir?

Yığın alttan yukarıya doğru merge edilir. Henüz merge edilmemiş en alttaki pull request’ten başlayarak, arada boşluk bırakmadan istediğiniz kadarını birlikte merge edebilirsiniz. Ortadaki bir pull request’i tek başına merge edemezsiniz; altındakiler de onunla birlikte merge edilir.

Belgeye göre bir pull request’in merge edilebilmesi için üç koşul aranır: pull request ana dalın bütün koruma şartlarını karşılamalı, altındaki her pull request de bunları karşılamalı ve dallar arasındaki geçmiş doğrusal olmalı. Alttaki dallardan birine yeni bir commit gelirse ya da ana dal ilerlerse geçmiş doğrusal olmaktan çıkar. O zaman merge kutusunda “Rebase stack” düğmesi çıkar; komut satırındaki karşılığı önce gh stack rebase, sonra gh stack push’tur.

Üç merge yöntemi de destekleniyor: merge commit, squash ve rebase. Squash’ta her pull request ana dala tek bir commit olarak girer; üç pull request, üç commit demektir. Merge’den sonra sıradaki pull request kendiliğinden rebase edilir ve artık doğrudan ana dalı hedefler. Yerel dallarınızı gh stack sync --prune günceller: ana dalı ileri alır, kalan dalları onun üzerine taşır ve merge edilmiş yerel dalları siler.

Merge queue (birleştirme kuyruğu) kullanan depolarda yığındaki pull request’ler kuyruğa doğru sırayla girer. Biri kuyruktan çıkarılırsa üstündekiler de çıkar.

Yığını elle kurduğumuzda üç yerde takıldık

Ağustos 2026’da, yerleşik destek henüz yokken, kendi depomuzda iki katmanlı bir yığını elle kurduk. Depomuzda merge’ler squash ile yapılıyor. Alttaki pull request merge edilince üstteki için üç şeyi elle yapmak zorunda kaldık.

Birincisi rebase’ti. Squash, alt dalın commit’lerini tek bir yeni commit’te toplar; eski commit’ler ana dalın geçmişine girmez. Üst dal o commit’leri hâlâ taşıdığı için ana dalla düz bir merge çakışma verdi. Sorunu git rebase --onto çözdü: yalnızca üst pull request’in kendi commit’lerini taşır. İkincisi tabandı: üst pull request alt dalı hedeflemeye devam etti, biz de onu elle ana dala çevirdik.

Üçüncüsü sessizdi. Ne force-push ne de taban değişikliği, rebase edilmiş dalın yeni ucu için CI’ı başlattı. Sayfadaki yeşil işaretler bir önceki uçta koşmuş kontrollere aitti. CI ancak pull request’i kapatıp yeniden açınca başladı.

# alttaki pull request squash ile merge edildi; üst daldasınız
git fetch origin
git rebase --onto origin/main <alt-dalın-eski-ucu>
git push --force-with-lease

# üst pull request’in tabanını ana dala çevirin
gh pr edit 123 --base main

# kontrollerin koştuğu commit, dalın ucuyla aynı mı
gh pr view 123 --json headRefOid
gh run list --branch api-endpoints --json headSha,workflowName,conclusion

Benzer bir tuzağı başka bir pull request’te gördük. Pull request tabanıyla çakışınca GitHub, workflow’ların koştuğu merge commit’ini oluşturmadı ve on bir kontrolden on tanesi hiç başlamadı. Sayfada yine de “All checks have passed · 1 successful check” yazıyordu; çünkü koşan tek kontrolün o commit’e ihtiyacı yoktu. Bu kural GitHub’ın belgesinde yazıyor: çakışması olan bir pull request’te pull_request workflow’ları koşmaz.

GitHub bu adımlardan hangilerini üstleniyor?

Bu adımları GitHub’ın belgeleriyle karşılaştırınca ortaya şu tablo çıkıyor.

“Elle kurulan dal zinciri” sütununda rebase, taban ve kontroller satırları kendi deneyimimizden, kurallar satırı GitHub’ın belgesinden. “GitHub’ın yerleşik yığını” sütununun kaynağı GitHub’ın belgeleri, 14 Ekim 2026.

Belgeye göre rebase ve taban işini artık GitHub üstleniyor. Squash konusunda gh stack’in kendi belgesi bizim yaşadığımızı anlatıyor: squash’tan sonra eski commit’ler ana dalın geçmişinde yer almaz; gh stack sync bu durumu fark eder ve --onto ile rebase eder.

Kontroller için belge iki durumu açıkça yazıyor: “Rebase stack” düğmesinden ve gh stack push’tan sonra CI yeniden başlar. Kısmi bir merge’ün ardından gelen otomatik rebase için böyle bir cümleyi 14 Ekim 2026 günü belgelerde bulamadık. Bu yüzden bir üst katmanı merge etmeden önce şu dört şeye bakmakta fayda var.

Yığın nasıl incelenir?

Yığında önünüze tek büyük bir diff gelmez; her biri bir altındakine göre okunan küçük diff’ler gelir. Bu, inceleyen kişi için üç şey demek.

• Alttan başlayın. Katmanlar birbirine sıkı sıkıya bağlıysa GitHub’ın önerisi incelemeyi en alttan istemek; çünkü alttaki bir hata üstündeki bütün dallara taşınır. Katmanları farklı kişiler inceliyorsa aynı anda da ilerleyebilirler.
• Üst katmanın diff’inde alt katmanın kodunu aramayın. Üçüncü katmanın çağırdığı bir fonksiyon birinci katmanda tanımlandıysa diff’te görünmez, main’de de henüz yoktur. Ama incelediğiniz dalda vardır; yığın haritası sizi o katmanın pull request’ine götürür.
• Bulguyu ait olduğu katmana yazın. Belgeye göre düzeltme, değişikliği içeren dalda yapılır, sonra üstteki dallar rebase edilir. Diff değişmediyse rebase var olan onayları düşürmez.

gh stack checkout auth-layer   # düzeltmenin ait olduğu katman
git add .
git commit -m "Süresi dolmuş token durumunu ele al"
gh stack rebase --upstack      # üstteki dalları bu commit’in üzerine oturtur
gh stack push                  # dalları --force-with-lease ile gönderir

Bu kurallar inceleyen bir insan için de, bir yapay zekâ inceleme aracı için de geçerli: ikisi de katmanın diff’ini okur. Bir katmanı onaylamak, altındakileri onaylamak anlamına gelmez; her pull request’in kendi zorunlu onayı ve kontrolleri vardır.

Her değişiklik yığın gerektirmez

Yığın, birbirine dayanan ve tek oturuşta incelenemeyecek kadar büyük işler içindir. Şu durumlarda tek bir pull request ya da birbirinden bağımsız pull request’ler daha iyi olur:

• Değişiklik küçükse. Tek oturuşta okunabilen bir diff’i bölmek, inceleyen kişiye yalnızca fazladan sayfa açtırır.
• İşler birbirine dayanmıyorsa. Yığın tek bir doğrusal zincirdir: her dalın bir altı, en çok bir üstü olur. İlgisiz bir düzeltme için ayrı bir pull request açın.
• Katkı fork’tan geliyorsa. Bütün dallar aynı depoda olmalıdır; fork’lar arasında yığın kurulamıyor.
• CI pahalıysa. Her katman kendi kontrollerini koşturur; önce pahalı işleri belirli katmanlarla sınırlayın.

14 Ekim 2026 günü okuduğumuz belgelerde üç sınır daha var. GitHub Desktop yığını desteklemiyor. Merge’ü API üzerinden yapan araçların eşzamansız merge API’sine geçmesi gerekiyor. Auto-merge konusunda iki sayfa farklı şey söylüyor: merge belgesine göre yığında desteklenmiyor, 6 Ekim duyurusuna göre ise önümüzdeki haftalarda gelecek.

diffox, kendisine verilen pull request’in diff’ini inceler. Yığında her katman ayrı bir pull request olduğu için her biri ayrı incelenir ve bulgular o katmanın pull request’ine yazılır.