Git Nedir? Sürüm Kontrolü Nasıl Çalışır?

Git, dosyaların yalnızca son halini değil, değişiklik geçmişini de tutan dağıtık sürüm kontrol sistemidir. Git ile dosyaları staging alanına alır, commit olarak kaydeder, branch'lerde ayrı çalışır ve uzak depolarla paylaşabilirsiniz. Böylece hatalı bir değişikliğin ne zaman yapıldığını görüp önceki çalışan sürüme dönebilirsiniz.

Git nedir ve neyi çözer?

Bir dosyada bugün çalışan kodu yarın bozduğunuzda, yalnızca son halini görmek çoğu zaman yeterli olmaz. Hangi satırın ne zaman değiştiğini, değişikliği kimin yaptığını ve önceki sürüme nasıl dönüleceğini bilmeniz gerekir. Git, dosya ve kod değişikliklerini yerel bir depo içinde izleyen dağıtık sürüm kontrol sistemidir.

Git, Linux çekirdeğinin geliştirme ihtiyaçları için oluşturuldu. Bugün web uygulamalarından Bash Script Nedir? Linux Otomasyonu Rehberi kapsamındaki otomasyon dosyalarına, altyapı tanımlarından dokümantasyona kadar pek çok metin tabanlı dosyayı yönetmek için kullanılabilir.

GitHub, GitLab veya Bitbucket Git’in kendisi değildir. Bu platformlar Git depolarını uzakta barındırır; inceleme, erişim yetkisi, issue ve CI/CD gibi ekip özellikleri sunar.

Git hangi bilgileri saklar?

• Dosyaların belirli andaki içeriğini
• Değişikliği yapan kullanıcıyı ve zamanı
• Commit mesajını ve ebeveyn commit ilişkisini
• Branch ve etiket gibi referansları
• Dosya içeriğinin bütünlüğünü doğrulayan kimlikleri

Git yalnızca dosyanın önceki halini saklayan basit bir yedekleme klasörü değildir. Commit’ler birbirine bağlanan nesnelerdir; branch ise bu commit’lerden birini gösteren hareketli bir referanstır.

Git deposu oluşturun – Proje klasöründe önce git init çalıştırın ve ilk commit’i anlamlı bir mesajla kaydedin.

Sürüm kontrolü nasıl çalışır?

Git’in çalışma mantığını anlamanın pratik yolu, dosyalarınızın geçtiği üç alanı ayırmaktır: çalışma dizini, staging area ve Git deposu. Bu ayrım, dosyada yaptığınız değişiklik ile commit’e dahil etmek istediğiniz değişikliği birbirinden ayırır.

İki dosyayı değiştirdiğinizi düşünün. Yalnızca birini git add ile staging alanına alırsanız sonraki commit diğer dosyadaki değişikliği içermez. Bu davranış, tek bir commit’in tek bir mantıksal değişikliği anlatmasını kolaylaştırır.

git status
git add nginx.conf
git diff --cached
git commit -m "Nginx proxy ayarını güncelle"

git diff --cached staging alanına alınan değişikliği gösterir. Commit’ten hemen önce bu çıktıyı okumak, yanlış dosyanın veya parolanın kayda girmesini engeller.

Commit’i inceleyin – git commit çalıştırmadan önce git diff --cached çıktısını okuyun.

Git commit nedir, branch ne işe yarar?

Commit, projenin belirli bir andaki kaydıdır. İyi bir commit mesajı yalnızca değişiklik yapıldığını söylemez; yapılan işi kısa ve arandığında anlaşılır biçimde belirtir. fix: SMTP timeout değerini 30 saniyeye çıkar mesajı, güncelleme mesajından daha fazla bağlam taşır.

Branch, ana geliştirme çizgisinden ayrılan bir çalışma hattıdır. Yeni bir özellik veya riskli bir yapılandırma branch üzerinde denenebilir; ana branch doğrudan etkilenmez.

git switch -c feature/healthcheck
git add .
git commit -m "Add HTTP healthcheck"
git switch main
git merge --no-ff feature/healthcheck

Buradaki git switch -c yeni branch oluşturup ona geçer. Eski Git sürümlerinde aynı iş için git checkout -b komutu da kullanılabilir. --no-ff, branch geçmişinin birleşme noktasını görünür tutar; ekip politikası farklıysa fast-forward merge tercih edilebilir.

Merge ile rebase farkı

