Kendi GitHub’ımı Yapsaydım

 (matduggan.com)
5 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • GitHub, GitLab, Gitea gibi modern forge’lar GitHub tarzı modeli paylaşsa da, gerçek iş akışının merkezi gitten çok PR, Actions, Issues, Releases gibi forge özelliklerinin içinde gerçekleşiyor
  • Yeni bir forge, commit’ten sonra değil push’tan önce geri bildirim veren zorunlu pre-commit hook’ları uzaktan çalıştırabilmeli; böylece Feature, fix, actually fix, asdfasdf gibi tekrar eden commit’ler azaltılabilir
  • PR onayı, onay/red ikiliğinin ötesine geçip Gerrit’teki gibi zayıf onay ve daha sonra yeniden bakma işaretlerini desteklemeli; ayrıca yazar bakımcıysa ve LLM değişikliği düşük riskli görüyorsa küçük değişiklikler daha esnek biçimde geçebilmelidir
  • Stacked PR’lar, hem forge’un hem de VCS’nin birinci sınıf özelliği olmalı; yerel depo ise yalnızca kodu değil, PR onayları ve issue’lar dahil tüm depo durumunu ifade edebilmelidir
  • İstenen kombinasyon; VCS olarak JJ, küçük birimlerde barındırılabilen yeni bir forge ve imza, SHA, çevrimdışı çalıştırma desteği sunan Actions; ancak GitHub gibi tek ve dev bir forge’un varsayılan olduğu çağda hâlâ belirgin bir alternatif yok

Modern forge’ların sorunu

  • GitHub, GitLab ve Gitea ayrıntılarda farklılaşsa da neredeyse aynı tasarım modelini izliyor; daha çok GitHub’ın oluşturduğu sektör kalıplarının başka araçlara taşınmış hâli gibiler
  • Mevcut forge işlevlerinin büyük kısmının gitin kendisiyle doğrudan pek ilişkisi yok ve istemci, fiilî kullanım biçiminden kopuk durumda
  • git, çekirdek geliştirme gibi ortamlara uygun bir dağıtık sürüm kontrol sistemi; yamaların e-postayla bakımcılara gönderildiği, bakımcıların kendi alanlarını yönettiği ve birleştirip birleştirmemeye karar verdiği yüksek güvene dayalı iş akışları için elverişli
  • Ama çoğu iş yerinde git, daha çok merkezi forge’daki depodan kod çekme ve gönderme aracı; asıl önemli işler forge’un içinde oluyor
    • Pull Request, dört göz ilkesini zorunlu kılan bir araç hâline geliyor
    • GitHub Actions, Pull Request üzerinde test ve lint çalıştırarak işlevselliği ve kurumsal gereksinimlere uyumu doğruluyor
    • Forge içindeki kullanıcı kimliği, kullanıcıyı doğrulamanın ölçütü oluyor
    • Issues, kodla ilgili sorunları takip etmekte; Releases ise kullanıcıların indireceği sürümleri oluşturmada kullanılıyor
  • Bu iş akışlarında gitin kendisinden çok gitin üstüne kurulu forge özellikleri bulunduğu için, yeni bir forge yapılacaksa mutlaka git kısıtına bağlı kalma gereği azalıyor

