Geçen ay bir arkadaşım aradı. “Ya Aşkın, ben şu portfolyo sitemi yayınlamak istiyorum ama hosting fiyatları ne öyle?” dedi. Ona GitHub Pages’i anlattım — 20 dakikada sitesi yayındaydı. Üstelik tek kuruş ödemeden. O gün dedim ki bu konuyu mutlaka yazmalıyım, çünkü hâlâ çok sayıda geliştirici bu özellikten bihaber geziyor.

Bir şey dikkatimi çekti: Bakın, ben 20 yılı aşkın süredir BT sektöründeyim. Hosting işini en başından beri biliyorum — shared hosting dönemlerini yaşadım, VPS’lere geçişi gördüm, bulut devrimine de şahit oldum. Ama şunu net söyleyeyim: statik bir site yayınlamak için sunucu kiralamak artık, nasıl desem, biraz saçma kaçıyor. GitHub Pages tam da bu boşluğu dolduruyor ve bence hak ettiği kadar konuşulmuyor.

GitHub Pages Tam Olarak Ne ve Kimin İşine Yarıyor?

Kısa ve net söyleyeyim. GitHub Pages, GitHub üzerindeki herhangi bir repository’yi ücretsiz bir statik web sitesine dönüştürüyor. HTML, CSS, JavaScript — bunlarla çalışan herhangi bir proje. Hepsi bu. Arka planda sunucu yönetimi yok, veritabanı yapılandırması yok, SSL sertifikası derdi yok; GitHub hallediyor zaten bunları.

Size bir şey söyleyeyim, Peki kimin işine yarıyor? Aslında düşündüğünüzden çok daha geniş bir kitle var:

• Portfolyo sitesi kurmak isteyen geliştiriciler ve tasarımcılar
• Açık kaynak projelerinin dokümantasyon sayfaları (mesela birçok popüler kütüphane bunu kullanıyor)
• Blog yazmak isteyip WordPress’in karmaşıklığından kaçan insanlar
• Küçük işletmelerin basit tanıtım sayfaları
• Hatta — ve bunu 2022’de bir öğrenci grubuna danışmanlık yaparken bizzat gördüm — üniversite projeleri için sunum sayfaları

Tabi “statik” kelimesinin altını çizmek lazım burada. Veritabanı bağlantısı gerektiren, sunucu tarafında iş yapan dinamik uygulamalar buraya uygun değil. Ama Next.js gibi framework’lerin statik export özelliğiyle bile epey şey yapılabiliyor. Hani eskiden “statik site” denince akla sadece düz HTML gelirdi — artık öyle değil. Güzel bir değişim bu.

Başlamadan Önce: Üç Şey Yeterli

GitHub Pages’e deploy etmek için elinizde olması gereken şeyler şaşırtıcı derecede az:

Hesabınız yoksa github.com’dan ücretsiz oluşturabilirsiniz. Projeniz yoksa bile endişelenmeyin — tek bir index.html dosyası bile yeterli. Ben ilk GitHub Pages deneyimimi 2017’de tam olarak böyle yapmıştım. Tek satır:

. Sonra yavaş yavaş üstüne ekledim. Güldüm şimdi bunu yazarken.

Yöntem 1: Branch’ten Deploy Etmek (Kolay Yol)

İki farklı yöntem var. Hangisini seçeceğiniz projenizin karmaşıklığına bağlı — ama ilk yöntemi anlatayım, çünkü o en basiti. Build adımı gerektirmeyen, doğrudan HTML/CSS/JS dosyalarından oluşan projeler için birebir.

Adım Adım Kurulum

Repository’nize girdikten sonra şu adımları takip edin:

1. Üstteki menüden Settings sekmesine tıklayın
2. Sol menüde “Code and automation” bölümünün altında Pages‘i bulun
3. Build and deployment” altındaki açılır menüden Deploy from a branch seçin
4. Branch” kısmında main branch’ını seçin (ya da dosyalarınız hangi branch’teyse önü)
5. Save‘e basın

Bitti. Evet, gerçekten bu kadar. Birkaç dakika içinde siteniz https://kullaniciadi.github.io/repo-adi/ adresinde yayında oluyor. İlk seferinde “hani nerede acaba?” diye bekliyorsunuz — sabırlı olun, bazen 2-3 dakika sürüyor. Panik yapmayın.

