🌐 GitHub Pages: Static Deploy, Custom Domain ve SPA Fallback

GitHub Pages: Static Deploy, Custom: GitHub Pages, hazırladığın bir sergiyi vitrine koymak gibidir: ziyaretçi vitrindeki her şeyi görebilir, ama vitrinin arkasında yemek pişiren

GitHub Pages, hazırladığın bir sergiyi vitrine koymak gibidir: ziyaretçi vitrindeki her şeyi görebilir, ama vitrinin arkasında yemek pişiren bir mutfak yoktur — yalnızca önceden hazırlanmış (build edilmiş) dosyalar servis edilir. Peki site tarayıcıda sorunsuz açılıyorsa, "backend yok" olması pratikte neyi değiştirir? Şunu değiştirir: kullanıcı adı/parola doğrulamak, veritabanına yazmak veya bir API anahtarını gizli tutmak için sunucu tarafında çalışan bir kod gerekir — Pages’te böyle bir yer olmadığı için JavaScript’e gömdüğün her "gizli" anahtar aslında herkese açıktır. Java tarafında bunu şöyle düşün: Pages, çalışan bir Spring Boot uygulaması değil, `target/` altındaki statik çıktının yayınlanmış hâlidir. QA açısından en sık ısıran ayrıntı ise routing’dir: `/selenium` gibi temiz bir URL’e doğrudan girildiğinde sunucu o adı taşıyan bir dosya arar, bulamaz ve 404 döner — bu yüzden SPA’larda `404.html` fallback’i kurulmazsa, siteyi kendi laptop’unda kusursuz gezerken gerçek kullanıcı ilk paylaşılan linkte boş sayfa görür.

github-pages-settings-ui

GitHub Pages Settings ekranı: source, domain, HTTPS ve canlı site

Pages’in Settings içinde nerede olduğunu ve Visit site, Unpublish site, Source, Custom domain, Save, Remove, Enforce HTTPS kontrollerinin ne yaptığını gör.

Pages ekranındaki kontroller ne işe yarar?

Try It Yourself: Pages ayarını güvenli sırayla yap

GitHub Pages ekranında yayın kaynağı, custom domain ve HTTPS ayarlarını doğru sırayla yapmayı dene.

Repository üst menüsünden Settings tabına gir

Sol menüden Pages seç

Source olarak GitHub Actions seç

Custom domain alanını doldur

Domain ayarını kaydet

HTTPS zorlamasını aç

Canlı siteyi Visit site ile kontrol et