Git ve GitHub Kullanım Rehberi: Sıfırdan İleri Seviyeye

Git, dosyalardaki her değişikliği zaman içinde kaydeden dağıtık bir versiyon kontrol sistemi; gerektiğinde eski bir sürüme geri dönmeyi sağlar. GitHub ise bu Git deposunu internette barındıran, ekip çalışmasını ve kod incelemesini kolaylaştıran bir platform. İkisi sık karıştırılır ama farklı katmanlarda çalışır: Git bilgisayarda yerel olarak çalışan bir araç, GitHub o aracın ürettiği geçmişi paylaştığın bir servis.

Bir Word belgesinde "Kaydet" tuşuna bastığında önceki hal kaybolur. Git'te ise her commit ayrı bir kayıt noktası oluşturur, istediğin ana geri dönebilirsin. Bu fark tek başına çalışan bir geliştirici için bile güvenlik ağı sağlar, ekip halinde çalışırken vazgeçilmez hale gelir. Bu rehber, kurulumdan dallanma stratejilerine ve açık kaynağa katkıya kadar gerçek komutlarla ilerliyor.

Git nasıl kurulur ve ilk commit nasıl atılır?

Git'i kurduktan sonra ilk yapılması gereken iş kimliği tanımlamak. Her commit'e bu bilgiler damgalanır, bu yüzden atlanmamalı.

git config --global user.name "Celil Uyanıkoğlu"
git config --global user.email "[email protected]"

Var olan bir klasörü depoya çevirmek için git init yeterli. GitHub'da duran bir projeyi indirmek içinse git clone kullanılır.

git init
git clone https://github.com/kullanici/proje.git

git init çalıştığında klasörde gizli bir .git dizini oluşur; burada geçmiş, dallar ve ayarlar saklanır. Bu klasörü silmek depo geçmişini tamamen yok eder, bu yüzden dikkatli olunmalı.

Depoya hiç girmemesi gereken dosyalar için .gitignore dosyası oluşturulur. Node.js projelerinde node_modules/ klasörü, Python'da __pycache__/ klasörü, şifre içeren .env dosyaları buraya yazılır.

node_modules/
.env
*.log

Depo hazır olduktan sonra sıra değişiklikleri kaydetmeye gelir. Git üç aşamalı çalışır: çalışma dizini, staging alanı (index) ve commit geçmişi. git add bir dosyayı staging'e taşır, git commit ise o anki staging durumunu kalıcı bir kayda dönüştürür.

git status
git add dosya.txt
git add .
git commit -m "Giriş sayfasına buton eklendi"

git status her adımdan önce çalıştırılmalı; hangi dosyanın değiştiğini, hangisinin staging'de beklediğini net gösterir. git add . klasördeki tüm değişiklikleri eklerken, tek bir dosyayı eklemek için dosya adını yazmak yeterli. Commit mesajını kısa ve emir kipinde yazmak geçmişi okumayı kolaylaştırır; "buton eklendi" yerine "buton ekle" tercih edilebilir.

Küçük ve sık commit'ler, büyük ve nadir commit'lerden her zaman daha kullanışlıdır. Elli dosyayı tek commit'te toplamak yerine her mantıksal adımı (bir fonksiyon, bir düzeltme, bir stil değişikliği) ayrı commit'lemek, sorun çıktığında hangi değişikliğin suçlu olduğunu bulmayı kolaylaştırır. Bu alışkanlık ilk başta yavaş hissettirir ama birkaç haftada refleks haline gelir.

Geçmişteki commit'leri görmek için git log kullanılır. git log --oneline her commit'i tek satıra sıkıştırdığı için büyük projelerde daha okunaklıdır.

git log --oneline -10

Çıktı şuna benzer görünür; her satırda kısa commit hash'i ve mesaj yer alır.

a1b2c3d Giriş sayfasına buton eklendi
9f8e7d6 Header responsive hale getirildi
4c5b6a1 İlk commit

Bir dosyada satır satır kimin ne değiştirdiğini görmek için git blame dosya.txt kullanılır; hata ayıklarken hangi commit'in hangi satırı eklediğini bulmak için işe yarar. git diff ise henüz commit'lenmemiş değişiklikleri satır bazında gösterir, git add'den önce ne değiştiğini kontrol etmenin en hızlı yoludur.

GitHub'a nasıl push ve pull yapılır?

Yerel depo hazır olduğunda uzak sunucudaki karşılığına bağlanması gerekir. Bu bağlantı remote olarak adlandırılır ve genelde origin ismini alır.

git remote add origin https://github.com/kullanici/proje.git
git push -u origin main

-u bayrağı yerel main dalını uzaktaki origin/main ile eşler; bir sonraki push'larda sadece git push yazmak yeterli olur. Başkasının yaptığı değişiklikleri kendi bilgisayarına indirmek için git pull kullanılır. Bu komut aslında git fetch ve git merge'ün birleşimidir.

git pull origin main

