Git ve GitHub Nedir? Sürüm Kontrolüne Giriş

Sürüm notu: Bu yazıdaki komutlar Git 2.54 ile denenmiştir.

Önce Tahmin Et

Ekibin bütün kodu tek bir sunucudaki repo'da duruyor. Sen de o repo'yu kendi bilgisayarına almışsın. Bir sabah sunucunun diski yanıyor ve repo tamamen siliniyor. Soru şu: kendi bilgisayarında projenin geçmişine, yani kimin neyi ne zaman değiştirdiğine hâlâ bakabilir misin? Peki internet yokken yeni bir commit atabilir misin?

Cevabı birazdan gerçek bir denemeyle göreceğiz. Bu sorunun cevabı, Git'i diğer sürüm kontrolü araçlarından ayıran şeyin ta kendisi.

Sürüm Kontrolü Neden Var?

Hepimiz bir yerde şu klasörü gördük: rapor.docx, rapor_son.docx, rapor_son_v2.docx, rapor_son_v2_gercekten_son.docx. Bu, sürüm kontrolünün elle yapılan, en ilkel hâli. Tek kişilik bir belgede bile çabuk çığırından çıkar. Yazılımda ise işin içine yüzlerce dosya, birkaç geliştirici ve aynı anda yürüyen işler girer.

Bir sürüm kontrolü sistemi dört soruya güvenilir bir cevap verir. Bu dosya kim tarafından, ne zaman ve neden değişti? Dün akşam çalışan hâline nasıl dönerim? İki kişi aynı dosyada çalışırsa değişiklikleri nasıl birleştiririz? Yarın yayına çıkacak sürümle şu an üzerinde çalıştığımız sürümü nasıl ayrı tutarız?

Git bu soruları commit denen kayıtlarla cevaplar. Her commit projenin o anki hâlinin bir fotoğrafıdır; yanında yazarı, tarihi ve "neden" sorusunun cevabı olan bir mesaj taşır. Commit'ler arka arkaya dizilince projenin geçmişi ortaya çıkar. Bir oyundaki kayıt noktaları gibi düşün: istediğin noktaya geri dönebilir, oradan başka bir yola sapabilirsin.

Merkezi ve Dağıtık Sürüm Kontrolü

Git'ten önceki yaygın araçlar, CVS ve Subversion (SVN), merkezi çalışırdı. Geçmişin tamamı tek bir sunucuda dururdu. Geliştiricinin bilgisayarında yalnızca dosyaların son hâli olurdu. Geçmişe bakmak, commit atmak, hatta bir dosyanın eski hâlini görmek için sunucuya bağlanman gerekirdi. Sunucu çökerse ekip dururdu; sunucunun diski giderse geçmiş de giderdi.

Git dağıtık bir sürüm kontrolü sistemidir. Bir repo'yu clone'ladığında yalnızca dosyaların son hâlini değil, bütün geçmişi, yani her commit'i ve her dosyanın her sürümünü alırsın. Sunucudaki repo ile senin bilgisayarındaki repo arasında teknik olarak bir fark yoktur. Sunucu, ekibin "buluşma noktası" olarak anlaştığı kopyadır, o kadar.

Açılıştaki soruyu deneyelim. Henüz Git kurmadıysan merak etme, kurulum bir sonraki yazının konusu; şimdilik sadece izle. Elimizde bookstore adında, iki commit'lik küçük bir repo var ve sunucu rolünü o oynuyor:

# "Sunucudaki" repo'nun kopyasını kendi bilgisayarına al
$ git clone bookstore ada-laptop
Cloning into 'ada-laptop'...
done.
# Sunucu bir anda ortadan kalktı
$ rm -rf bookstore
$ cd ada-laptop
$ git log --oneline
fae4454 (HEAD -> main, origin/main, origin/HEAD) Add shopping cart
29f27c8 Add README and book list

Sunucuyu sildik ama git log bütün geçmişi gösterdi, çünkü geçmiş zaten ada-laptop klasörünün içindeki .git klasöründe duruyor. origin/main yazan kısım, sunucunun son bildiğimiz durumu; onu remote yazısında ayrıntılı göreceğiz. Sunucuyla konuşması gereken bir komut ise doğal olarak hata verir:

$ git fetch
fatal: '/.../bookstore' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Ama commit atmak sunucuya ihtiyaç duymaz:

# README.md'ye bir satır ekledikten sonra
$ git add README.md
$ git commit -m "Mention the currency in README"
[main cec2371] Mention the currency in README
 1 file changed, 2 insertions(+)
$ git log --oneline
cec2371 (HEAD -> main) Mention the currency in README
fae4454 (origin/main, origin/HEAD) Add shopping cart
29f27c8 Add README and book list