merge iki geçmişi birleştirir ve gerektiğinde merge commit oluşturur. rebase ise branch commit’lerini başka bir tabanın üzerine yeniden yazar. Bu nedenle rebase, henüz paylaşılmamış yerel commit’lerde kullanışlıdır; ortak branch üzerinde yapılması başkalarının referanslarını bozabilir.

Branch’i paylaşmadan yeniden yazmayın – Ortak branch üzerinde git push --force kullanmadan önce ekipten açık onay alın.

Günlük Git kullanımı için temel komutlar

Git komutlarını ezber listesi gibi değil, değişikliğin yaşam döngüsü olarak düşünmek daha pratiktir. Önce mevcut durumu görün, dosyaları seçin, farkı kontrol edin ve commit oluşturun.

git clone ssh://git@example.com/uygulama.git
cd uygulama
git status
git switch -c fix/login-timeout
vim config/app.conf
git diff
git add config/app.conf
git diff --cached
git commit -m "Fix login timeout configuration"
git log --oneline --decorate -5

git clone uzak depoyu ve geçmişini yerel makineye indirir. git diff staging alanına alınmayan değişiklikleri, git log --oneline ise kısa commit geçmişini gösterir.

Dosya ekleme ve geri alma

git add -p, dosyanın tamamı yerine değişiklik parçalarını seçmenizi sağlar. Aynı dosyada iki ayrı iş yaptıysanız bu seçenek, commit’leri mantıksal olarak ayırır.

git add -p
git restore --staged config/app.conf
git restore config/app.conf

git restore --staged dosyayı staging alanından çıkarır; çalışma dizinindeki değişikliği silmez. İkinci komut ise kaydedilmemiş çalışma dizini değişikliklerini geri alır. Bu komut dikkat ister – yanlış dosyada kullanıldığında yerel değişiklik kurtarılamayabilir.

Silmeden önce kontrol edin – Geri alma komutlarından önce git status ve git diff çıktılarında doğru dosyayı doğrulayın.

Uzak depo, push ve pull nasıl çalışır?

Yerel Git deposu tek başına çalışabilir. Ekip çalışmasında ise bir uzak depo tanımlanır; çoğu kurulumda bu uzak depo origin adıyla kaydedilir. git fetch uzaktaki referans ve commit bilgilerini indirir, fakat çalışma dizininizi değiştirmez. git pull ise genel olarak fetch işleminden sonra merge veya rebase uygular.

git remote -v
git fetch origin
git log --oneline HEAD..origin/main
git switch main
git pull --ff-only origin main
git push -u origin feature/healthcheck

git pull --ff-only, yerel ve uzak geçmiş ayrışmışsa otomatik merge yapmaz; hata vererek karar vermenizi ister. Üretim sunucusunda sessiz bir merge yerine bu davranış daha öngörülebilirdir.

SSH ile bağlantı kullanırken uzak URL git@example.com:team/app.git biçiminde olabilir. HTTPS kullanılıyorsa parola yerine sağlayıcının önerdiği erişim belirteci gerekir. Özel anahtarlar, API belirteçleri ve .env dosyaları depoya eklenmemelidir.

.gitignore ne yapar?

.gitignore, Git’in izlemeye almadığı dosya desenlerini tanımlar. PHP bağımlılıkları için vendor/, Node.js projeleri için node_modules/ ve yerel sırlar için .env eklenebilir. Daha önce commit edilmiş bir dosyayı yalnızca .gitignore‘a yazmak depodan kaldırmaz; izlemeyi bırakmak için ayrıca git rm --cached gerekir.

Uzak geçmişi önce güncelleyin – Push öncesinde git fetch çalıştırın, farkı inceleyin ve birleştirmeyi kontrollü yapın.

Git ile GitHub, GitLab ve yedekleme aynı şey mi?

Git dağıtık bir sürüm kontrol sistemidir; GitHub ve GitLab barındırma ve ekip iş akışı hizmetleridir. Yerel deponuzdaki commit geçmişi, uzak platform erişilemez olduğunda da kullanılabilir. Bu, Git deposunun otomatik olarak iyi bir yedek olduğu anlamına gelmez.

Bir Git deposu kaynak kodunun geçmişini korur; veritabanı içeriği, yüklenen görseller, kullanıcı dosyaları ve üretim sırları çoğu uygulamada ayrı yedekleme gerektirir. Örneğin VPS’te MySQL Kurulumu ve Güvenli Yapılandırma sırasında kullanılan şema migration dosyaları Git’te tutulabilir, fakat canlı MySQL veritabanı ayrıca yedeklenmelidir.