SSH anahtarı kurulmamış hesaplarda push işlemi her seferinde kullanıcı adı ve şifre sorar; GitHub artık şifre yerine kişisel erişim jetonu (personal access token) istiyor. Bu jeton GitHub ayarlarından üretilip şifre alanına yapıştırılır.

SSH anahtarıyla çalışmak bu adımı kalıcı olarak ortadan kaldırır. Anahtar bir kere üretilip GitHub hesabına eklendikten sonra her push'ta şifre sorulmaz.

ssh-keygen -t ed25519 -C "[email protected]"
cat ~/.ssh/id_ed25519.pub

Çıktıdaki genel anahtar GitHub'da "Settings > SSH and GPG keys" bölümüne yapıştırılır; depo adresi de https:// yerine [email protected]: ile başlayan SSH formuna çevrilmelidir.

Branch ile çalışmak neden önemli?

Ana daldaki (main) kodu bozmadan yeni bir özellik geliştirmenin yolu ayrı bir branch açmaktan geçer. Branch, commit geçmişinin ayrı bir kolu gibi düşünülebilir. Ana hattan ayrılır, kendi değişikliklerini biriktirir, sonra tekrar ana dala birleşir.

git branch
git checkout -b ozellik/giris-formu
git push -u origin ozellik/giris-formu

git checkout -b hem yeni dalı oluşturur hem de o dala geçer; tek komutla iki iş birden yapılmış olur. Güncel Git sürümlerinde aynı işi git switch -c ozellik/giris-formu ile de yapmak mümkün; checkout daha eski ve çok amaçlı bir komut olduğu için switch daha net bir alternatiftir.

Branch isimlendirmesi ekipten ekibe değişir ama ozellik/, duzeltme/ gibi öneklerle gruplamak karışıklığı azaltır. İşi biten dal GitHub'da bir pull request ile main'e önerilir; ekip arkadaşları kodu inceler, onay verirse birleştirilir.

Dallar arası geçiş yaparken commit'lenmemiş değişiklikler varsa Git geçişe izin vermeyebilir. Bu durumda git stash değişiklikleri geçici bir kenara koyar, dal değiştirdikten sonra git stash pop ile geri getirir. Yarım kalmış bir işi bırakıp acil bir düzeltmeye geçmek gerektiğinde bu komut zaman kazandırır.

Aşağıdaki tabloda güncel Git sürümlerinde en sık kullanılan komutlar ve ne işe yaradıkları listelenir:

Merge çakışması çıkınca ne yapılır?

İki dal aynı dosyanın aynı satırını farklı şekilde değiştirdiyse git merge otomatik birleştiremez ve çakışma (conflict) bildirir. Panik gerekmez; Git dosyanın içine hangi satırların çakıştığını işaretler.

git checkout main
git merge ozellik/giris-formu

Çakışan dosyada şu işaretler görünür:

<<<<<<< HEAD
mevcut ana daldaki satır
=======
ozellik dalındaki satır
>>>>>>> ozellik/giris-formu

İki bloktan hangisinin (ya da ikisinin birleşiminin) kalacağına karar vermek gerekir. Ardından işaret satırları (<<<<<<<, =======, >>>>>>>) tamamen silinir. Sonrasında dosya normal bir değişiklik gibi eklenip commit'lenir.

git add dosya.txt
git commit -m "Merge conflict çözüldü: giris formu"

Sık çakışan dosyalar genelde paket kilit dosyaları veya otomatik üretilen config dosyalarıdır. Böyle durumlarda ekip içinde "bu dosyayı kim düzenliyorsa o commit'lesin" gibi basit bir kural bile çoğu çakışmayı önler.

Merge işleminden vazgeçmek için git merge --abort her şeyi çakışmadan önceki haline döndürür. Bu komut çakışan dosyalar henüz commit'lenmeden çalıştırılabilir; commit'lendikten sonra geri dönmek için git reset gerekir.

Bazı ekipler merge yerine git rebase kullanır. Rebase, dalın commit'lerini ana dalın üzerine tek tek yeniden uygular ve daha düz bir geçmiş bırakır. Rebase güçlü ama tehlikeli bir araçtır; paylaşılan bir dalda dikkatsizce kullanılırsa başkalarının geçmişini bozar. Yeni başlayanlar için merge daha öngörülebilir bir seçenektir.

Pull request süreci nasıl işler?

Pull request (PR), bir branch'teki değişikliklerin başka bir dala (genelde main) aktarılmasını öneren, GitHub'a özgü bir mekanizmadır. Kod push edildikten sonra GitHub arayüzünde "Compare & pull request" butonuyla açılır; başlık, açıklama ve varsa ilgili issue numarası eklenir.

PR açıldığında ekip arkadaşları satır satır yorum bırakabilir, değişiklik isteyebilir veya onaylayabilir. Bu inceleme süreci hataları merge olmadan önce yakalar; özellikle birden fazla kişinin dokunduğu projelerde tek başına kod yazmaktan daha güvenli sonuç verir. GitHub Actions gibi otomatik kontroller de PR'a bağlanıp testler geçmeden birleştirmeyi engelleyebilir.

