M">
GitHub Yayın: 17 Temmuz 2026 8 dk okuma

GitHub README İçin Markdown İpuçları: Profesyonel bir dosya nasıl yazılır

Bir açık kaynak projesinin ilk izlenimi neredeyse her zaman README.md dosyasıdır. Aynı temel markdown sözdizimiyle yazılsa da, GitHub'a özgü birkaç teknik — rozet, katlanabilir bölüm, dil etiketli kod bloğu — sıradan bir dosyayı profesyonel görünen bir projeye dönüştürür. Bu rehberde açık kaynak projelerin en çok kullandığı 10 pratik ipucunu örneklerle inceliyoruz.

GitHub markdown ipuçları nedir?

Kısa cevap GitHub, standart GitHub Flavored Markdown (GFM)'in üzerine README dosyalarında özel olarak render edilen birkaç ek özellik sunar: rozet görselleri, ham HTML <details> ile katlanabilir bölümler, dil etiketli kod blokları için otomatik sözdizimi vurgusu ve başlıklardan otomatik üretilen çapa (anchor) bağlantıları. Bu ipuçları temel markdown bilginize eklenen, GitHub'a özgü katmandır.

Bu tekniklerin hiçbiri "gizli" değildir — hepsi GFM'in izin verdiği ham HTML ve görsel sözdizimi kombinasyonlarıdır. Farkı yaratan, bunları doğru yerde ve doğru sırada kullanmaktır. Önce temel markdown sözdizimine hakim değilseniz "Markdown Nedir, Nasıl Yazılır?" rehberimizle başlamanızı öneririz.

1-2. Rozet (badge) ekleme