Yeni commit'imiz yerelde duruyor; origin/main hâlâ eski yerinde. Sunucu geri geldiğinde bu commit'i oraya push ederiz. Açılıştaki iki sorunun cevabı da "evet". Dağıtık olmanın pratik karşılığı bu: uçakta, trende, sunucu bakımdayken çalışmaya devam edersin ve her clone aynı zamanda tam bir yedektir.

Git ile GitHub Aynı Şey Değil

Yeni başlayanların en sık karıştırdığı ikili bu. Git, bilgisayarına kurduğun açık kaynak bir komut satırı aracıdır. Commit'leri, branch'leri, geçmişi o yönetir ve hiçbir şirkete bağlı değildir. GitHub ise Git repo'larını barındıran bir web hizmetidir. Repo'nu orada tutarsın; üstüne pull request, kod incelemesi (review), issue takibi, GitHub Actions ile CI/CD ve erişim yönetimi gibi ekip çalışmasına dönük özellikler eklenir.

Bir benzetmeyle: Git fotoğraf makinesidir, GitHub da fotoğrafları paylaştığın, üzerine yorum yazılan albüm sitesi. Fotoğraf çekmek için siteye ihtiyacın yok, ama ekiple paylaşmak için bir yere koyman gerekiyor.

GitHub tek seçenek de değil. GitLab, Bitbucket ve Microsoft'un Azure DevOps'u (içindeki Azure Repos) aynı işi yapan yaygın hizmetler. Kendi sunucunda barındırmak istersen GitLab'ın kendi kurduğun sürümü, Gitea ya da Forgejo gibi seçenekler var. Hepsinin altında aynı Git çalışır; bu serinin Git kısmında öğrendiğin her şey hepsinde geçerlidir. GitHub'a özgü konuları (pull request, branch koruması, token'lar) ayrı yazılarda, GitHub'ın adını koyarak anlatacağız.

Kısa Bir Tarihçe

Git, Linux kernel'i için doğdu. Kernel geliştiricileri 2000'lerin başında BitKeeper adlı ticari bir araç kullanıyordu. 2005'te ücretsiz kullanım hakkı geri çekilince Linus Torvalds kendi aracını yazmaya karar verdi ve Git'in ilk sürümü Nisan 2005'te ortaya çıktı. Hedefleri belliydi: hızlı olacak, binlerce geliştiricinin aynı anda paralel çalışmasını kaldıracak ve geçmişin bozulmadığını garanti edecekti. O yılın Temmuz ayından beri projenin bakımını Junio Hamano yapıyor.

2008'de GitHub açıldı ve Git'i kernel dünyasının dışına, herkesin gündelik aracına dönüştüren şey büyük ölçüde bu oldu. Microsoft 2018'de GitHub'ı satın aldı. Git tarafında 2014'te başlayan 2.x çizgisi hâlâ sürüyor. Yaklaşık 10–13 haftada bir yeni bir özellik sürümü (2.N.0) çıkıyor, arada da hata ve güvenlik düzeltmesi taşıyan bakım sürümleri geliyor. Bu yazı yazılırken en güncel kararlı sürüm 28 Eylül 2026'da çıkan Git 2.56.0.

Ufukta Git 3.0 var. Varsayılan branch adının main olması, yeni repo'larda SHA-256 hash'i, reftable adlı yeni ref depolama biçimi ve derleme için Rust'ın zorunlu olması gibi değişiklikler 3.0 için planlanıyor. Resmî belgede henüz kesin bir tarih yok; bu yüzden tarih vermiyorum. Bu planları serinin son yazısında ayrıntılı ele alacağız.

DevOps'ta Git'in Yeri

Bu seri blogda DevOps kategorisinde, çünkü modern bir yazılım hattında neredeyse her şey bir commit'le başlar. Sen bir branch'i push edersin, CI sunucusu bunu görür ve testleri çalıştırır. Pull request merge edildiğinde CD tarafı uygulamayı test ortamına taşır. Bir tag attığında sürüm paketlenir ve yayına çıkar. Altyapıyı kodla tanımladığın (infrastructure as code) projelerde sunucu ayarları bile bir repo'da durur ve her değişiklik yine bir commit olur.

Yani Git'i iyi bilmek, yalnızca kendi kodunu kaybetmemek demek değil. Pipeline'ın neden tetiklendiğini, hangi commit'in yayına çıktığını, bir hatanın hangi değişiklikle geldiğini anlamanın da temeli. GitHub Actions'ı ayrı bir seride ele alacağız; bu seride Git tarafını sağlam kuruyoruz.

Bu Seri Nasıl İlerleyecek?

Seri, YouTube kanalımdaki "Git & Github" oynatma listesinin derinleştirilmiş ve güncellenmiş hâli. Videolardaki sıra burada da korunuyor: müfredat ve Git & GitHub nedir, repo ve ilk adım, log ve değişiklik takibi, branch, conflict, remote ve GitHub, son olarak reset, revert, restore, cherry-pick, stash, rebase ve squash gibi ileri konular. Her video burada bir ya da birkaç yazıya dönüşüyor.

İlk blok, yani 1–25. yazılar, kemik yapı. Güncel Git ile modern komutları kullanıyoruz: branch değiştirmek için git switch, dosya geri almak için git restore. Eski yazılarda ve StackOverflow cevaplarında göreceğin git checkout kullanımlarını da yeri geldikçe not düşeceğim. İkinci blok, 26–29. yazılar, sürümlerle evrim: Git 2.23'ten bugüne "eskiden böyle yapıyorduk, artık şöyle yapıyoruz" ve Git 3.0'a hazırlık.

Bütün örnekler tek bir küçük projede, bookstore adında bir kitapçı repo'sunda ilerleyecek. Ekipte iki kişi var: Ada ve Alan. Kodu bilerek basit tutuyoruz, çünkü konu JavaScript değil, Git. Yazılardaki komutlar Git 2.54 ile gerçekten çalıştırıldı ve çıktılar o çalıştırmalardan kopyalandı. GitHub'a gerçek push yapmak yerine, örneklerde GitHub'daki repo'nun yerine geçen yerel bir bare repo kullanacağız; hesap ve arayüz adımlarını metinde anlatacağım.

Sık Düşülen Tuzaklar

İlk tuzak, Git ile GitHub'ı aynı şey sanmak. "GitHub'ı kurdum" diyen birinin aslında Git'i kurduğunu, "Git'e yükledim" diyen birinin de GitHub'a push ettiğini sık görürsün. Aradaki farkı bilmek, hata mesajlarını okurken bile işini kolaylaştırır: fatal: ile başlayan satırı senin bilgisayarındaki Git yazar, remote: ile başlayan satırlar ise karşıdaki sunucudan gelir.

İkincisi, Git'i otomatik bir yedekleme aracı sanmak. Git yalnızca commit'lediğin şeyi korur. Kaydetmediğin, commit'lemediğin bir değişiklik diskin gittiğinde onunla birlikte gider. Commit'lediğin ama push etmediğin bir iş de yalnızca senin bilgisayarında yaşar.

Üçüncüsü, kavramı öğrenmeden bir GUI'ye ya da IDE'nin düğmelerine yaslanmak. Düğmeler gündelik işte rahat ama bir conflict ya da yanlış bir reset anında ne olduğunu bilmiyorsan düğme seni kurtarmaz. Bu seride her şeyi komut satırından yapacağız; komutları anlayınca hangi aracı kullandığın fark etmez.

Dördüncüsü, repo'yu her şeyin çöplüğü yapmak. Şifreler, API anahtarları, büyük binary dosyalar ve build çıktıları repo'ya girmemeli. Bir şifreyi commit'leyip sonra silmek yetmez, geçmişte durmaya devam eder. Bunun önlemini .gitignore yazısında konuşacağız.

Küçük Bir Deneme

★☆☆ Şu an çalıştığın ya da geçmişte çalıştığın bir projeyi düşün. Kod nerede duruyordu, geçmişe nasıl bakıyordunuz, iki kişi aynı dosyayı değiştirdiğinde ne oluyordu? Açılıştaki dört soruya o proje için cevap yazmayı dene.

★★☆ Kullandığın ya da merak ettiğin barındırma hizmetlerinden (GitHub, GitLab, Bitbucket, Azure DevOps) ikisini seç. İkisinde de pull request'in (GitLab'da merge request) ve CI'ın nerede durduğunu bul. Hangi kavramların Git'e, hangilerinin o hizmete ait olduğunu ayırmaya çalış.

★★★ Git kurulu bir bilgisayarın varsa yukarıdaki denemeyi kendin tekrarla: küçük bir repo oluştur, clone'la, asıl repo'yu sil ve clone'da git log ile yeni bir commit dene. Kurulu değilse bir sonraki yazıdan sonra geri dön.

Bir sonraki yazıda Git'i macOS, Windows ve Linux'a kuracağız, git --version ile sürümünü kontrol edeceğiz ve her repo'da işine yarayacak ilk ayarları yapacağız: adın, e-postan, varsayılan branch'in neden main olması gerektiği ve ayarların hangi dosyada durduğu.