Küçük PR'lar büyük olanlardan çok daha hızlı incelenir. Yüz dosyalık bir PR yerine, her biri tek bir işi çözen beş ayrı PR açmak hem incelemeyi kolaylaştırır hem de bir sorun çıktığında hangi değişikliğin sebep olduğunu bulmayı hızlandırır.

İyi bir PR açıklaması şu üç soruyu yanıtlar:

• Ne değişti ve neden değişti?
• Nasıl test edildi?
• İlgili issue veya konuşma var mı?

Bu üç noktayı içeren bir PR, incelemeyi yapan kişinin kod okumadan önce bağlamı anlamasını sağlar ve gidip gelen soru sayısını azaltır.

Açık kaynağa katkı nereden başlanır?

GitHub'daki açık kaynak projelere katkı genelde projeyi kendi hesabına "fork" etmekle başlar. Fork, deponun kendi hesabında bağımsız bir kopyasını oluşturur; orada istenilen değişiklik yapılabilir.

git clone https://github.com/kullanici-adi/proje.git
cd proje
git remote add upstream https://github.com/orijinal-sahip/proje.git
git fetch upstream
git merge upstream/main

upstream remote'u orijinal projeyle bağlantıyı canlı tutar; zaman geçtikçe orijinal depoda biriken değişiklikleri kendi fork'una çekmeyi sağlar. Değişiklik tamamlandıktan sonra kendi fork'una push edilir, oradan orijinal projeye pull request açılır.

Katkıya başlarken projenin CONTRIBUTING.md dosyasını okumak zaman kazandırır; çoğu proje kod stili, test çalıştırma ve commit mesajı formatı gibi kendine özgü kurallar tanımlar. "good first issue" etiketiyle işaretlenmiş görevler, yeni katkıda bulunanlar için özellikle seçilmiş, küçük ve net kapsamlı işlerdir.

GitHub profili, düzenli commit geçmişi ve katkı grafiğiyle iş başvurularında küçük bir portföy görevi de görür. İşe alım sürecinde bazı ekipler adayın açık kaynağa yaptığı katkılara, yazdığı kod kalitesine ve PR yorumlarındaki iletişimine bakar; bu yüzden profildeki depoları düzenli tutmak, boş "test" veya "deneme" adlı depoları silmek işe yarar.

Hangi hatalardan geri dönülür, hangilerinden dönülmez?

Son commit mesajını değiştirmek veya ona unutulan bir dosyayı eklemek için git commit --amend kullanılır. Ama bu komut commit push edilmeden önce kullanılmalı; push edilmiş bir commit'i amend etmek, ekip arkadaşlarının geçmişiyle çakışan bir geçmiş yaratır.

git commit --amend -m "Doğru mesaj"
git reset --soft HEAD~1
git revert a1b2c3d

git reset --soft HEAD~1 son commit'i geri alır ama değişiklikleri staging'de tutar; tekrar düzenleyip commit'lemek için kullanışlıdır. git revert ise geçmişi silmeden o commit'in tersini yeni bir commit olarak ekler; paylaşılan bir dalda hata düzeltmenin güvenli yolu budur. reset geçmişi yeniden yazdığı için zaten push edilmiş, başkalarının da çektiği commit'lerde neredeyse hiç kullanılmamalıdır.

Bir dosya yanlışlıkla commit'lenmişse ve o dosyanın .gitignore'a girmesi gerekiyorsa, dosyayı Git takibinden çıkarmak için git rm --cached dosya.txt komutu kullanılır; bu komut dosyayı silmeden takipten kaldırır. .gitignore dosyasına sonradan eklenen desenler, o andan itibaren yeni dosyaları otomatik dışlar.

Silinmiş bir dosyayı veya yanlış silinmiş bir branch'i kurtarmak da genelde mümkündür. git reflog, HEAD'in geçmişte gezdiği tüm noktaları listeler; yanlışlıkla silinmiş bir branch'in son commit hash'i buradan bulunup git checkout -b eski-dal ile geri getirilebilir. Reflog varsayılan olarak yaklaşık 90 gün saklanır, bu yüzden büyük bir hata fark edildiğinde reflog'a bakmak mantıklıdır.

Resmî Git dokümantasyonu komutların tüm parametrelerini örnekleriyle listeler, GitHub Docs ise pull request ve Actions gibi platforma özgü akışları anlatır. Tek gerçek güvenlik kuralı şudur: push'lanmış bir commit üzerinde git commit --amend ile git reset'i denemeden önce, o commit'i kimsenin çekmediğinden emin olmak.

Yazan Celil Uyanikoglu

25 yıldır bilgi işlem piyasasında farklı dallarda uzmanlaşan bir Bilgisayar Mühendisi