28 Nisan 2026'da Mitchell Hashimoto, açık kaynaklı terminal emülatörü Ghostty'nin GitHub'dan ayrılacağını duyurdu. Hashimoto GitHub kullanıcısı 1299; Şubat 2008'den beri platformu neredeyse her gün kullandı. Ancak karar gününde bu geçmiş artık belirleyici değildi: kişisel günlüğünde zaten “neredeyse her gün bir X var” şeklinde kesintileri takip ediyordu ve aynı gün yaşanan GitHub Actions hatası PR incelemelerini iki saat boyunca engelledi. Kararı netti: “Her gün sizi saatlerce bloke ediyorsa, burası artık ciddi işler yapmak için bir yer değil.” Apidog'u bugün deneyin Geliştirici araçları geliştiriyorsanız bu duyuru yalnızca “bir proje GitHub’dan ayrılıyor” haberi değildir. Hashimoto, HashiCorp’u GitHub üzerinde kurdu; Terraform, Vagrant, Vault, Consul ve Boundary gibi araçları bu ekosistem üzerinden yayınladı. Bu profildeki bir kullanıcının dünyanın en baskın geliştirici platformundan güvenilirlik nedeniyle ayrılması, araç geliştiricileri için doğrudan bir uyarıdır: kritik yolda yer alıyorsanız, güvenilirlik özelliklerden önce gelir. Yapay zeka dönemi geliştirici araçlarının GitHub odaklı iş akışlarını nasıl değiştirdiğine dair arka plan için AGENTS.md dosyaları nasıl yazılır ve ekipler için GitHub Copilot kullanımı ve faturalandırma API'si yazılarına bakabilirsiniz. GitHub güvenilirlik boşlukları etrafında otomasyon geliştiren bir ekibin bakış açısı için Clawsweeper triage botu yazısı da iyi bir örnektir. Mitchell Hashimoto, 28 Nisan 2026'da Ghostty'nin GitHub'dan ayrılacağını duyurdu. Gerekçe özellik, fiyatlandırma veya politika değil; kronik GitHub Actions ve platform kesintileriydi. Duyuru gününde GitHub Actions hatası PR incelemelerini yaklaşık iki saat engelledi. Ghostty'nin GitHub deposu salt okunur yansıma olarak kalacak; aktif geliştirme aşamalı olarak başka bir platforma taşınacak. Hashimoto henüz hedef platform açıklamadı; ticari ve FOSS seçenekleri değerlendiriyor. Geliştirici araçları için ana ders: Kullanıcının kritik yolundaysanız, kesinti doğrudan güven kaybıdır. API ekipleri için uygulanabilir model: sağlayıcıdan bağımsız istemciler, mock sunucular, çoklu sağlayıcı testleri ve önceden hazırlanmış taşıma yolları. Duyuru gönderisi kısa ve doğrudan. Manifesto yok, Microsoft eleştirisi yok, yeni platform tanıtımı yok. Hashimoto’nun anlattığı zaman çizelgesi şöyle: GitHub kesintilerini kişisel günlüğüne kaydetmeye başladı. Günlük beklediğinden hızlı doldu. Yazıyı yazdığı sabah GitHub Actions hatası PR incelemelerini iki saat boyunca engelledi. Ghostty için GitHub’ın artık yeterince güvenilir olmadığı sonucuna vardı. Bu kararı tek bir kötü güne tepki olarak okumamak gerekiyor. 27 Nisan 2026’da Actions, paketler ve API yüzeyini etkileyen büyük bir GitHub kesintisi yaşandı; ancak Hashimoto’nun günlüğü bundan önce başlamıştı. Yani kararın nedeni tek olay değil, birikmiş paterndi. Geçişin sınırları da net: Ghostty ayrılıyor. Hashimoto’nun diğer projeleri şimdilik GitHub’da kalıyor. Ghostty deposu mevcut URL’de salt okunur yansıma olarak kalacak. Sorunlar, PR’ler ve CI dahil aktif geliştirme yeni platforma taşınacak. Hedef platform henüz açıklanmadı. Geçiş tek seferlik “bayrak günü” şeklinde değil, aşamalı yapılacak. Bu noktada önemli olan şey, şikayetin ürün yönüyle ilgili olmaması. Sorun şu: temel geliştirme altyapısı saatlerce çalışmadığında, üstündeki proje de çalışamıyor. Duyuruda çoğu kişinin sorduğu ilk soru şu oldu: Ghostty nereye taşınıyor? Daha önemli soru ise şu: GitHub gibi olgun bir platform, Hashimoto gibi uzun süreli ve yüksek profilli bir kullanıcının güvenilirlik nedeniyle ayrılacağı noktaya nasıl geldi? Bu duyuruyu klasik “X platformundan ayrılıyorum” yazılarından ayıran üç unsur var. Hashimoto yeni bir kullanıcı değil. Fortune 500 şirketlerinde kullanılan altyapı araçlarının arkasındaki isimlerden biri. GitHub'ın güvenilir olmadığını söylediğinde, bu mesaj yalnızca bireysel geliştiricilere değil, kaynak kodu stratejisi belirleyen ekip liderlerine ve CTO’lara da ulaşır. Sebep Copilot, Microsoft, yapay zeka eğitimi, fiyatlandırma veya politika değil. Sebep daha basit: Araç ihtiyaç duyulduğunda çalışmıyor. Geliştirici araçları için bu en kritik eksendir. Gönderi öfkeli değil. Daha çok, kalmak için uzun süre çabalamış bir kullanıcının yazdığı kısa bir olay sonrası raporu gibi. Bu da onu daha etkili kılıyor. Bir geliştirici aracı işletiyorsanız en kötü senaryo budur: kullanıcılarınız size kızmaz, sadece kesinti kayıtlarını sessizce biriktirir ve bir noktada ayrılır. Ürününüz bir geliştiricinin kritik yolundaysa, Hashimoto duyurusunu bir kontrol listesine dönüştürebilirsiniz. Son 90 gündeki tüm olayları çıkarın: durum sayfasına giren kesintiler, iç ekiplerin bildiği ama dışarıya yansımayan bozulmalar, yavaşlamalar, kuyruk gecikmeleri, bölgesel sorunlar, CI/CD başarısızlıkları. Sonra bunları en yoğun kullanıcılarınızın çalışma saatleriyle eşleştirin. Sorulacak pratik soru: En ağır kullanıcılarımız, bizi beklerken haftada kaç saat kaybediyor? Cevap sıfırdan büyükse, kullanıcı güveni aşınıyor demektir. Tekil kesinti önemlidir, ancak trend daha önemlidir. Şu metrikleri bileşen bazında izleyin: olay sayısı, ortalama çözüm süresi, tekrar eden olay oranı, kullanıcı etkisi süresi, iş saatlerinde gerçekleşen kesinti oranı. Basit bir tablo bile yeterlidir: Bileşen Bu Ay Olay Önceki Ay Olay Trend Actions 5 2 ↑ API 3 3 → Paketler 2 1 ↑ Web UI 1 4 ↓ SLA hâlâ tutuyor olabilir; ancak olay sıklığı artıyorsa güvenilirlik sessizce kötüleşiyor demektir. Kullanıcılar kendi günlüklerini genelde resmi sinyale güvenmediklerinde tutar. Durum sayfanızda yalnızca “büyük kesinti” değil, aşağıdakiler de görünür olmalı: belirli özellik bozulmaları, bölgesel yavaşlıklar, arka plan kuyruğu gecikmeleri, CI çalıştırıcı kapasite sorunları, API hata oranı artışları. İyi durum sayfası soğuk değil, sıcak çalışır: kullanıcı problemi yaşarken sinyal verir. %99,95 çalışma süresi iyi görünebilir. Ancak kesintiler hep müşterinin PR inceleme, deploy veya yayın saatlerine denk geliyorsa pratikte güvenilir değilsiniz. Örneğin: Toplam aylık kesinti: 2 saat Kesinti zamanı: Pazartesi 10:00-12:00 Müşteri iş akışı: Haftalık release hazırlığı Gerçek etki: Release gecikmesi Kullanıcı açısından bu “ayda 2 saat” değil, “release sırasında sistem çalışmadı” demektir. Hashimoto’nun en dikkat çekici cümlelerinden biri şu fikirdi: Projelerimi nereye koyacağım benim için hiç sorun olmamıştı: her zaman GitHub. Bu alışkanlık pahalıdır. Bir projeyi GitHub’dan taşırken yalnızca git geçmişini taşımıyorsunuz. Şunları da düşünmeniz gerekir: issues, pull request geçmişi, review yorumları, Discussions, Actions workflow dosyaları, secret yönetimi, CODEOWNERS kuralları, release artifact’leri, package registry, OAuth entegrasyonları, webhook’lar, bot izinleri, branch protection kuralları. Git deposunu klonlamak kolaydır: git clone https://github.com/org/project.git Ama issue geçmişini, PR review bağlamını ve CI kimlik bilgilerini aynı sadelikte taşıyamazsınız. Geliştirici aracı geliştiriyorsanız bu risk daha da büyür. Aracınız: GitHub Action olarak çalışıyorsa, Marketplace üzerinden dağıtılıyorsa, GitHub OAuth ile giriş yapıyorsa, GitHub Packages üzerinden paket yayınlıyorsa, aracınızın güvenilirliği GitHub’ın güvenilirliğine bağlı hale gelir. Kullanıcı kesintiyi yaşadığında çoğu zaman şunu ayırmaz: GitHub mı çöktü? Sizin aracınız mı çöktü? Entegrasyon mu çöktü? Kullanıcı açısından sonuç aynıdır: iş durmuştur. GitHub’ı “altyapının kendisi” olarak değil, “sağlayıcılardan biri” olarak modelleyin. Örnek arayüz: interface SourceProvider { listPullRequests(repo: string): Promise; getIssue(repo: string, id: number): Promise; createComment(targetId: string, body: string): Promise; } GitHub adaptörü: class GitHubProvider implements SourceProvider { async listPullRequests(repo: string) { // GitHub REST veya GraphQL API çağrısı } async getIssue(repo: string, id: number) { // GitHub issue çağrısı } async createComment(targetId: string, body: string) { // GitHub comment çağrısı } } Daha sonra GitLab, Forgejo veya başka bir sağlayıcı için aynı arayüzün arkasına adaptör ekleyebilirsiniz. class GitLabProvider implements SourceProvider { async listPullRequests(repo: string) { // GitLab merge request çağrısı } async getIssue(repo: string, id: number) { // GitLab issue çağrısı } async createComment(targetId: string, body: string) { // GitLab note/comment çağrısı } } Bu yaklaşım tüm geçiş maliyetini ortadan kaldırmaz, ancak sağlayıcı bağımlılığını kod tabanının her yerine yaymanızı engeller. Hashimoto hedef platform açıklamadı. Ancak Ghostty gibi açık kaynaklı bir proje için seçeneklerin şekli belli. Forgejo, Gitea’nın tamamen açık kaynaklı bir hard fork’u. Codeberg e.V. tarafından sürdürülüyor. FOSS uyumlu projeler için güçlü bir adaydır. Federasyon ve ActivityPub tarafında da ilerleme vardır. Codeberg, kar amacı gütmeyen bir kuruluş tarafından işletilen barındırılmış Forgejo örneğidir. Açık kaynak projeler için ücretsizdir. GitHub ölçeğinde bir Actions eşdeğeri henüz yoktur. GitLab güçlü CI/CD, olgun proje yönetimi ve ticari destek sunar. Birçok iş akışında GitHub’a doğrudan alternatif olabilir. Ancak lisanslama ve ürün yönü nedeniyle bazı FOSS toplulukları için tartışmalıdır. Sourcehut e-posta tabanlı iş akışını merkeze alır. Minimalist ve hızlıdır. Niştir, ancak kullanan geliştiriciler tarafından güçlü şekilde benimsenir. En yüksek kontrolü sağlar, ancak operasyonel sorumluluk da sizdedir. Yedekleme, güncelleme, güvenlik, izleme ve kapasite planlamasını siz yaparsınız. Radicle eşten eşe bir model sunar; merkezi ana bilgisayar yoktur. Federasyon argümanı burada güçlüdür, ancak büyük ve görünür projeler için hâlâ erken olabilir. Bu seçeneklerin hiçbiri GitHub’ın tüm yüzeyini birebir karşılamaz. Zaten ana nokta da bu: tek bir platform tüm geliştirme yığınını emdiğinde, ondan temiz şekilde ayrılmak yapısal olarak zorlaşır. Terminal emülatörü geliştirmiyor olabilirsiniz. Ancak API veya API aracı geliştiriyorsanız aynı model geçerlidir. Şu eşlemeyi yapın: GitHub Actions -> bağımlı olduğunuz yukarı akış API Issues / PR -> müşterinin size hata bildirdiği kanal GitHub kesintisi -> sağlayıcı kesintisi Temel soru değişmez: Müşterinizin işinin ne kadarı kontrol edemediğiniz bir hizmete bağlı? Bu riski azaltmak için üç pratik model kullanabilirsiniz. Yukarı akış API kapalıyken geliştirme durmamalı. Bu nedenle şu katmanlarda mock sunucu kullanın: yerel geliştirme, test paketi, CI, demo ortamı, hata senaryosu testleri. Basit bir örnek: { "id": "evt_123", "status": "processed", "amount": 1999, "currency": "USD" } Bu yanıtı canlı API’den beklemek yerine mock sunucuda tanımlarsanız, upstream kapalı olsa bile geliştirme devam eder. Apidog, aynı veri tanımlarından mock sunucu üretme modelini destekler. Canlı API’yi test etmek için kullandığınız şema, geliştirme sırasında mock yanıt üretmek için de kullanılabilir. Çok sağlayıcılı bir senaryonun pratik görünümü için GPT-5.5 API'si nasıl kullanılır yazısındaki OpenAI benzeri ekosistem karşılaştırmasına bakabilirsiniz. LLM veya API sağlayıcılarıyla çalışıyorsanız, tek sağlayıcıya bağlı kalmak operasyonel risk yaratır. Örneğin ürününüz şu sağlayıcılardan birini kullanıyor olabilir: OpenAI, Anthropic, Mistral, DeepSeek, Google, xAI. Benzer endpoint şekillerine sahip olsalar bile hata davranışları, hız limitleri ve yanıt formatları farklı olabilir. Test matrisinizi tek sağlayıcıyla sınırlamayın: providers: - openai - anthropic - mistral - deepseek CI’da aynı sözleşme testini her sağlayıcı için çalıştırın: PROVIDER=openai npm test PROVIDER=anthropic npm test PROVIDER=deepseek npm test Böylece “birincil sağlayıcı çöktü, biz de çöktük” yerine “yedek sağlayıcıya geçtik” diyebilirsiniz. Apidog ortam değişkenleriyle bu geçişi tek konfigürasyon değişikliğine indirebilirsiniz: BASE_URL=https://api.provider-a.example API_KEY=... veya: BASE_URL=https://api.provider-b.example API_KEY=... CI tamamen GitHub Actions üzerindeyse ve GitHub Actions çalışmıyorsa, yayın yapamazsınız. Minimum uygulanabilir önlem: kritik release job’larını ikinci bir çalıştırıcıda aynalayın, self-hosted runner seçeneğini test edin, manuel release yolunu belgeleyin, artifact üretimini tek platforma bağlamayın. Örnek basit manuel fallback: npm ci npm run test npm run build npm publish Bu komutlar belgelenmemişse, gerçek cevap şudur: CI kapalıysa release yapamıyoruz. Ücretli müşterisi olan bir araç için bu kabul edilebilir bir durum değildir. Yukarı akış sağlayıcı kesintilerine karşı daha dayanıklı bir API iş akışı şu şekilde kurulabilir: Apidog'u indirin. Bağımlı olduğunuz her yukarı akış API için ayrı proje oluşturun. İstek ve yanıt şemalarını bir kez tanımlayın. Bu şemalardan mock sunucu üretin. Kimlik bilgilerini ortam kapsamlı değişken veya sır olarak saklayın. Aynı istekleri dev, staging ve prod ortamlarında çalıştırın. Her release’te sözleşme testlerini çalıştırın. Desteklediğiniz her sağlayıcı için aynı test setini koşturun. Upstream bozulduğunda geliştirme ortamını mock sunucuya çevirin. Canlı servis dönene kadar ürün geliştirme ve test akışını durdurmayın. Örnek ortam modeli: dev: BASE_URL=https://mock.example API_KEY=mock-key staging: BASE_URL=https://sandbox.provider.example API_KEY=staging-key prod: BASE_URL=https://api.provider.example API_KEY=prod-key Bu model Ghostty’ye veya yapay zekaya özgü değildir. Dış bağımlılığı olan her API ekibi için geçerlidir. İlk tepkiler birkaç gruba ayrıldı. Uzun süredir GitHub kesintilerinden rahatsız olan güç kullanıcıları, bu gönderiyi kendi deneyimlerini görünür kılmak için bir işaret olarak gördü. Birçoğu zaten ikinci bir platforma yansıtma yapıyordu; gönderi bu yansıtmayı daha ciddi ele almalarına neden oldu. Bu grup GitHub’ın genel uptime rakamlarının hâlâ rekabetçi olduğunu savunuyor. Makro düzeyde haklı olabilirler. Ancak Hashimoto’nun vurgusu tek olay değil, olayların yönü ve sıklığıydı. Bu grup da haklı. GitHub’dan çıkmak yalnızca repo taşımak değildir. Issue, PR, CI ve kimlik yüzeyi maliyeti büyüktür. Hashimoto’nun salt okunur yansıma ve aşamalı geçiş planı bu nedenle mantıklıdır. Küçük projeler için hesap farklıdır. Hashimoto için saatlerce kesinti ciddi üretkenlik kaybıdır; hafta sonu projesi için yalnızca rahatsızlık olabilir. Ancak yansıtma gibi düşük maliyetli önlemler çoğu proje için yine de değerlidir. Aşağıdaki listeyi doğrudan uygulayabilirsiniz. Haftalık veya günlük mirror job kurun. git remote add mirror [email protected]:org/project.git git push mirror --mirror Forgejo, Codeberg veya GitLab kullanılabilir. Amaç hemen taşınmak değil; gerektiğinde çıkış yolunu hazır tutmaktır. Kötü örnek: import { GitHubClient } from "@vendor/github"; const prs = await github.listPullRequests(repo); Daha iyi örnek: const provider: SourceProvider = createProvider(process.env.SOURCE_PROVIDER); const prs = await provider.listPullRequests(repo); Bu sayede GitHub varsayılan kalabilir, ancak tek seçenek olmaz. Şu soruya yazılı cevap verin: CI çalışmıyorsa release nasıl yapılır? Belge örneği: ## Manuel Release 1. `main` branch'ini çek. 2. `npm ci` çalıştır. 3. `npm test` çalıştır. 4. `npm run build` çalıştır. 5. Versiyonu doğrula. 6. `npm publish` çalıştır. 7. Release notunu manuel yayınla. Bir tablo oluşturun: Servis Kritik mi? 4 saat kapalıysa ne olur? Fallback GitHub Actions Evet Release durur Self-hosted runner GitHub API Evet Bot çalışmaz Cache + retry Package registry Evet Yayın yapılamaz Manuel publish LLM provider Evet Özellik yavaşlar/durur İkinci sağlayıcı Boş kalan fallback alanları risk listesidir. Sadece uptime değil, olay sıklığı trendini de izleyin. Ay Olay Sayısı Ocak 2 Şubat 3 Mart 5 Nisan 8 Bu tablo SLA ihlali göstermeyebilir, ama geçiş planı hazırlamanız gerektiğini gösterebilir. API aracı özelinde çalışan bir örnek için sağlayıcı kesintilerinden kurtulan dayanıklı iş akışları oluşturma yazısı, DeepSeek ve OpenAI’yi ikili sağlayıcı örneği olarak kullanarak aynı modeli adım adım ele alır. Hashimoto duyuru gönderisinde hedef platform açıklamadı. Ticari ve FOSS sağlayıcılarla görüşmelerin sürdüğünü, geçişin aşamalı yapılacağını söyledi. Mevcut GitHub deposu salt okunur yansıma olarak kalacak. GitHub’ın genel uptime rakamları benzer platformlarla rekabetçi olabilir. Ancak Hashimoto’nun şikayeti genel yüzde değil, kritik yoldaki tekrar eden kısmi kesintilerdi. Actions, Paketler ve API yüzeyindeki kısa kesintiler bile PR inceleme, CI ve release akışlarını doğrudan durdurabilir. Çoğu ekip için hemen taşınmak gerekli olmayabilir. Ancak yansıtma neredeyse her zaman düşük maliyetli ve faydalıdır. Haftalık mirror job kurmak, tam geçiş kararı vermeden çıkış yolunu hazır tutar. Hashimoto’nun gönderisi Copilot’u özel olarak hedef almıyor. Ancak duyuru günündeki GitHub Actions kesintisi doğrudan tetikleyiciydi. Copilot ayrı bir ürün yüzeyidir ve güvenilirliği ayrıca değerlendirilmelidir. Copilot tarafındaki kullanım ve faturalandırma detayları için ekipler için GitHub Copilot kullanımı ve faturalandırma API'si yazısına bakabilirsiniz. GitHub API’sini saran inceleme botları, issue triage araçları veya MCP sunucuları GitHub’ın güvenilirlik profilini miras alır. Azaltma stratejisi aynıdır: önbellekleme, retry, açık hata durumları, mock upstream, sağlayıcı adaptörü, manuel fallback. Apidog mock sunucu modeli bu tür test ve geliştirme akışlarını daha dayanıklı hale getirmek için kullanılabilir. Çalışan bir örnek için Clawsweeper triage bot yazısı incelenebilir. Muhtemelen yavaş ilerleyen bir trendin işareti. Büyük projeleri GitHub’dan taşımak haftalar sürebilir; çoğu ekip bunu keyfi olarak yapmaz. Hashimoto gönderisinin önemi, uzun süreli ve yüksek profilli bir kullanıcının geçiş maliyetini ödemeye değer bulmasıdır. Başka geliştiricilerin günlük iş akışında kullandığı yazılımı geliştiren herkes. Buna şunlar dahildir: terminaller, editörler, CI araçları, API istemcileri, izleme araçları, paket kayıt sistemleri, review botları, yapay zeka kodlama yardımcıları. Müşteriniz geliştiriciyse ve aracınız onların kod yazma, test etme veya yayınlama yolunda duruyorsa, Hashimoto’nun güvenilirlik dersi doğrudan sizin için geçerlidir.