Kısa cevap Rozet, aslında sıradan bir markdown görselidir: ![etiket](rozet-url). shields.io gibi servisler build durumu, sürüm numarası, lisans veya indirme sayısı gibi bilgileri anlık olarak bir görsele dönüştürür; siz sadece o görsel URL'sini görsel sözdiziminde kullanırsınız. Genellikle birden fazla rozet üst üste, başlığın hemen altına dizilir.
Rozet örneği
![Lisans](https://img.shields.io/badge/lisans-MIT-brightgreen)
![Sürüm](https://img.shields.io/badge/sürüm-2.1.0-blue)
![Build](https://img.shields.io/badge/build-geçti-success)

İpucu 2: Rozeti tıklanabilir yapmak için bağlantı sözdizimiyle sarmalayın: [![etiket](rozet-url)](hedef-url). Örneğin bir "Build" rozetini CI/CD panelinize, "Sürüm" rozetini ise sürüm notları sayfasına yönlendirebilirsiniz — kullanıcı rozete tıkladığında ilgili detay sayfasına gider.

3-4. Dil etiketli kod bloğu ve klavye kısayolu

Kısa cevap Üçlü ters tırnaktan hemen sonra dil adını yazarsanız (ör. ```bash, ```python, ```json) GitHub o dile özel sözdizimi vurgusu uygular ve kod bloğunun sağ üst köşesinde otomatik bir kopyalama butonu görünür. Dil belirtilmezse kod düz metin renginde kalır.
Dil etiketli kod bloğu
```bash
npm install proje-adi
npm run build
```

İpucu 4: Klavye kısayolu belirtmek için <kbd> HTML etiketi kullanılabilir — GitHub bunu bir tuş görseline benzer şekilde render eder: <kbd>Ctrl</kbd> + <kbd>C</kbd>. Kurulum adımlarında komut satırı kodunu her zaman dil etiketiyle yazmak, README'nizi teknik olarak daha güvenilir gösterir.

Rozet ve kod bloklarını şimdi deneyin

Yukarıdaki örnekleri kopyalayıp editöre yapıştırın, kendi README taslağınızda nasıl göründüğünü canlı izleyin.

Markdown Önizleyiciyi Aç →

5-6. Katlanabilir bölüm ve otomatik içindekiler

Kısa cevap Uzun içerikleri (SSS, ayrıntılı hata logları, ekran görüntüsü galerisi) ham HTML <details><summary> etiketleriyle sarmalayarak varsayılan olarak kapalı, tıklanınca açılan bir bölüm oluşturabilirsiniz. GitHub markdown içinde temel HTML etiketlerine izin verdiği için bu doğrudan çalışır.
Katlanabilir bölüm
<details>
<summary>Kurulum sırasında hata mı aldınız? Tıklayın</summary>

1. Node.js sürümünüzü kontrol edin (18+ gerekli)
2. `node_modules` klasörünü silip yeniden yükleyin
3. Hâlâ sorun varsa bir issue açın

</details>

İpucu 6: GitHub, her ## ve ### başlığından otomatik olarak bir çapa (anchor) kimliği üretir — başlığı küçük harfe çevirip boşlukları tire yapar. Bu yüzden kendi içindekiler listenizi [Kurulum](#kurulum) gibi bağlantılarla elle yazabilirsiniz; ekstra bir eklenti gerekmez. Uzun README'lerde (300+ satır) bu içindekiler listesi okunabilirliği ciddi ölçüde artırır.

Katlanabilir bölüm içinde markdown kullanmak

Dikkat: <details> içinde markdown'ın (liste, kod bloğu, kalın metin) doğru render edilmesi için etiketin hemen altına boş bir satır bırakmanız gerekir. Boş satır bırakmazsanız GitHub içeriği ham metin olarak, biçimlendirmeden gösterebilir.

7-8. Görsel boyutlandırma ve tema-duyarlı görsel

Kısa cevap Standart ![alt](url) sözdizimi görsel boyutunu kontrol etmenize izin vermez. Boyutu ayarlamak için ham HTML <img src="url" width="480"> etiketi kullanılır. Açık/koyu temaya göre farklı görsel göstermek için ise GitHub'ın <picture> + prefers-color-scheme desteğinden yararlanılır.
Boyutlu görsel
<img src="ekran-goruntusu.png" width="480" alt="Uygulama arayüzü">

İpucu 8: Logo gibi görselleri koyu ve açık GitHub temasında da okunaklı göstermek için <picture> etiketiyle iki farklı kaynak tanımlayabilirsiniz — GitHub, kullanıcının aktif temasına göre doğru görseli otomatik seçer. Bu, özellikle şeffaf arka planlı logo dosyalarında görünürlük sorununu tamamen çözer.

9-10. İskelet yapı ve lisans bölümü

Aşağıdaki tablo, üzerine oturacağınız temel bir README iskeletinin bölümlerini ve amacını özetler — projenizin büyüklüğüne göre bazı bölümleri çıkarabilir veya birleştirebilirsiniz.

Önerilen README iskeleti — bölüm sırası
SıraBölümAmaç
1Başlık + rozetlerProje adı ve anlık güven sinyalleri
2Tek cümlelik açıklamaZiyaretçi 5 saniyede ne olduğunu anlar
3Kurulum kod bloğuKopyala-yapıştır ile çalışır hale getirme
4Kullanım örneğiTemel senaryoyu gösteren kısa kod
5İçindekiler (uzun README'lerde)Hızlı gezinme
6SSS (katlanabilir)Sayfayı uzatmadan detay sunma
7Katkıda bulunmaTopluluk katkısını teşvik etme
8LisansYasal kullanım koşulunu netleştirme

Kaynak: GitHub Docs, "About READMEs" ve açık kaynak topluluk pratikleri.

Benzersiz içgörü Çoğu geliştirici README'yi projeyi bitirdikten sonra son adım olarak yazar — oysa deneyimli açık kaynak sürdürücüleri README'yi önce yazmayı önerir ("README-driven development"). Kurulum ve kullanım örneğini önce README'de tasarlarsanız, API'nizin gerçekten kullanıcı dostu olup olmadığını kod yazmadan önce fark edersiniz — README, iyi bir tasarım aracı olarak da işlev görür.

Lisans bölümünü eklerken tam metni README'ye gömmek yerine ayrı bir LICENSE dosyasına bağlantı vermek yaygın pratiktir: Bu proje [MIT Lisansı](LICENSE) ile lisanslanmıştır. Tablo yazımını henüz öğrenmediyseniz kurulum matrisi veya karşılaştırma tabloları için "Markdown ile Tablo Nasıl Oluşturulur?" rehberimize göz atın; temel sözdizimini tazelemek isterseniz "Markdown Nedir, Nasıl Yazılır?" yazımız başlangıç noktanız olabilir.

Sık sorulan sorular

GitHub README'ye rozet (badge) nasıl eklenir?
Bir görsel bağlantısı olarak eklenir: ![etiket](https://img.shields.io/badge/durum-aktif-brightgreen). shields.io gibi servisler sürüm, lisans, build durumu gibi bilgileri anlık rozet görseline dönüştürür; siz bu URL'yi görsel sözdiziminde kullanırsınız.
GitHub README'de katlanabilir (collapsible) bölüm nasıl yapılır?
Ham HTML <details> ve <summary> etiketleriyle yapılır. GitHub markdown, bazı ham HTML etiketlerine izin verir, bu yüzden bu etiketler README içinde doğrudan render edilir. İçindeki markdown'ın çalışması için etiketin altına boş satır bırakmayı unutmayın.
Kod bloğuna dil etiketi neden eklenir?
Üçlü ters tırnaktan hemen sonra dil adı yazmak (ör. ```javascript) GitHub'ın o dile özel sözdizimi vurgusu uygulamasını sağlar. Dil belirtilmezse kod düz metin renginde, vurgusuz görünür.
README'de görsele nasıl bağlantı verilir ve boyutu ayarlanır?
Standart markdown görsel sözdizimiyle boyut ayarlanamaz; GitHub bunu kontrol etmenize izin vermez. Boyut kontrolü gerekiyorsa ham HTML <img src="url" width="400"> etiketi kullanılmalıdır, çünkü GitHub README içinde temel HTML etiketlerine izin verir.
README dosyasının adı ve konumu önemli mi?
Evet. GitHub, bir deponun kök dizinindeki (veya .github/ klasöründeki) README.md dosyasını otomatik olarak depo ana sayfasında render eder. Farklı bir isim veya konum kullanılırsa bu otomatik görüntüleme çalışmaz.

İlgili rehberler

Metodoloji & kaynaklar. Bu rehberdeki tüm örnekler, MarkdownÖnizle'nin kendi açık önizleme motorunda test edilerek hazırlanmıştır. GitHub'a özgü davranışlar GitHub Docs ("Basic writing and formatting syntax", "About READMEs") kaynaklarına, temel sözdizimi GitHub Flavored Markdown (GFM) Spesifikasyonu'na dayanır. Son güncelleme: 17 Temmuz 2026. GitHub arayüzü zamanla değişebilir; kritik kullanımlarda güncel GitHub Docs sayfasını kontrol etmeniz önerilir.
Kaynak: CommonMark & GitHub Flavored Markdown (GFM) spesifikasyonları · Güncelleme: 17 Temmuz 2026
Bilgilendirme amaçlıdır; tüm işlem tarayıcınızda yapılır, veri sunucuya gönderilmez. · MarkdownÖnizle