Yeni bir forge’dan beklenen özellikler

  • Geri bildirim commit’ten sonra değil önce gelmeli

    • Yaygın bir PR’da Feature, fix, fix, actually fix, please, asdfasdf gibi commit’ler arka arkaya geliyor
    • Geri bildirim döngüsü commit’ten sonra kurulursa kullanıcılar geç saatlere kadar düzeltme yapıp yoruluyor
    • Forge, işleri uzaktan çalıştıran zorunlu pre-commit hook’lar sunmalı; böylece kullanıcı push etmeden önce geri bildirim alabilmeli

  • PR onayı fazla ikili yapıda

    • Bugünkü PR’lar ya onaylanmış ya da onaylanmamış sayılıyor, ama gerçek kod incelemesinde ikisi arasında pek çok alan var
    • “Şimdilik olur, sonra ele alalım” gibi insani tepkiler de düğmelerle ifade edilebilmeli
    • Gerrit bu konuda daha iyi bir model sunuyor
    • Bir bakımcı zayıf onay verirse, sonradan yeniden bakmak için işaretleme yapılabilmeli

  • PR politikaları daha esnek olmalı

    • Her değişikliğin dört göz incelemesine ihtiyacı yok; özellikle LLM’lerin bulunduğu bir ortamda bu daha da geçerli
    • Dört satırlık bir PR için kıdemli bir mühendisin sadece LGTM yazmasını beklemenin maliyeti fazla yüksek
    • Yazar bakımcıysa ve LLM bunu düşük riskli ya da risksiz görüyorsa, doğrudan ilerlemeyi daha kolay kontrol etmek mümkün olmalı

  • Stacked PR’lar birinci sınıf özellik olmalı

    • Stacked PR’lar incelemeyi ve anlamayı kolaylaştırır
    • VCS dışı araçlarla eklenen bir yan özellik değil, forge ve VCS içinde birinci sınıf vatandaş olarak ele alınmalıdır

  • Forge her şeyi yapmaya çalışmamalı

    • Issue takibi gerekli, ama muhtemelen Kanban panosu gerekli değil
    • Wiki’nin de gerekliliği şüpheli
    • Her özelliği içine alan araçların kalitesi sonunda düşer; özellik eklemek kolay olsa da bakım maliyeti, benimsenme oranından bağımsız biçimde sürer
    • Birisi bir yerde kullanmaya başladı mı, o özelliğe bağımlı kalınır

  • Barındırma birimi fazla büyük

    • GitHub Enterprise çalıştırmak büyük bir iş, GitLab çalıştırmak da hatırı sayılır bir yük
    • Bu ürünler çok sayıda hareketli parçadan oluşan karmaşık sistemler
    • Daha küçük, tekil barındırma birimleri oluşturulabilmeli ve bunlar bağlanarak tek bir organizasyon kurulabilmeli
    • Küresel federation şart değil ve her organizasyon için ayrı hesap açmak da kabul edilebilir; ama sistem, bir organizasyonun “Bu 12 Raspberry Pi benim organizasyonum” diyebileceği kadar esnek olmalı

  • Yerel depo yalnızca kodu değil tüm depoyu temsil etmeli

    • Yerel kopya, sadece kodu değil PR onayları ve issue’lar gibi tüm depo durumunu ifade etmeli
    • Kodu check-in yapılan aynı VCS içinde PR onaylamak mümkün olmalı
    • Issue’lar, yerel dosyalar arasında gezinir gibi incelenebilmeli

  • Her zaman tüm geçmişi saklama maliyeti ödenmemeli

    • Bir ekiple düzgün çalışmak zaten çevrimiçi olmayı gerektirdiğinden, herkese sürekli tüm depolama maliyetini yüklemek zorunda değiliz
    • VCS ile forge birlikte çalışmalı
    • Depo clone edilirken yalnızca sınırlı geçmiş alınmalı; daha eskiye gitmek istenince bir worker ayağa kalkıp gerekenleri VCS’den getirebilmeli
    • Kullanıcının bir gün tüm proje geçmişinden forge’u yeniden kurabileceği varsayımı uğruna, forge’a sürekli dev clone istekleri göndermek gerekmemeli

  • Actions imzalı olmalı, SHA taşımalı ve çevrimdışı da kullanılabilmeli

    • Actions kritik olduğu için imza, SHA ve çevrimdışı kullanım desteği gerekli
    • İstenirse tüm action tarball’ları indirilip depoya konabilmeli ve sisteme checkout action’ı dışarıdan almak yerine yerel depodakini kullanması söylenebilmeli
    • latest belirtildiğinde, bugünkü Dependabot’a benzer biçimde en yeni tarball’ı depoya ekleyen bir PR açılmalı
    • Actions, istenirse aynı VCS üzerinden yerel makinede de çalıştırılabilmeli

Bunun parçalarını yapan araçlar var ama kombinasyon gerekiyor

  • Bu gereksinimlerin bazılarını karşılayan araçlar zaten çok sayıda var
  • Gereken şey, bu araçları alıp bir araya getirmek ve doğru biçimde uyuşturmaktır
  • İstenen kombinasyon; VCS olarak JJ, forge olarak yeni bir sistem ve kullanıcıların tek bir Raspberry Pi’ı uzun süre memnuniyetle forge olarak kullanabileceği beklentisi
  • Yeni forge; nesne deposu, shallow clone ve LLM botlarının sürekli istekleri gibi modern kavramlar merkez alınarak tasarlanmalı