Bu yöntemi Logosoft’ta bir iç eğitim portalı için kullanmıştık. 2023 yazıydı galiba. Basit HTML sayfalarından oluşan eğitim materyallerini bu şekilde yayınladık — herkes erişsin, güncellemesi kolay olsun istedik (ben de ilk duyduğumda şaşırmıştım). Mükemmel çalıştı… yanı mükemmel demeyeyim, gayet iyi çalıştı diyelim. E peki, sonuç ne öldü? Fazla abartmayayım.

Çok konuştum, örnekle göstereyim.

Branch’ten deploy en hızlı yoldur ama build adımı gerektiren projeler için (React, Next.js, Vue gibi) Actions" data-glossary-term="GitHub Actions">GitHub Actions yöntemi daha uygun. Projenize göre seçin.

Yöntem 2: GitHub Actions ile Deploy (Güçlü Yol)

Şimdi gelelim asıl eğlenceli kısma. Projeniz bir build süreci gerektiriyorsa — mesela Next.js, Gatsby, Hugo, Jekyll veya herhangi bir statik site generator kullanıyorsanız — GitHub Actions yöntemine geçmeniz gerekiyor.

Dur, önce şunu söyleyeyim. GitHub Actions’ı bilmiyorsanız, basitçe şunu bilin: repository’nizde belirli olaylar tetiklendiğinde (commit, PR, vs.) otomatik olarak çalışan iş akışları bunlar. CI/CD pipeline diye düşünebilirsiniz. Bu konuda blogumuzda GitHub Actions’ta 50 Yeniden Çalıştırma Sınırı: Sahada Ne Değişiyor? yazısına bakabilirsiniz — Actions’ın pratik taraflarını orada detaylıca ele almıştık zaten.

Next.js Projesi İçin Adım Adım

Settings > Pages sayfasında “Source” açılır menüsünden GitHub Actions‘ı seçin. GitHub size önerilen workflow’ları gösterecek. Next.js kullanıyorsanız: .NET Agent Skills: Üç Yöntem, Tek Sağlayıcı yazımızda bu konuya da değinmiştik.

1. Browse all workflows‘a tıklayın
2. Arama kutusuna “next.js” yazın (bu kritik)
3. Çıkan Next.js workflow’ünün yanındaki Configure butonuna basın
4. Workflow dosyasını inceleyin — genelde varsayılan ayarlar yeterli oluyor
5. Commit changes butonuna basın
6. Main branch’e commit yapıldığından emin olun ve onaylayın (bu kritik)

Commit yaptıktan sonra Actions sekmesine gidin, workflow’un tamamlanmasını bekleyin. Yeşil tık görünce — tebrikler, siteniz canlı.

Workflow Dosyası Neye Benziyor?

Vallahi, Merak edenler için tipik bir GitHub Pages workflow dosyasının iskeletini göstereyim:

name: Deploy Next.js to GitHub Pages
on:
push:
branches: ["main"]
workflow_dispatch:
permissions:
contents: read
pages: write
id-token: write
jobs:
build:
runs-on: ubuntu-latest
steps:
— name: Checkout
uses: actions/checkout@v4
— name: Setup Node
uses: actions/setup-node@v4
with:
node-version: "20"
— name: Install dependencies
run: npm ci
— name: Build
run: npm run build
— name: Upload artifact
uses: actions/upload-pages-artifact@v3
with:
path:./out
deploy:
runs-on: ubuntu-latest
needs: build
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
steps:
— name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4

Bu dosyada dikkat edilmesi gereken birkaç nokta var. permissions kısmında pages: write ve id-token: write yetkilerinin verilmesi şart — bunları eksik bırakırsanız deploy başarısız oluyor. Hata mesajı da pek açıklayıcı olmuyor bu arada. Bunu deneyimlerimden söylüyorum: 2024 başında bir kere 40 dakika bu yüzden hata aradım. Sınır bozucu.

İki Yöntemin Karşılaştırması

Hangisini ne zaman kullanmalısınız? Şöyle bir tablo hazırladım:

