Bir proje üzerinde tek başına ya da bir ekiple çalışırken "bu değişikliği kim yaptı", "dün akşamki çalışan hâline nasıl geri dönerim" ya da "iki kişi aynı dosyayı aynı anda değiştirirse ne olur" sorularıyla er ya da geç karşılaşırsınız. Git, tam olarak bu sorunları çözmek için tasarlanmış bir dağıtık sürüm kontrol sistemidir. Bu yazıda Git'in ne işe yaradığını, kurulumunu, günlük kullanımda ihtiyaç duyacağınız temel komutları, uzak depo ile çalışmayı, dallanma mantığını ve .gitignore dosyasını sıfırdan anlatıyoruz. Bir sunucuda kod barındırıyor, siteyi Git üzerinden yönetiyor ya da sadece ekip arkadaşlarınızla ortak çalışıyorsanız burada anlatılanlar günlük iş akışınızın temel taşı olacak.
Sürüm Kontrolü Neden Gerekli?#
Sürüm kontrolü olmadan çalışmak genellikle şuna benzer: site_v2_son.zip, site_v2_son_GERCEK.zip, site_v2_son_GERCEK_duzeltilmis.zip. Dosya adlarıyla versiyon takibi yapmak, birkaç değişiklikten sonra tamamen kontrolden çıkar; kimin ne zaman neyi değiştirdiğini bulmak imkânsızlaşır.
Git bu sorunu, her değişikliği zaman damgalı, yazarı belli, açıklamalı bir "anlık görüntü" (commit) olarak kaydederek çözer. Bunun sağladığı somut faydalar:
- Geçmişe dönebilme: Bir hata fark ettiğinizde, hangi commit'te ortaya çıktığını bulup o noktaya güvenle dönebilirsiniz.
- Paralel çalışma: Ekip üyeleri aynı proje üzerinde farklı özellikleri aynı anda, birbirini bozmadan geliştirebilir (dallanma sayesinde).
- Değişiklik izlenebilirliği: Her commit "ne değişti, neden değişti" sorusuna cevap verir; kod incelemesi (code review) bu sayede mümkün olur.
- Yedekleme: Uzak bir depoya (GitHub, GitLab vb.) düzenli olarak gönderilen kod, yerel diskinizden bağımsız bir yedek hâline gelir.
Git, dağıtık bir sistemdir; yani her geliştiricinin bilgisayarında projenin tüm geçmişinin tam bir kopyası bulunur. Bu, eski merkezi sistemlerin (ör. SVN) aksine, internet bağlantısı olmadan da commit atabilmenizi, dal oluşturabilmenizi ve geçmişe bakabilmenizi sağlar — yalnızca başkalarıyla senkronize olmak için ağa ihtiyaç duyarsınız.
Kurulum ve Yapılandırma#
Git'i Kurmak#
Çoğu Linux dağıtımında Git tek satırla kurulur:
# Ubuntu / Debian
sudo apt update && sudo apt install -y git
# CentOS / AlmaLinux / Rocky Linux
sudo dnf install -y git
Kurulumun başarılı olduğunu sürüm numarasıyla doğrulayabilirsiniz:
git --version
Kendi bulut sunucunuzda geliştirme ortamı kuruyorsanız, bu adımı genellikle sunucuyu ilk hazırladığınız anda diğer temel araçlarla birlikte yaparsınız. Bir VDS veya sanal sunucu üzerinde çalışıyorsanız Git kurulumu birkaç saniyeden fazla sürmez.
Kimliğinizi Tanımlamak#
Git, her commit'e kimin yaptığını damgalar. Bu yüzden kurulumdan hemen sonra adınızı ve e-postanızı bir kere tanımlamanız gerekir:
git config --global user.name "Ayşe Yılmaz"
git config --global user.email "[email protected]"
--global bayrağı bu ayarların bilgisayarınızdaki tüm projelerde geçerli olacağı anlamına gelir; ayarlar ~/.gitconfig dosyasına yazılır. Belirli bir proje için farklı bir e-posta kullanmak isterseniz (ör. iş ve kişisel projeler ayrımı), ilgili proje klasöründe --global olmadan aynı komutu çalıştırmanız yeterlidir — bu durumda ayar yalnızca o depoya özel .git/config dosyasına yazılır.
Varsayılan dal adını ve editörü de bu aşamada ayarlayabilirsiniz:
git config --global init.defaultBranch main
git config --global core.editor "nano"
Yaptığınız tüm ayarları görmek için:
git config --list
Temel Akış: init, add, commit, status, log#
Git'in günlük kullanımının %80'i beş komuttan ibarettir. Bunları bir örnek üzerinden ilerleterek anlatalım.
Bir Depo Başlatmak: git init#
Yeni bir projeye Git ile versiyon takibi eklemek için proje klasöründe şu komutu çalıştırırsınız:
mkdir benim-projem && cd benim-projem
git init
Bu komut, klasörün içine gizli bir .git dizini oluşturur — projenin tüm geçmişi, dalları ve ayarları burada saklanır. .git klasörünü silerseniz, o projenin Git geçmişi tamamen kaybolur (dosyaların kendisi etkilenmez, sadece geçmiş gider).
Değişiklikleri İzlemeye Almak: git add#
Git, bir dosyada değişiklik yaptığınızda bunu otomatik olarak commit'e dahil etmez. Önce hangi değişikliklerin bir sonraki commit'e gireceğini staging area (hazırlama alanı) adı verilen ara katmana eklemeniz gerekir:
# Tek bir dosyayı ekle
git add index.html
# Belirli bir klasördeki tüm değişiklikleri ekle
git add src/
# Çalışma dizinindeki tüm değişiklikleri ekle
git add .
Bu iki aşamalı yapı (önce add, sonra commit) ilk bakışta gereksiz görünebilir ama aslında büyük bir esneklik sağlar: on dosya değiştirmiş olsanız bile, mantıksal olarak birbiriyle ilgili olanları seçip ayrı commit'ler hâlinde kaydedebilirsiniz.
Kaydı Kalıcı Hâle Getirmek: git commit#
add ile hazırladığınız değişiklikleri, açıklayıcı bir mesajla birlikte kalıcı bir anlık görüntüye dönüştürürsünüz:
git commit -m "Ana sayfa başlığını güncelle"
İyi bir commit mesajı, altı ay sonra o değişikliğe bakan birinin (genellikle sizin) "burada ne olmuş, neden" sorusuna cevap vermelidir. "düzeltme" ya da "güncelleme" gibi belirsiz mesajlar yerine "Giriş formundaki e-posta doğrulama hatasını düzelt" gibi somut ifadeler tercih edin.
Durumu Kontrol Etmek: git status#
Hangi dosyaların değiştiğini, hangilerinin staging alanında beklediğini görmek için en sık kullanacağınız komut budur:
git status
Çıktı size üç kategori gösterir: henüz izlenmeyen yeni dosyalar (untracked), değişmiş ama add edilmemiş dosyalar, ve add edilip commit bekleyen dosyalar. Emin olmadığınız her an bu komutu çalıştırmak zarar vermez, tam tersine alışkanlık hâline getirilmesi gereken bir refleks olmalıdır.
Geçmişi İncelemek: git log#
Projenin tüm commit geçmişini görmek için:
git log
Daha kompakt ve okunaklı bir görünüm için:
git log --oneline --graph --all
Bu komut her commit'i tek satırda, kısa bir hash (kimlik) ile birlikte gösterir ve dallar arası ayrışmayı basit bir ASCII grafiğiyle görselleştirir — özellikle birden fazla dalla çalışırken projenin genel akışını kavramak için çok işe yarar.
Uzak Depo: remote, push, pull, clone#
Şimdiye kadar anlatılanların hepsi yerel bilgisayarınızda gerçekleşti. Git'i asıl güçlü kılan, bu geçmişi bir uzak depo (remote repository) ile senkronize edebilmenizdir — GitHub, GitLab veya kendi sunucunuzdaki bir Git barındırma servisi bu rolü üstlenebilir.
Var Olan Bir Projeyi İndirmek: git clone#
Uzak bir depoyu, tüm geçmişiyle birlikte bilgisayarınıza kopyalamak için:
git clone https://github.com/kullanici/proje-adi.git
Bu komut hem projenin son hâlini hem de tüm commit geçmişini indirir; ekstra bir git init gerekmez, clone bunu otomatik yapar.
Uzak Depo Bağlantısı Eklemek: git remote#
Zaten yerelde git init ile başlattığınız bir projeyi sonradan bir uzak depoya bağlamak isterseniz:
git remote add origin https://github.com/kullanici/proje-adi.git
git remote -v
origin, uzak depo için kullanılan geleneksel takma addır; teknik olarak istediğiniz ismi verebilirsiniz ama neredeyse herkes origin kullanır.
Değişiklikleri Göndermek: git push#
Yerel commit'lerinizi uzak depoya göndermek için:
git push -u origin main
-u bayrağı (uzun hâli --set-upstream) yerel main dalınızı uzaktaki origin/main dalıyla ilişkilendirir; bu ilişki bir kere kurulduktan sonra sonraki push işlemlerinde sadece git push yazmanız yeterli olur.
Değişiklikleri Almak: git pull#
Ekip arkadaşlarınızın uzak depoya gönderdiği değişiklikleri kendi kopyanıza indirmek için:
git pull
pull aslında iki komutun birleşimidir: git fetch (uzaktaki değişiklikleri indirir ama yerel dallarınızı değiştirmez) ve ardından git merge (indirilenleri mevcut dalınıza uygular). Ekiple çalışırken güne başlarken git pull çekmek, üstünde çalıştığınız kodun güncel olduğundan emin olmanın en basit yoludur.
Bu tür sürekli senkronizasyon, canlı bir sunucuda kod dağıtımı yaparken de işinize yarar; kendi altyapınızda sunucu yönetimi ile ilgilenirken dağıtım betiklerinizi genellikle bir git pull adımı üzerine kurarsınız.
Dallanma: branch, checkout, merge#
Git'in belki de en güçlü özelliği dallanmadır (branching). Bir dal, projenin bağımsız bir geliştirme hattıdır; main (ana) dalınız her zaman kararlı ve çalışır durumda kalırken, yeni bir özelliği ayrı bir dalda geliştirip test edebilir, işiniz bittiğinde ana dala birleştirebilirsiniz.
Yeni Dal Oluşturmak#
git branch yeni-ozellik
Bu komut yalnızca dalı oluşturur, sizi otomatik olarak o dala geçirmez. Oluşturup aynı anda geçmek için:
git checkout -b yeni-ozellik
Git 2.23 ile birlikte gelen git switch ve git restore komutları da aynı işi görür: git switch -c yeni-ozellik yeni dalı oluşturup üzerine geçer. Bu iki komut, checkout'un yıllar içinde üstlendiği "hem dal değiştir hem dosya geri al" gibi birbirinden uzak görevleri ayırmak için eklendi; ama checkout hâlâ yaygın kullanıldığı ve çoğu eski kaynakta öyle geçtiği için iki yazımı da bilmekte fayda var.
Dallar Arası Geçiş#
git checkout main
git checkout yeni-ozellik
Bunun yerine git switch main / git switch yeni-ozellik da yazabilirsiniz — işlev aynıdır, sadece niyeti daha açık ifade eder. Dal değiştirmeden önce çalışma dizininizde commit edilmemiş değişiklikler varsa Git genellikle geçişe izin vermez; bu noktada değişikliği ya commit'ler ya da git stash ile geçici olarak bir kenara koyup dal değiştirdikten sonra geri getirirsiniz.
Mevcut dalları listelemek için:
git branch
Şu an bulunduğunuz dal, listede bir yıldız (*) ile işaretlenir.
Dalları Birleştirmek: git merge#
yeni-ozellik dalındaki geliştirmeler tamamlandığında, bunları main dalına aktarmak için önce main dalına geçip sonra birleştirme komutunu çalıştırırsınız:
git checkout main
git merge yeni-ozellik
Eğer iki dal aynı dosyanın aynı satırında farklı değişiklikler yaptıysa, Git bunu otomatik çözemez ve size bir çakışma (merge conflict) bildirir. Bu durumda ilgili dosyayı açtığınızda <<<<<<<, ======= ve >>>>>>> işaretleriyle ayrılmış iki versiyon görürsünüz; hangi kısmın kalacağına siz karar verip işaretleri temizler, ardından git add ve git commit ile çakışmayı çözdüğünüzü bildirirsiniz. Çakışmalar ilk başta ürkütücü görünse de aslında Git'in "burada bir karar vermen gerekiyor, elimden bir şey gelmez" demesinden ibarettir.
İşi biten bir dalı temizlemek için:
git branch -d yeni-ozellik
.gitignore ile İstenmeyen Dosyaları Dışlamak#
Her proje klasöründe Git'in takip etmesini istemediğiniz dosyalar bulunur: bağımlılık klasörleri (node_modules/), ortam değişkeni dosyaları (.env), derleme çıktıları, log dosyaları, işletim sisteminin oluşturduğu geçici dosyalar (.DS_Store) gibi. Bunları projenin kök dizinine koyacağınız bir .gitignore dosyasıyla dışlarsınız:
node_modules/
.env
*.log
dist/
.DS_Store
Her satır bir desen (pattern) tanımlar; sonuna / eklenen desenler yalnızca klasörleri, * joker karakteri ise herhangi bir dizi karakteri temsil eder. .gitignore dosyasının kendisini ise mutlaka commit'lersiniz — böylece bu kurallar projeyi klonlayan herkes için geçerli olur.
Dikkat edilmesi gereken bir nokta: .gitignore, yalnızca henüz izlenmeyen dosyalar için işe yarar. Bir dosya daha önce yanlışlıkla commit edilmişse, sonradan .gitignore'a eklemeniz onu geçmişten silmez — Git o dosyayı izlemeye devam eder. Böyle bir durumda önce git rm --cached dosya-adi ile dosyayı yalnızca takipten çıkarmanız (diskten silmeden), ardından değişikliği commit'lemeniz gerekir.
.env gibi sırlar (API anahtarı, veritabanı şifresi) barındıran dosyaları asla commit etmeyin; bir kez geçmişe girdikten sonra dosyayı silmek yeterli olmaz, geçmişten de temizlenmesi gerekir ki bu ayrı ve zahmetli bir işlemdir. Bu tür bilgileri ortam değişkenleri veya sunucu tarafı yapılandırma dosyaları üzerinden yönetmek, ileride yaşanacak bir güvenlik sızıntısını baştan engeller.
GitHub ve Benzeri Platformlar Üzerine Kısa Not#
GitHub, GitLab ve Bitbucket gibi platformlar Git'in kendisi değil, Git depolarını barındıran ve üzerine ekip çalışmasını kolaylaştıran araçlar (pull request/merge request, issue takibi, CI/CD entegrasyonu vb.) ekleyen servislerdir. Yani "GitHub'a push atıyorum" derken aslında Git komutlarını, uzak deponuz GitHub'da barındığı için kullanıyorsunuzdur.
Bir GitHub deposundan kod çekip kendi sunucunuzda çalıştırmak istediğinizde iş akışı genellikle şöyle olur: sunucuya SSH ile bağlanın, git clone ile depoyu indirin, bağımlılıkları kurun ve servisi başlatın. Projeyi sıfırdan bir sunucuya taşıyorsanız, bu süreci site taşıma hizmetimizle de tamamlayabilir veya kendi başınıza bir VDS üzerinde adım adım kurabilirsiniz. Git ile birlikte konteynerleştirilmiş dağıtım yapmayı düşünüyorsanız Docker'a giriş yazımız da işinize yarayacaktır.
Sıkça Sorulan Sorular#
Git ile GitHub arasındaki fark nedir?#
Git, bilgisayarınızda çalışan bir sürüm kontrol yazılımıdır ve internet bağlantısı olmadan da kullanılabilir. GitHub ise Git depolarını internet üzerinden barındıran, ekip çalışmasını kolaylaştıran ticari bir platformdur; Git'i kullanmak için GitHub'a ihtiyacınız yoktur, ama GitHub'ı kullanmak için Git bilmeniz gerekir.
Bir commit'i geri almak mümkün mü?#
Evet, ama nasıl yapacağınız commit'in nerede olduğuna bağlı. Henüz push etmediğiniz son commit'i geri almak için git reset --soft HEAD~1 kullanabilirsiniz; bu, commit'i siler ama değişiklikleri staging alanında bırakır, yani hiçbir şey kaybolmaz. Zaten uzak depoya gönderilmiş, başkalarının da çektiği bir commit'i geri almak isterseniz reset yerine git revert <commit-hash> tercih edilir; bu komut geçmişi silip yeniden yazmak yerine değişikliği tersine çeviren yeni bir commit ekler — paylaşılan bir dalın geçmişini bozmadığı için ekip çalışmasında daha güvenlidir.
git add . her zaman güvenli mi?#
Hayır, dikkatli kullanılmalı. Bu komut çalışma dizinindeki tüm değişmiş ve yeni dosyaları staging alanına ekler; .gitignore içinde tanımlamadığınız bir .env veya geçici dosya varsa yanlışlıkla commit edilebilir. git status ile önce neyin ekleneceğini kontrol etmek daha güvenlidir.
Merge ve rebase arasındaki fark nedir?#
merge, iki dalın geçmişini birleştiren yeni bir "birleştirme commit'i" oluşturur ve her iki dalın geçmişini olduğu gibi korur. rebase ise bir dalın commit'lerini başka bir dalın en son noktasının üzerine "yeniden oynatarak" daha düz, doğrusal bir geçmiş oluşturur. Yeni başlayanlara genellikle daha az sürpriz içerdiği için merge önerilir; rebase daha ileri seviye bir tekniktir.
Git kullanmak için mutlaka bir uzak depo (GitHub vb.) gerekli mi?#
Hayır. Git tamamen yerel olarak, hiçbir uzak depoya bağlanmadan da kullanılabilir; git init, git add, git commit komutlarının hiçbiri internet gerektirmez. Uzak depo yalnızca kodunuzu yedeklemek, başkalarıyla paylaşmak veya birden fazla makineden erişmek istediğinizde devreye girer.
Yanlışlıkla sildiğim bir dosyayı Git ile geri getirebilir miyim?#
Eğer dosya daha önce en az bir kez commit edilmişse evet. git checkout HEAD -- dosya-adi (veya güncel Git sürümlerinde git restore dosya-adi) komutu, dosyayı son commit'teki hâline geri döndürür. Bu, Git'in sürüm kontrolünün en pratik faydalarından biridir.
Git'i günlük alışkanlık hâline getirdikten sonra, kodunuzu bir sunucuya taşımak da doğal bir sonraki adım olur. İster sıfırdan bir proje kurun ister mevcut bir depoyu canlıya alın, uygun bir VDS veya bulut sunucu üzerinde Git tabanlı bir dağıtım akışı kurmak, güncellemelerinizi hızlı ve iz bırakır şekilde yönetmenizi sağlar.