GitHub’ın varsayılan olduğu çağdaki çatlak

  • GitHub iyi gidiyor olsaydı, böyle bir tasarıyı yazmaya gerek kalmazdı
  • GitHub varsayılan seçenek ve insanları varsayılanın ötesine ikna etmeye çalışmak çoğu zaman zaman kaybına yakın
  • 2026’ya kadar bir forge kullanacaksanız, herkesin kullandığı aracı seçmemek için çok güçlü bir nedeniniz olması gerekiyordu
  • Yakın zamana kadar diğer forge’lar gerçekten istenen seçenekler değil, daha çok ikame ürünler gibi görülüyordu
  • Ama tek ve dev forge modeli çözülmeye başlıyor, yine de henüz gerçek bir alternatif ortaya çıkmış değil
  • Parası olanlar roketlerle meşgul, zevk sahibi olanlar asıl işleriyle meşgul; geri kalanlar ise gece yarısı asdfasdf adlı bir PR açıp robot kontrollerini beklerken, bütün gün kullandıkları aracın ne zamandan beri kullanıcılar için yapılmamaya başladığını sorguluyor

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Hacker News yorumları

  • PR onayının fazla ikili olduğuna yönelik eleştiri çelişkili görünüyor. PR onayı bir yetki verme işlemi, dolayısıyla sonuçta boolean olmak zorunda; kodu merge edebilirsiniz ya da edemezsiniz
    Burada kastedilen şey daha çok, sevmediğiniz kodu onaylarken “buna sonra tekrar bakmak lazım...” gibi sözlerle insanı biraz rahatlatan bir mekanizma. Onun yerine yeni bir ticket açmak yeterli

    • Gerrit'te -2 ile +2 arasında puanlar var
      -2: kötü fikir, yapılmamalı
      -1: iyi fikir ama iyileştirme gerekli
      +1: iyi görünüyor ama onay verecek bilgiye ya da yetkiye sahip değilim
      +2: onay
    • “Bu 3 commit şimdi onaylanıp merge edilsin, şu 2 tanesi ise yeniden çalışılsın” diyebilen bir düğme olmasını isterdim
    • Kod onaylanmış olsa da merge edilmeyebilir. Bu durumda bir yönetici değişiklikleri ekleyip elle uygulayabilir ve bu değişiklik commit'ine PR yazarını ortak yazar olarak ekleyebilir
    • Daha büyük sorun, GitHub'ın issue takip sistemiyle fazla kopuk görünmesi. Sürekli elle senkronize etme yükü çok fazla ve Linear bunu bir ölçüde çözse de ideal değil
    • “Kodu merge edebilirsiniz ya da edemezsiniz” demek, pek sezgici biri olmadığını düşündürüyor

  • “Y de bunların bir kısmını yapıyor” demek doğru, ama tangled.org bunların çoğunu gerçekten yapıyor

    1. Sürüm kontrol sistemi olarak JJ kullanıyor: tangled, jj change-id ile stacked PR destekliyor. https://blog.tangled.org/stacking tangled'ın kendisi de bu şekilde yoğun biçimde geliştiriliyor: https://tangled.org/tangled.org/core/pulls
    2. Raspberry Pi üzerinde uzun süre çalışabilecek bir forge: bu da mümkün. git sunucu shim'i son derece hafif; yalnızca git deposu üzerindeki bir XRPC katmanı ve bir sqlite3 veritabanı. Bunu 512MB RAM'li bir RISC-V kartta çalıştıranlar bile var
    3. Actions önemli ve yerel makinede çalışabilmeli: bence bu gereksinim biraz hedefi ıskalıyor. Kapalı, her yerde çalışabilen ve cross-build işlerini halleden yapıların görevi genelde build sistemidir. Böyle build çıktılarını forge'un içine “terfi ettirebilmek” gerçekten harika olurdu
    • İş akışında kritik verileri barındırmak için Raspberry Pi'ın anılması şaşırtıcı. Geçmişte SD kart bozulmasıyla çok uğraştım; artık NVME sürücü mü kullanılıyor diye merak ediyorum
    • Evet, bu build sisteminin işi. Ama insanların yerelde çalıştırılabilen Actions ile çözmek istediği sorunların çoğu doğrudan build hatası değil, tüm entegrasyon meselesi
      YAML tanımları, secret'lar, tam olarak hangi komutların çalıştırıldığı, araçların ve cache'in nasıl geri yüklendiği gibi konular. Build sistemi bunların bir kısmını ele alabilir ama GHA'nin sunduğu ilkel özellikler çok zayıf. Sonuçta tüm sistemi başka bir yerde çalıştırma problemine dönüyor; bu yüzden bu tür sistemler genelde deneme-yanılma ile ilerliyor gibi görünüyor
    • Evet, hatta daha da ötesi, kapalı build kavramının genişletilip yerelde ya da hesaplama kaynağı bulunan herhangi bir yerde kolayca çalıştırılabilmesi iyi olurdu
      Burada asıl söylenen sorun, değişiklikler, commit'ler ve ağ çağrıları içeren bir döngü içinde CI yeşile dönene kadar uğraşmanın çok acı verici olması. Bu yinelemeden kaçınmanın en iyi yolu hiç bug yazmamak! Şaka tabii
    • Radicle ve Tangled ikisi de asıl noktayı kaçırıyor. Bunlar kamusal işbirliği çalışmaları için; peki özel depolar ne olacak? Birçok kullanıcı yan proje yapıyor ve bunun için GitHub private kullanıyor
      GitHub'ı öğrenen biri, kamusal projelerini de GitHub'da başlatıyor. İnsanlara yan projeleri için özel depo oluşturma imkânı vermedikçe yaygınlaşmaları zor. İnsanların istediği şey, özel bir depo oluşturup aylarca uzak kaldıktan sonra geri döndüklerinde onun hâlâ orada kendilerini bekliyor olması
    • Vay be, Tangled'ın jujutsu desteği tam aradığım şeymiş. Bu hafta sonum self-hosted kurulumla geçecek gibi

  • Sadece sınırlı bir geçmişi clone'layıp gerekince eski verileri almak istiyorsanız blobless clone kullanabilirsiniz
    git clone --filter=blob:none
    Geçmiş gelir, blob'lar ise yalnızca gerektiğinde alınır. GitHub'ın bununla ilgili güzel bir yazısı var: https://github.blog/open-source/git/get-up-to-speed-with-par...

  • Çözümün kendisi sorun hâline gelirse, yıkıcı inovasyon için fırsat doğar. Son zamanlarda bu konuda epey konuşuluyor; GitHub yönünü düzeltmeden önce ortaya çıkan onca alternatiften biri ivme kazanacak mı merak ediyorum

    • Bence sorun, Microsoft'un yapay zekaya tamamen abanmış olması. Geri dönüş yok ve GitHub da bundan etkilenmek zorunda
      Microsoft'un tanıtımı yapay zekayı her şeyin çözümü gibi anlatacaktır ama gerçekte aynı sorunlar tekrar tekrar yaşanacak. GitHub kesintileri doğrudan yapay zekayla ilgili olmayabilir ama Microsoft'un stratejisi zaten değiştiği için kararların çoğu yapay zeka merkezli, tepeden inme kontrole göre şekillenecek. GitHub kullananların iş akışlarının bozulup bozulmaması Microsoft için olsa olsa ikincil bir mesele ve bu sorun tekrar tekrar ortaya çıkacak. Belki 3 ay kadar sessiz geçebilir ama çok geçmeden GitHub'ın gerilediğine dair yeni bir drama yüzde 100 yeniden çıkacak diye düşünüyorum. Ghostty son örnek olmayacak. Alternatiflerin çıkıp çıkmayacağını görmek ilginç ama o alternatiflerin kötü olmaması gerek; ne yazık ki birçok web sitesi oldukça kötü
    • Ben kendi araçlarımı kendim yapıyorum. İnsanların da kendi araçlarını kendilerinin yapması gerektiğini düşünüyorum
      Gelecekte ücretli ya da açık kaynak yazılım yerine, code forge için bir gereksinim dokümanları paketi, bir tür tarif alıyor olabiliriz. Herkes kendi fırınında pişirir, kullanımına ve zevkine göre değiştirir

  • Daha basit bir git hizmeti için pazarda boşluk olduğunu düşünüyorum. Gerekli olan tek şey, projeyi başkalarının görebilmesi için push edebileceğiniz uzak bir host; PR ya da Actions gibi şeyleri özellikle istemiyorum
    Yerelde derlenmiş binary varlıklarını yükleyebileceğimiz bir “release” özelliği olsa güzel olurdu. Fork işi de insanlar depoyu clone'layıp yeni proje olarak yükleyerek çözülebilir

    • Gerek olmayan özellikleri kapatınca bunların çoğu çözülmüyor mu? Az önce kendi Forgejo instance'ıma baktım; depo bazında Code, Projects, Releases, Packages, Actions, Issues, PRs, Wikis kapatma seçenekleri var
    • https://sr.ht/
    • O zaman yine cgit'e mi dönüyoruz?

  • İnceleme verilerinin de kaynak kod gibi bir git deposunda tutulabileceği fikri oldukça ikna edici
    Bilinen bir önek ekleyip her inceleme için bir branch açarak bunu oldukça kolay uygulayabilirsiniz ama varsayılan branch ad alanı kısa sürede karmakarışık olur. Bunu git namespace'leriyle ana ad alanından ayırabilir ya da .reviews gibi, her inceleme branch'inin uç commit ID'sini tutan özel bir branch kullanabilirsiniz. Birisi yeterince ilgi gösterip bir spesifikasyon ve gerçek kullanımda işe yarayan bir uygulama çıkarırsa insanlar bunu benimsemeye başlayabilir. GitHub ve diğer birçok forge'un bu yolu seçmemesinin nedeni muhtemelen inceleme meta verisini kendi ekosistemlerine kilitlemenin platform değeri yaratması. Eğer herkes istediği yerel araçlarla başkalarının kodunu inceleyebilirse sağlayıcıya bağımlılık azalır. Yine de erişim kontrolü ya da depolar arası inceleme gibi nedenlerle inceleme meta verisini başka bir depoda tutmak istemenin başka sebepleri de olabilir

  • PR yerine farkları inceleyen Gerrit iş akışını gerçekten seviyorum. Ama gitea gibi araçlarla kıyaslandığında, issue'lar, proje planlama gibi git hosting'den beklenen diğer özellikler eksik olduğu için birçok kişiyi ikna etmesi zor görünüyor
    Phabricator gibi iyi bir diff inceleme platformu olsa keşke

    • Ama neden Gitea bunu eklemiyor? Geri kalan her şey zaten var; bu forge'ların neden hep GitHub kopyası olarak kalıp daha ileri gitmediğini anlamıyorum

  • PR, inceleme yorumları, issue'lar gibi tüm mesaj saklama işlerinin temel biçimi olarak RFC2822 kullanılabilir ve mesajlar gösterilirken CommonMark ile biçimlendirilebilir diye düşünüyorum
    Tüm meta veri header'lara konur ve Message-ID/In-Reply-To/References header'larıyla birbirine bağlanabilir. Böyle iyi tanımlanmış bir biçim kullanırsanız, tüm mesajların nasıl saklanacağına ve taşınacağına siz karar verebilirsiniz. İsterseniz git deposuna koyar, isterseniz e-posta kullanır, isterseniz başka uygun bir yöntem seçersiniz. Kod inceleme konusunda kişisel olarak Gerrit'in GitHub ve benzerlerinden çok daha iyi olduğunu düşünüyorum. CI'ı olabildiğince dışarıda tutmak isterdim; yalnızca pipeline'ı başlatan, sonuçları gösteren ve merge'e izin verilip verilmeyeceğine karar veren hook'lar olsun yeter

    • Bence GitHub'ın çekiciliğinin bir kısmı, kod inceleme, kaynak gezintisi, ticket takibi ve CI olmak üzere dört şeyi tek yerde birleştirmesi
      Dördünde de olağanüstü iyi değil ama bunları bir araya getirmeyi iyi başarıyor. Gerrit'in daha iyi bir kod inceleme modeli sunduğuna katılıyorum ama diğer üç parça olmadan ortada ürün kalmıyor. Google'da her gün Gerrit kullandığım dönemde bile kod arama, kod inceleme ve CI arasındaki zayıf entegrasyon can sıkıcıydı. Google3/Critique/Forge gibi Google içi araçlar bunların hepsini çok daha iyi birbirine bağlıyordu

  • E-posta tabanlı iş akışlarının bir avantajı aklıma geldi. E-postalara bakmaya başladıysanız, genelde bunun için uygun bir zihinsel durumdasınızdır ve o durumda başka dikkat dağıtıcılar olmayacağını varsaydığınız için daha iyi odaklanırsınız
    Bildirimlerin sorunu, göründükleri anda onları ortadan kaldırmak istemenizdir. Ama o anda gerçekten bunu ele alacak enerjiniz olduğu garanti değildir. Web'deki çoğu bildirim sistemi, e-posta istemcilerinin onlarca yıl önce zaten başardığı şeyi beceriksizce taklit ediyor gibi görünüyor. Belki de eskiler e-posta kullanmakta gerçekten haklıydı

    • E-posta da bir bildirim sonuçta; geldiği anda buna nasıl uygun bir ruh hâlinde oluyorsunuz, biraz daha açıklar mısın

  • Microsoft GitHub'ı içine kattığında birçok kişi zaten rahatsız olmuştu. Ama pratikte alternatifler sık sık kötüydü. Sourceforge'da issue açmak bitmek bilmeyen bir eziyet, GitLab Sourceforge'dan iyi ama orada da issue açmaktan hoşlanmıyorum. Codeberg yakın zamanda arayüzünü değiştirmiş gibi görünüyor ama hâlâ oldukça kullanışsız
    GitHub'ın başta iyi yaptığı şey, arayüze ve GitHub kullanan insanların ihtiyaçlarına odaklanıp işleri kolay ya da daha kolay hâle getirmesiydi. Elbette her şeyi iyi yapmadı; örneğin wiki desteğinin korkunç olduğunu düşünüyorum. O kadar kötü ki neredeyse hiç wiki kullanmıyorum. Asıl büyük sorunun ticari çıkarlar, yani özel çıkarlar olduğunu düşünüyorum. Microsoft sadece bir örnek; benzer sitelerin neredeyse hepsinde aynı sorun var. Daha önce xz backdoor aracıyla ilgili bir issue tartışmasını örnek vermiştim ve ben de o tartışmaya katılmıştım; ertesi gün Microsoft hepsini kaldırdı. Bunu Microsoft mu yaptı yoksa depo sahibi mi, çok önemli değil. Sorun, tek bir kişinin potansiyel olarak yararlı bilgiyi çok kolay sansürleyebilmesi. O issue tartışması faydalıydı ve sansürlendi. O sırada tüm bilginin geri getirilmediğini hatırlıyorum. Belki birileri mirror almıştır ama bağlantısını görmedim. Bu, tepeden inme kontrolün gerçekten zararlı olabileceğini gösteriyor. Açıkçası Microsoft'a ne kadar güvenilebilir? Merkeziyetsiz, istikrarlı çalışan, varsayılan arayüzü iyi olan ve basit ya da en azından iyi bir iş akışı sunan bir şeye ihtiyaç var. Ayrıca özel aktörlerin herkesi rehin alabileceği bir durumdan da kaçınmak gerek. Bunun nasıl çözüleceğini hiç bilmiyorum; belki aynı anda birkaç farklı yaklaşım gerekir. Web değişti ve özellikle devasa şirketlerin özel çıkarları son 10-15 yılda durumu çok daha kötüleştirdi gibi geliyor. Bunun değişmesi lazım

    • Sorun, SaaS ürün işletmenin çok pahalı olması
      Büyük şirketler bu maliyeti karşılayabiliyor ama bütçesi küçük çok sayıda geliştirici bir araya gelse bile aynı işi finanse edecek parayı bulamıyor. Bu yüzden herhangi bir ticari proje, eninde sonunda ortalama bir insandan çok büyük şirketlerin çıkarlarını destekleyen bir yöne kaymak zorunda kalıyor