Küçük bir startup için hızlıca landing page yayınlıyorsanız — branch yöntemi gayet yeterli, valla yeter. Ama enterprise seviyede bir dokümantasyon portalı ya da sürekli güncellenen bir site kuruyorsanız, GitHub Actions bana kalırsa daha mantıklı. Hem her push’ta otomatik deploy oluyor, hem build sürecini istediğiniz gibi şekillendirebiliyorsunuz. Ciddi fark var ikisi arasında. Bu konuyla ilgili ChatGPT ile Araştırma: Search ve Deep Research Rehberi yazımıza da göz atmanızı tavsiye ederim.

Custom Domain ve HTTPS Ayarları

Ha bu arada önemli bir detay daha var. GitHub Pages varsayılan olarak kullaniciadi.github.io altında yayınlıyor. Kendi domain’ınızı de bağlayabilirsiniz (evet, doğru duydunuz). Bunun için Settings > Pages sayfasında “Custom domain” alanına domain adresinizi yazın. Sonra DNS sağlayıcınızda bir CNAME kaydı oluşturup kullaniciadi.github.io‘ya yönlendirin (ki bu çoğu kişinin gözünden kaçıyor). GitHub otomatik olarak Let’s Encrypt üzerinden SSL sertifikası sağlıyor. Ücretsiz.

Garip gelecek ama, Bu kısım beni açıkçası etkilemişti ilk keşfettiğimde —. SSL sertifikası derdi hosting’in en can sıkıcı parçalarından biriydi eskiden. “Enforce HTTPS” seçeneğini de mutlaka aktif edin. 2025’te HTTP üzerinden site yayınlamak (ciddiyim) — hmm, nasıl desem, pek hoş karşılanmıyor. — SEO açısından da güvenlik açısından da.

Sınırlamalar ve Dikkat Edilmesi Gerekenler

Şöyle söyleyeyim, Her şey güllük gülistanlık değil tabi. Açık konuşayım: GitHub Pages’in de eksikleri var ve bunları bilmek önemli.

Hani, Öncelikle repository boyutu için önerilen sınır 1 GB (ben de ilk duyduğumda şaşırmıştım). Site boyutu da (söylemesi ayıp) 1 GB’ı geçmemeli, aylık 100 GB bant genişliği sınırı var. Kişisel bir blog veya portfolyo için bunlar sorun olmaz ama yüksek trafikli bir site düşünüyorsanız — bu iş için uygun değil, başka bir çözüme bakmanız gerekiyor.

Bir de şu var. Özel (private) repository’lerden de Pages yayınlayabilirsiniz ama site kendisi her zaman public oluyor — yanı kodunuz private olsa bile sitenize herkes erişebilir (ben de ilk duyduğumda şaşırmıştım). Bu bazı kurumsal senaryolarda sorun olabiliyor (yanlış duymadınız). Logosoft’ta bir finans müşterimiz tam bu noktada “olmaz” demişti (ilk duyduğumda inanamadım). Haklıydı da, hassas içerik varsa dikkatli olmak lazım, tabiî ki. Copilot Cloud Agent Doğrulama Araçları %20 Hızlandı yazımızda bu konuya da değinmiştik. Bu konuyla ilgili PowerShell’de MSI Dönemi Bitiyor: MSIX’e Geçiş Rehberi yazımıza da göz atmanızı tavsiye ederim.

Bakın, garip gelecek ama, Dinamik içerik yok. Sunucu tarafı işlem yok. Form gönderimi için Formspree veya Netlify Forms gibi üçüncü parti servislere ihtiyacınız var. Bu konuda beklediğim kadar esnek değil açıkçası. Ama statik site generator’lar artık o kadar gelişti ki çoğu ihtiyacı karşılıyorlar — bu biraz teselli edici.

Copilot entegrasyonu konusunda da bir şey söyleyeyim — workflow dosyası oluştururken commit mesajını Copilot’a yazdırabiliyorsunuz. Küçük ama hoş bir detay. Bu konuda GitHub Copilot CLI Nedir ve Nasıl Kurulur: İlk Adımlar yazımıza da göz atmanızı öneririm.

Pratik İpuçları ve Sahadan Notlar