Git geçmişinden silinen bir parola güvenli kabul edilmemelidir. Commit geçmişinde görünmüş bir anahtar için anahtarı iptal etmek veya döndürmek, yalnızca dosyayı sonraki commit’te silmekten daha doğru müdahaledir.

Altyapı kodu da Git ile izlenebilir. Cloud-Init Nedir? VPS Kurulumunu Otomatikleştirme gibi kurulum tanımları ve VPS’te Docker Kurulumu ve İlk Konteyneri Çalıştırma kapsamındaki Compose dosyaları branch, inceleme ve geri dönüş avantajlarından yararlanır.

Yedeği ayrı tutun – Git deposunu düzenli olarak uzak konuma gönderin, üretim verilerini ise bağımsız ve geri dönüşü test edilmiş bir yedekleme sistemiyle koruyun.

Git conflict neden çıkar ve nasıl çözülür?

Conflict, Git’in iki değişikliği otomatik olarak birleştiremediği durumda oluşur. Aynı dosyanın aynı satırları farklı branch’lerde değiştirilmişse Git karar vermez; seçimi kullanıcıya bırakır.

<<<<<<< HEAD
proxy_read_timeout 30s;
=======
proxy_read_timeout 60s;
>>>>>>> feature/timeout

İşaretler dosyada kalmamalıdır. Doğru satırı seçin, işaretleri silin, dosyayı test edin ve çözümü staging alanına alın.

git status
vim nginx.conf
nginx -t
git add nginx.conf
git commit -m "Resolve Nginx timeout conflict"

Çatışma birden fazla dosyadaysa git status hangi dosyaların beklediğini gösterir. Merge kararından emin değilseniz git merge --abort ile merge öncesi duruma dönebilirsiniz; rebase için karşılığı git rebase --abort komutudur.

Çakışmayı çözerken yalnızca dosyanın sözdizimini değil, davranışını da kontrol edin. Nginx için nginx -t, uygulama için test komutu ve Docker yapılandırması için ilgili doğrulama adımı çalıştırılmalıdır.

Git kullanırken sık yapılan hatalar

Her şeyi git add . ile eklemek: Çalışma dizinindeki gizli veya geçici dosyalar istemeden commit’e girebilir. Önce git status ile listeyi inceleyin; gerekiyorsa dosya adı belirterek staging yapın.

Commit geçmişini parola kasası sanmak: Bir sırrı dosyadan silmek, eski commit’lerdeki kopyasını yok etmez. Anahtarı iptal edin; geçmiş temizliği gerekiyorsa işlemi ekipçe planlayın.

Force push kullanmak: git push --force-with-lease, düz --force seçeneğinden daha güvenlidir; yine de ortak branch’lerde gelişigüzel kullanılmamalıdır.

Test etmeden merge etmek: Commit geçmişi temiz görünse bile uygulama çalışmayabilir. CI kontrolleri, yapılandırma testleri ve mümkünse staging ortamı kullanılmalıdır.

Git’i yedekleme yerine koymak: Uzak depo hesabı silinirse veya erişim yetkisi kaybolursa tek kopya korunmuş sayılmaz. Farklı erişim alanında, düzenli doğrulanan bir yedek bulundurun.

Git’in gücü komut sayısında değil, değişiklikleri küçük ve izlenebilir parçalara ayırmasındadır. Her commit geri dönüşü kolaylaştırır; belirsiz commit’ler ise gelecekteki incelemeyi uzatır.

İlk Git Deposunu Kullanırken Şunları Kontrol Edin

• Depoyu doğru klasörde başlatın veya doğru uzak URL'yi klonlayın.
• İlk commit'ten önce .gitignore dosyasını oluşturun.
• git status ile beklenmeyen dosyaları kontrol edin.
• Commit'leri tek bir mantıksal değişiklikle sınırlayın.
• Paylaşmadan önce git diff –cached çıktısını okuyun.
• Uzak branch'i fetch ile güncelleyin ve geçmiş farkını inceleyin.
• Git deposundan bağımsız, geri dönüşü test edilmiş yedek alın.

Sık Sorulan Sorular

Kaynaklar

• Git Resmi Dokümantasyonu — git-scm.com
• Pro Git Kitabı — git-scm.com
• Git Revision Selection — git-scm.com