Açıkçası, Yıllar içinde öğrendiğim birkaç şeyi paylaşayım. Kısa tutacağım.

Yanı, 404 sayfası oluşturun. Repository’nizin kök dizinine 404.html adında bir dosya koyun — GitHub Pages bunu otomatik olarak hata sayfası yapıyor (ki bu çoğu kişinin gözünden kaçıyor). Kullanıcı deneyimi açısından fark yaratıyor, küçücük bir dokunuş ama değer (evet, doğru duydunuz)

İlginç olan şu ki, Jekyll kullanmayacaksanız boş bir .nojekyll dosyası ekleyin. GitHub Pages varsayılan olarak Jekyll işleminden geçiriyor dosyaları. Alt çizgiyle başlayan klasörleriniz varsa — mesela _next — bu sorun yaratır. Boş bir .nojekyll dosyası bunu devre dışı bırakıyor. Bunu öğrenmek bana bir projede yaklaşık 2 saat mal olmuştu; 2021’de bir Next.js projesinde sayfalar düzgün yüklenmiyordu, sorun buymuş. Sız ne dersiniz? Neyse, sız aynı hatayı yapmayın.

Şunu söyleyeyim, Branch yönteminde /docs klasörünü kullanabilirsiniz. Root yerine /docs klasörünü kaynak olarak seçebilirsiniz — proje kodunuz ile site dosyalarınızı ayrı tutmanın güzel bir yolu bu.

Sıkça Sorulan Sorular

GitHub Pages tamamen ücretsiz mi?

Evet, kişisel hesaplar dahil tüm GitHub hesapları için ücretsiz (buna dikkat edin). Aylık 100 GB bant genişliği ve 1 GB site boyutu sınırı var ama çoğu proje için bu fazlasıyla yeterli. Custom domain bağlamak da ekstra ücret gerektirmiyor (yanlış duymadınız)

GitHub Pages’te dinamik bir uygulama (PHP, Python) çalıştırabilir mıyım?

Hayır, GitHub Pages sadece statik dosyaları (HTML, CSS, JavaScript) destekliyor. Bir bakıma, sunucu tarafı işlem yapamıyorsunuz. Dinamik bir uygulama istiyorsanız App Service" data-glossary-term="Azure App Service">Azure App Service, Heroku veya Vercel gibi platformlara bakmanız gerekir.

Kendi domain adımı GitHub Pages’e nasıl bağlarım?

Settings > Pages’te “Custom domain” alanına domain adresinizi girin. DNS sağlayıcınızda bir CNAME kaydı oluşturup kullaniciadi.github.io‘ya yönlendirin. GitHub birkaç dakika içinde SSL sertifikasını otomatik sağlıyor. Daha açık söyleyeyim, “Enforce HTTPS” seçeneğini de aktif etmeyi unutmayın.

GitHub Pages sitemi private yapabilir mıyım?

Repository’niz private olsa bile GitHub Pages sitesi her zaman herkese açık yayınlanıyor (inanın bana). Eğer erişim kısıtlaması istiyorsanız GitHub Enterprise Cloud planında “access control” özelliği var. Bu ücretsiz planlarda mevcut değil.

Deploy ettikten sonra site neden görünmüyor?

İlk deploy’dan sonra birkaç dakika bekleyin — propagasyon süresi olabiliyor. Hâlâ görünmüyorsa Actions sekmesinden workflow loglarını kontrol edin. En sık karşılaşılan sorun .nojekyll dosyasının eksikliği veya yanlış branch seçimi oluyor.

Kaynaklar ve İleri Okuma

GitHub Pages Resmî Dokümantasyonu

GitHub Blog: Getting Started with GitHub Pages

Tuhaf ama, GitHub Actions ile Deploy Etme Kılavuzu

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

.NET 11 Preview 3: Gelen Yenilikler ve Sahadan Notlar16 Nis 2026

.NET ve PostgreSQL ile Azure’da Cache’i Ciddiye Almak4 May 2026

Copilot SDK: Ajanları Kendi Uygulamana Taşırken Ne Değişiyor?3 Nis 2026

AG-UI ile Çoklu Ajan Arayüzü: Gerçek Zamanlı Demo8 Nis 2026