Git Sihirbazı Rehberi: Zaman Kazandıran Sırlar & İpuçları

Her geliştirici bilir: Bir projede çalışırken kodunuzu kaybetmek, yanlış bir değişikliği yayınlamak veya ekip arkadaşlarınızla çakışmalar yaşamak, motivasyonunuzu hızla düşürebilir. Git, bu kaosu düzenli bir hale getirmek için tasarlanmış harika bir versiyon kontrol sistemidir. Ancak, çoğu zaman sadece temel komutlarla yetiniriz: add, commit, push. Oysa Git’in derinliklerinde, geliştirme süreçlerinizi inanılmaz derecede hızlandıracak, sizi olası hatalardan kurtaracak ve ekip içindeki işbirliğini zirveye taşıyacak gizli güçler yatar. Bu rehber, Git ile ilişkinizi baştan aşağı yeniden tanımlayacak, sizi bir “Git kullanıcısından” “Git sihirbazına” dönüştürecek bir yol haritası sunuyor. Gelin, Git’in gerçek potansiyelini birlikte keşfedelim ve sizi durdurulamaz bir geliştirici yapacak ipuçlarına dalalım.

Git, en basit tabiriyle, yazılım geliştirme projelerinde yapılan değişiklikleri takip etmemizi ve yönetmemizi sağlayan dağıtılmış bir versiyon kontrol sistemidir (DVCS). Kodunuzun her anını kaydedebilir, önceki versiyonlara dönebilir ve farklı özellikler üzerinde eş zamanlı olarak çalışabilirsiniz. Bu sistemin temelini anlamak, ileri seviye teknikleri kavramak için hayati öneme sahiptir. Peki, Git’in temel taşları nelerdir ve neden bu kadar güçlüdür?

Öncelikle, Git bir projenin tüm geçmişini lokalde saklar. Bu, internet bağlantısına ihtiyaç duymadan hızla değişiklik yapabilmenizi ve geçmişi inceleyebilmenizi sağlar. Merkezi sistemlerin aksine, Git’te bir sunucu çökse bile, her geliştiricinin kendi kopyasında projenin tam geçmişi bulunur. Bu dağıtık yapı, hem esneklik hem de veri güvenliği açısından büyük avantajlar sunar. İşte Git’in temel iş akışını ve terimlerini açıklayan bir başlangıç:

• Depo (Repository): Projenizin tüm dosyalarını ve onların tüm versiyon geçmişini içeren ana alandır. Bir Git projesi başlattığınızda (git init), aslında bir Git deposu oluşturmuş olursunuz.

  git init

  
  Bu komut, bulunduğunuz dizine gizli bir .git klasörü ekler ve projenizi bir Git deposu haline getirir.

• Çalışma Dizini (Working Directory): Projenizin bilgisayarınızda bulunan ve üzerinde aktif olarak çalıştığınız dosyaların olduğu klasördür. Burada yaptığınız değişiklikler henüz Git tarafından takip edilmez.
• Hazırlık Alanı (Staging Area / Index): Çalışma dizinindeki değişikliklerinizi bir sonraki commit için hazırladığınız ara bölgedir. Değişiklikleri buraya ekleyerek, bir sonraki kaydınıza (commit'inize) hangi dosyaların dahil olacağını belirlersiniz.

  git add .

  
  Bu komut, mevcut tüm değişiklikleri hazırlık alanına ekler.

• Commit: Hazırlık alanındaki değişikliklerin kalıcı olarak kaydedildiği anlık görüntülerdir. Her commit, bir anlık görüntü (snapshot) alır ve projenin o anki durumunu kaydeder. Her commit'in benzersiz bir kimliği (hash) ve bir mesajı bulunur. Bu mesaj, yapılan değişiklikleri açıklar.

  git commit -m "İlk commit: Proje başlangıcı"

  
  Bu komut, hazırlık alanındaki değişiklikleri verilen mesajla birlikte kaydeder.

• Dal (Branch): Git'te geliştirme sürecini birbirinden ayırmanın en güçlü yoludur. Ana kod tabanından (genellikle main veya master dalı) ayrılıp yeni bir özellik, hata düzeltmesi veya deneme yapmak için yeni bir dal oluşturabilirsiniz. Bu, ana kod tabanını etkilemeden güvenle çalışmanızı sağlar.

  git branch yeni-ozellik
  git checkout yeni-ozellik

  
  Bu iki komut, yeni-ozellik adında bir dal oluşturur ve o dala geçiş yapmanızı sağlar. Alternatif olarak, git checkout -b yeni-ozellik ile tek komutta yapabilirsiniz.

• Birleştirme (Merge): Bir dalda yaptığınız değişiklikleri başka bir dala (genellikle ana dala) entegre etme işlemidir. Bu işlem, iki farklı geliştirme hattını bir araya getirir.

  git checkout main
  git merge yeni-ozellik

  
  Bu komutlar, önce main dalına geçiş yapar, ardından yeni-ozellik dalındaki değişiklikleri main dalına birleştirir.

Git'in bu temel kavramları, herhangi bir projenin omurgasını oluşturur. Bunları sağlam bir şekilde anlamak, hem tek başınıza çalışırken hem de bir ekiple işbirliği yaparken karşılaşacağınız sorunları daha kolay çözmenizi sağlayacaktır. Gerçek dünya senaryolarında, bu temeller üzerinde inşa edeceğimiz ileri düzey teknikler, sizi bir sonraki seviyeye taşıyacak. Örneğin, bir hata tespit ettiğinizde, projenin geçmişinde nerede ortaya çıktığını bulmak için git log ve git blame gibi komutları kullanabilirsiniz. Ya da yeni bir özellik üzerinde çalışırken, acil bir hata düzeltmesi gerektiğinde, git stash kullanarak mevcut değişikliklerinizi geçici olarak kenara koyup, acil düzeltmeyi yapıp geri dönebilirsiniz. Git'in bu esnekliği, geliştirme süreçlerinde karşılaşabileceğiniz her türlü duruma karşı sizi donatır.

İş Akışınızı Hızlandıran Gizli Git Güçleri Nasıl Keşfedilir?

Git'in temel komutlarını biliyor olsanız bile, iş akışınızı inanılmaz derecede hızlandıracak ve sizi daha verimli kılacak bir dizi ileri düzey özellik ve teknik bulunur. Bunlar, genellikle "sihirli" olarak adlandırılan ve deneyimli geliştiricilerin vazgeçilmezi olan araçlardır. Bu bölümde, Git'in size sunduğu bu gizli güçleri keşfedeceğiz ve onları günlük pratiklerinize nasıl entegre edeceğinizi adım adım göreceğiz.

Git Stash ile Çalışmayı Nasıl Yönetirsiniz?

Bir geliştiricinin sıkça karşılaştığı senaryo şudur: Yeni bir özellik üzerinde çalışıyorsunuz, ancak acil bir hata düzeltmesi yapmanız gerekiyor. Mevcut değişikliklerinizi commit etmek istemiyorsunuz çünkü henüz tamamlanmadılar ve yarım kalmış bir commit mesajı vermek de istemiyorsunuz. İşte tam bu noktada git stash devreye girer. Git stash, o anki çalışma dizininizdeki ve hazırlık alanınızdaki değişiklikleri geçici olarak kaydetmenizi ve çalışma dizininizi temiz bir hale getirmenizi sağlar. Böylece, başka bir işe geçebilir, acil düzeltmeyi yapabilir ve sonra kaldığınız yerden devam edebilirsiniz.

Vaka Analizi: Acil Düzeltme İhtiyacı

Diyelim ki bir e-ticaret uygulamasının ürün listeleme sayfasının filtreleme özelliğini geliştiriyorsunuz. Birkaç dosya üzerinde değişiklik yaptınız ve henüz test etmediniz. Birden, canlı sistemde kritik bir ödeme hatası olduğu bildirildi. Hemen müdahale etmeniz gerekiyor.

1. Mevcut Değişiklikleri Stash'leme:

   git status # Mevcut değişiklikleri kontrol edin
   git stash save "Ürün filtreleme özelliği üzerinde çalışırken" # Değişiklikleri kenara koyun

   
   Bu komut, mevcut tüm değişikliklerinizi bir "stash" olarak kaydeder ve çalışma dizininizi en son committeki haline geri döndürür. Artık git status komutunu çalıştırdığınızda temiz bir çalışma dizini göreceksiniz.

2. Acil Düzeltmeyi Yapma:
   Şimdi main dalına geçip hata düzeltmesini yapabilirsiniz.

   git checkout main
   # Hata düzeltmesini yapın
   git add .
   git commit -m "FIX: Kritik ödeme hatası düzeltildi"
   git push origin main

3. Kaldığınız Yerden Devam Etme:
   Hata düzeltmesini tamamladıktan sonra, tekrar yeni-ozellik dalınıza dönüp stashlediğiniz değişiklikleri geri getirebilirsiniz.

   git checkout yeni-ozellik
   git stash pop # En son stash'i uygulayın ve listeden kaldırın

   
   git stash pop komutu, değişiklikleri çalışma dizininize uygular ve stash listesinden kaldırır. Eğer değişiklikleri listede tutmak istiyorsanız git stash apply kullanabilirsiniz. Çatışmalar oluşursa, normal bir birleştirme işlemi gibi çözmeniz gerekecektir.

Uzman İpucu: Birden fazla stash kaydınız varsa, git stash list ile tüm stash'leri görebilir ve git stash apply stash@{2} gibi komutlarla belirli bir stash'i uygulayabilirsiniz.

Git Rebase ve Merge Arasındaki Fark Nedir, Ne Zaman Kullanılır?

Dal birleştirme, Git'in temel bir parçasıdır, ancak bunu yapmanın iki ana yolu vardır: git merge ve git rebase. Her ikisi de bir daldaki değişiklikleri diğerine entegre eder, ancak bunu farklı şekillerde yaparlar ve farklı geçmişler oluştururlar.

• Git Merge:
  Birleştirme işlemi, iki dalın geçmişini koruyarak yeni bir "birleştirme commiti" (merge commit) oluşturur. Bu commit, her iki dalın en son commit'lerini işaret eder ve iki farklı geliştirme hattını gösteren bir tarih oluşturur.

  git checkout main
  git merge feature-branch

  
  Avantajları: Güvenli ve değiştirilemez bir geçmiş sağlar. Orijinal commit tarihleri korunur.
  Dezavantajları: Çok sayıda birleştirme commiti, proje geçmişini karmaşık ve okunması zor hale getirebilir, özellikle sık sık dal birleştiriliyorsa.

• Git Rebase:
  Yeniden temel oluşturma, bir dalın commit'lerini başka bir dalın üzerine taşıyarak yapılır. Bu, dalın commit geçmişini değiştirir ve adeta o dalın başka bir dalın son commit'inden başlamış gibi görünmesini sağlar. Bu işlem yeni bir birleştirme commiti oluşturmaz; bunun yerine, commit'lerin kendileri yeniden yazılır.

  git checkout feature-branch
  git rebase main

  
  Bu komut, feature-branch dalındaki commit'leri main dalının en son commit'inin üzerine taşır.
  Avantajları: Daha temiz, doğrusal bir proje geçmişi oluşturur. Birleştirme commit'lerinden kaçınarak geçmişi daha okunabilir hale getirir.
  Dezavantajları: Commit geçmişini yeniden yazdığı için, zaten paylaşılan (uzak depoya push edilmiş) dallarda rebase yapmak tehlikelidir ve takım arkadaşları için sorunlara yol açabilir. Sadece kendi yerel dallarınızda kullanılması önerilir.

Ne Zaman Hangisini Kullanmalısınız?

Merge kullanın: Paylaşılan dallarda veya geçmişin korunması mutlak öncelikliyse. Ortak çalışma yapılan uzun ömürlü dallarda (örn. develop, release) merge daha güvenli bir seçenektir.

Rebase kullanın: Kendi yerel dallarınızda, henüz uzak depoya gönderilmemiş (push edilmemiş) değişiklikleriniz varsa ve temiz, doğrusal bir geçmiş istiyorsanız. Örneğin, bir özellik dalını main dalına birleştirmeden önce, main dalındaki en son değişiklikleri kendi dalınıza entegre etmek için rebase kullanabilirsiniz. Bu, birleştirme sırasında oluşabilecek çatışmaları daha erken tespit etmenizi ve çözmenizi sağlar.

# Rebase örneği adımları
git checkout feature/yeni-ozellik # Özellik dalınıza geçin
git pull origin feature/yeni-ozellik # Kendi dalınızın uzak versiyonu ile senkronize olun (her ihtimale karşı)
git fetch origin # Uzak depodaki değişiklikleri alın
git rebase origin/main # main dalının üzerine rebase yapın
# Çatışmalar oluşursa çözün, sonra git rebase --continue
# İşlem bittikten sonra, eğer uzak depoya push edecekseniz --force veya --force-with-lease kullanmanız gerekebilir
git push --force-with-lease origin feature/yeni-ozellik # Dikkatli kullanın!

Git Cherry-Pick ile Seçici Değişiklikler Nasıl Uygulanır?

Bazen, bir daldaki tüm commit'leri değil, sadece belirli bir commit'i başka bir dala uygulamak isteyebilirsiniz. Örneğin, bir hata düzeltmesi yaptınız, ancak bu düzeltme henüz tamamlanmamış bir özellik dalında. Acilen bu düzeltmeyi ana dala (main) veya başka bir sürüm dalına taşımanız gerekiyor. İşte git cherry-pick tam da bu senaryolar için tasarlanmıştır.

Vaka Analizi: Sıcak Fix'i Ana Dala Aktarma

Diyelim ki feature/yeni-rapor adında bir daldasınız ve bu dalda birkaç commit yaptınız. Bu commit'lerden biri, aslında acil bir güvenlik açığını kapatan kritik bir düzeltmeyi içeriyor. Ancak feature/yeni-rapor dalı henüz tamamlanmadığı ve test edilmediği için ana dala birleştirilemez. Güvenlik düzeltmesini hemen main dalına uygulamak zorundasınız.

1. İlgili Commit'in ID'sini Bulma:
   Öncelikle, aktarmak istediğiniz commit'in SHA-1 kimliğini (hash'ini) bulmanız gerekiyor. Bunu git log komutuyla yapabilirsiniz.

   git log --oneline feature/yeni-rapor

   
   Çıktıda, örneğin "abcdef1 Güvenlik açığı kapatıldı" gibi bir commit göreceksiniz. abcdef1 bu commit'in kısaltılmış ID'sidir.

2. Main Dalına Geçme ve Cherry-Pick Uygulama:
   Şimdi, bu commit'i uygulamak istediğiniz ana dala geçin ve git cherry-pick komutunu kullanın.

   git checkout main
   git cherry-pick abcdef1 # Güvenlik düzeltmesi commit ID'si

   
   Bu komut, abcdef1 commit'indeki değişiklikleri main dalınıza yeni bir commit olarak uygular. Eğer çatışmalar oluşursa, normal bir birleştirme/rebase işlemi gibi çözmeniz ve git cherry-pick --continue ile devam etmeniz gerekir.

cherry-pick, özellikle bir daldaki kararlı bir düzeltmeyi birden fazla başka dala (örneğin, main, release-v1.0, hotfix) hızlıca yaymanız gerektiğinde çok kullanışlıdır. Ancak, dikkatli kullanılmalıdır, zira aynı değişikliklerin farklı commit'ler olarak birden fazla dalda var olmasına neden olabilir, bu da gelecekteki birleştirmelerde karmaşıklığa yol açabilir. En iyi uygulama, düzeltmeleri mümkün olan en kısa sürede ana dala entegre etmek ve diğer dalları ana daldan çekerek güncel tutmaktır.

Git Alias ile Kendi Komutlarınızı Nasıl Oluşturursunuz?

Git komut satırı arayüzünde çok güçlü olsa da, bazı komutlar oldukça uzun olabilir veya sıkça kullandığınız bir dizi komutu arka arkaya çalıştırmanız gerekebilir. İşte bu noktada Git'in alias (takma ad) özelliği devreye girer. Git alias, uzun veya karmaşık komutlara daha kısa, hatırlanması kolay isimler vermenizi sağlar. Bu, geliştirici verimliliğini artırmanın ve yazım hatalarını azaltmanın harika bir yoludur.

Alias'ları Git konfigürasyon dosyanızda tanımlarsınız. Bu, global (tüm depolar için) veya yerel (sadece mevcut depo için) olabilir. Çoğu durumda, global alias'lar daha kullanışlıdır.

git config --global alias.st status # 'git st' artık 'git status' anlamına gelir
git config --global alias.co checkout # 'git co' artık 'git checkout' anlamına gelir
git config --global alias.br branch # 'git br' artık 'git branch' anlamına gelir
git config --global alias.ci commit # 'git ci' artık 'git commit' anlamına gelir
git config --global alias.hist "log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short" # Daha detaylı bir log görüntüsü
git config --global alias.type 'cat-file -t' # Bir nesnenin tipini gösterir
git config --global alias.dump 'cat-file -p' # Bir nesnenin içeriğini gösterir

Bu örnekler, sık kullanılan komutlara nasıl kısaltmalar atayabileceğinizi göstermektedir. Özellikle git log gibi detaylı çıktılar veren komutları özelleştirmek, projenin geçmişini çok daha okunabilir hale getirebilir.

Vaka Analizi: Hızlı ve Bilgilendirici Log Görünümü

Projenin geçmişini hızlıca incelemek istediğinizde, varsayılan git log çıktısı bazen çok uzun ve karmaşık olabilir. Özel bir alias ile bunu çok daha kullanışlı hale getirebilirsiniz. Yukarıdaki hist alias'ı bunun güzel bir örneğidir:

git hist

Bu komut, size aşağıdaki gibi bir çıktı verecektir:

* 1a2b3c4 2023-10-27 | Özellik E: Kullanıcı profili güncellendi (Ali Can)
* | 5d6e7f8 2023-10-26 | FIX: Ödeme formundaki hata giderildi (Veli Demir)
* |/
* 8g9h0i1 2023-10-25 | Özellik D: Admin paneli geliştirildi (Ayşe Yılmaz)

Böylece, her bir commit'in kısa hash'ini, tarihini, mesajını, hangi daldan geldiğini ve kim tarafından yapıldığını tek bir satırda görebilirsiniz. Bu, özellikle karmaşık dallanma geçmişlerine sahip projelerde hata ayıklama veya belirli bir değişikliği bulma süreçlerini büyük ölçüde hızlandırır.

Daha Karmaşık Alias'lar: Kabuk Komutları

Alias'lar sadece Git komutlarını kısaltmakla kalmaz, aynı zamanda kabuk komutlarını da çalıştırabilir. Bir alias'ın başına ünlem işareti (!) koyarak, Git'in komutu doğrudan kabukta çalıştırmasını sağlayabilirsiniz. Bu, birden fazla Git komutunu veya farklı kabuk komutlarını birleştiren güçlü alias'lar oluşturmanızı sağlar.

git config --global alias.unstage 'reset HEAD --' # 'git unstage ' ile dosyayı hazırlık alanından çıkarır
git config --global alias.last 'log -1 HEAD' # Son commiti gösterir
git config --global alias.visual 'gitk' # Gitk GUI aracını açar (varsa)
git config --global alias.clean-branches '!git branch --merged | grep -v "\* main" | xargs -n 1 git branch -d' # Birleştirilmiş tüm dalları siler (main hariç)

Yukarıdaki clean-branches alias'ı, mevcut daldan birleştirilmiş ve main dalı dışındaki tüm dalları otomatik olarak siler. Bu, geliştirme süreçlerinde biriken eski özellik dallarını temizlemek için inanılmaz derecede zaman kazandırır ve depo karmaşasını azaltır. Unutmayın, bu tür güçlü alias'ları kullanırken dikkatli olun, özellikle git branch -d gibi silme işlemleri içerenlerde.

Uzman İpucu: Alias'larınızı bir metin dosyasına kaydederek (örneğin .gitconfig dosyanızın içeriğini yedekleyerek) farklı makineler arasında kolayca senkronize edebilirsiniz. Ayrıca, özel iş akışlarınıza uygun, kendinize özgü alias'lar oluşturmaktan çekinmeyin!

Gelişmiş Git İş Akışları ve Takım Çalışması İpuçları Nelerdir?

Bireysel olarak Git'i ustaca kullanmak harikadır, ancak gerçek bir sihirbaz, takım içinde de Git'in tüm potansiyelini kullanır. Büyük ekipler ve karmaşık projeler için standart main/feature dal modelleri bazen yetersiz kalabilir. İşte burada daha gelişmiş iş akışları ve takım çalışmasını kolaylaştıran Git özellikleri devreye girer. Bu bölümde, Gitflow gibi yapılandırılmış yaklaşımları, bağımlılıkları yönetme yollarını ve Git'i otomatik süreçlerle entegre etmenin yollarını inceleyeceğiz.

Gitflow İş Akışı ile Projeyi Nasıl Yönetirsiniz?

Gitflow, Hollandalı geliştirici Vincent Driessen tarafından popülerleştirilen, sıkı bir şekilde tanımlanmış bir dallanma modelidir. Özellikle birden fazla sürümün eş zamanlı olarak geliştirildiği veya uzun ömürlü bir projenin yönetildiği durumlarda çok faydalıdır. Gitflow, temel olarak beş ana dal türü kullanır:

1. main: Üretimde (production) olan kararlı kodu içerir. Buraya yapılan commit'ler sadece yayınlanan sürümlerdir.
2. develop: Bir sonraki büyük sürüm için tüm yeni özelliklerin birleştirildiği entegrasyon dalıdır. Tüm yeni özellik dalları buradan ayrılır ve buraya birleştirilir.
3. feature dalları: Yeni bir özellik geliştirmek için develop dalından ayrılan kısa ömürlü dallardır. İş bitince develop dalına geri birleştirilir ve silinir.
4. release dalları: Yeni bir sürüm hazırlığı için develop dalından ayrılır. Sürüm hazırlığı sırasında hata düzeltmeleri ve son küçük ayarlamalar yapılır. Hazırlık bitince main ve develop dallarına birleştirilir, ardından silinir.
5. hotfix dalları: Üretimdeki main daldaki kritik hataları acilen düzeltmek için main dalından ayrılır. Düzeltme bitince main ve develop dallarına birleştirilir, ardından silinir.

Gitflow, bu dallar arasında geçişleri ve birleştirmeleri belirli kurallara bağlar. Bu, takım içindeki herkesin hangi dalın ne amaçla kullanıldığını bilmesini sağlar ve karmaşıklığı azaltır. Birçok Git istemcisi (Sourcetree, GitKraken) ve komut satırı aracı (git-flow uzantısı) bu iş akışını destekler.

# Gitflow başlangıcı
git flow init

# Yeni bir özellik dalı başlatma
git flow feature start yeni-kullanici-paneli

# Özellik üzerinde çalışın, commit'ler yapın
# ...

# Özelliği bitirme ve develop dalına birleştirme
git flow feature finish yeni-kullanici-paneli

Gitflow'un ana faydası, özellikle büyük takımlarda ve uzun ömürlü projelerde, net bir yayın döngüsü ve sürüm yönetimi sağlamasıdır. Ancak, küçük ve hızlı iterasyonlarla çalışan takımlar için bazen gereksiz derecede karmaşık olabilir.

Git Submodules ile Dış Bağımlılıkları Nasıl Yönetirsiniz?

Bir projenin, başka bir Git deposunda bulunan bir kütüphane veya alt proje gibi bir dış bağımlılığa ihtiyacı olduğu durumlar vardır. Bu tür senaryolar için Git, "submodule" (alt modül) özelliğini sunar. Git submodule'ları, bir Git deposunu, başka bir Git deposunun alt dizini olarak gömmenizi sağlar. Bu, ana projenizi ve bağımlı alt projeyi ayrı ayrı yönetebilmenize olanak tanır.

Vaka Analizi: Ortak Kütüphane Yönetimi

Diyelim ki hem web uygulamanız hem de mobil uygulamanız için ortak bir doğrulama kütüphanesi geliştiriyorsunuz. Bu kütüphane kendi Git deposunda bulunuyor. Her iki ana projenin de bu kütüphaneyi kullanması ve güncellemelerini takip etmesi gerekiyor.

1. Submodule Ekleme:
   Ana projenizin kök dizininde, alt modülü eklemek istediğiniz dizinde aşağıdaki komutu çalıştırın:

   git submodule add https://github.com/kullanici/ortak-dogrulama-kutuphanesi.git modules/validation

   
   Bu komut, ortak-dogrulama-kutuphanesi deposunu modules/validation dizinine klonlar ve ana depoya bir .gitmodules dosyası ile ekler.

2. Submodule Güncelleme:
   Alt modüldeki değişiklikleri takip etmek için, ana depodan alt modülün en son commit'ini çekmeniz gerekir:

   git submodule update --remote

   
   Bu komut, tüm alt modülleri uzak depodaki en son commit'e günceller.

3. Submodule Klonlama:
   Ana projeyi klonlarken alt modülleri de otomatik olarak klonlamak için:

   git clone --recurse-submodules https://github.com/kullanici/ana-proje.git

   Mevcut bir projede alt modülleri başlatmak ve güncellemek için:

   git submodule update --init --recursive

Submodule'lar, modüler yapıları teşvik eder ve bağımlılıkları temiz bir şekilde yönetmenize yardımcı olur. Ancak, yönetimi bazen karmaşık olabilir, özellikle alt modülün kendisinde değişiklik yapıp ana depodan takip etmeniz gerektiğinde. Bu durumda, her iki deponun da commit'lerini doğru sırayla senkronize etmek önemlidir.

Git Hooks ile İş Akışınızı Nasıl Otomatikleştirirsiniz?

Git hooks, belirli Git olayları (örneğin, commit yapmadan önce, push yapmadan sonra) tetiklendiğinde otomatik olarak çalışan komut dosyalarıdır. Bu, iş akışınızı otomatikleştirmek, kalite kontrolü sağlamak ve geliştirme sürecinizi daha tutarlı hale getirmek için inanılmaz güçlü bir araçtır. Hooks, projenizin .git/hooks dizininde bulunur ve basit kabuk betiklerinden (bash, Python, Ruby vb.) oluşur.

Bazı yaygın hook türleri:

• pre-commit: Commit mesajı yazılmadan önce çalışır. Kod kalitesi denetimi (linting), birim testleri çalıştırma veya kod standartlarını kontrol etme gibi işlemleri otomatikleştirmek için idealdir. Eğer hook başarısız olursa, commit işlemi iptal edilir.
• post-commit: Commit başarılı olduktan sonra çalışır. Genellikle bildirim göndermek veya bir CI/CD pipeline'ını tetiklemek için kullanılır.
• pre-push: Uzak depoya push yapmadan önce çalışır. Entegre testlerinizi çalıştırmak veya main dala direkt commit push'unu engellemek gibi güvenlik kontrolleri için kullanılabilir.
• post-merge: Bir birleştirme işlemi tamamlandıktan sonra çalışır. Bağımlılıkları güncellemek (örneğin npm install), testleri çalıştırmak gibi işlemler için kullanışlıdır.

Vaka Analizi: Pre-commit Hook ile Kod Kalitesi Sağlama

Bir projede, her commit'in belirli bir kod standardına uymasını ve syntax hataları içermemesini sağlamak istiyorsunuz. Bir pre-commit hook'u ile bunu otomatikleştirebilirsiniz.

1. Hook Dosyasını Oluşturma:
   Projenizin .git/hooks dizinine gidin (eğer yoksa, şablon dosyalarını kopyalayabilirsiniz). pre-commit adında bir dosya oluşturun ve içine çalıştırılacak betiği yazın.

   #!/bin/sh
   # Staging alanındaki JavaScript dosyalarını lint et
   JS_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep '\.js$')
   if [ -n "$JS_FILES" ]; then
     echo "JavaScript dosyaları kontrol ediliyor..."
     eslint --max-warnings 0 $JS_FILES
     if [ $? -ne 0 ]; then
       echo "ESLint hataları bulundu. Commit iptal edildi."
       exit 1
     fi
   fi
   exit 0

2. Çalıştırılabilir Hale Getirme:
   Betiği çalıştırılabilir hale getirin:

   chmod +x .git/hooks/pre-commit

Artık her commit yapmaya çalıştığınızda, Git önce bu pre-commit betiğini çalıştıracak. Eğer betik eslint hataları bulur ve exit 1 ile çıkarsa, commit işlemi gerçekleşmeyecektir. Bu, codebase'inize istenmeyen veya hatalı kodların girmesini engellemenin güçlü bir yoludur.

Uzman İpucu: Git hooks dosyaları .git dizininde olduğu için depoya dahil edilmez. Bu yüzden, takım arkadaşlarınızla aynı hook'ları paylaşmak için, hook betiklerini projenizin ana dizininde bir yere koyup, bir kurulum betiği ile .git/hooks dizinine sembolik linkler oluşturmak veya husky gibi araçlar kullanmak iyi bir yaklaşımdır.

Git ile Hata Ayıklama ve Sorun Giderme Teknikleri: Zorluklarla Başa Çıkma Kılavuzu

Her geliştiricinin başına gelir: Bir noktada kodunuzda bir hata belirir ve bu hatanın ne zaman ve hangi değişiklikten kaynaklandığını bulmak zorlaşır. Git, bu tür durumlar için inanılmaz güçlü hata ayıklama ve sorun giderme araçları sunar. Bir Git sihirbazı, sadece kod yazmakla kalmaz, aynı zamanda sorunları hızlı ve etkili bir şekilde çözmek için Git'i nasıl kullanacağını da bilir.

git bisect ile Hataları Otomatik Olarak Nasıl Bulursunuz?

git bisect, bir hata veya gerilemenin (regression) ne zaman tanıtıldığını otomatik olarak bulmak için ikili arama (binary search) algoritmasını kullanan bir Git komutudur. Belirli bir geçmiş aralığındaki commit'leri "iyi" (good) veya "kötü" (bad) olarak işaretleyerek, Git bu aralığı sürekli daraltır ve hatanın hangi commit'te ortaya çıktığını size söyler.

Vaka Analizi: Performans Gerilemesi Tespiti

Projenizin son sürümünde performans düşüşü yaşadığınızı fark ettiniz. Son iki haftadır birçok commit yapıldı ve hangi commit'in bu düşüşe neden olduğunu bilmiyorsunuz. git bisect ile bunu bulabilirsiniz:

1. Bisect İşlemini Başlatma:

   git bisect start

2. Kötü (Bad) Commit'i Belirtme:
   Mevcut durumun (son commit) kötü olduğunu belirtin.

   git bisect bad HEAD

3. İyi (Good) Commit'i Belirtme:
   Hatanın henüz mevcut olmadığı bilinen eski bir commit'i (veya dalı) belirtin. Örneğin, iki hafta önceki main dalının son commit'i.

   git bisect good 2 weeks ago # Veya belirli bir commit hash'i, örneğin abcdef1

   
   Git şimdi bu iki commit arasındaki commit'lerin ortasındaki bir commit'e otomatik olarak geçiş yapacaktır.

4. Test Etme ve İşaretleme:
   Geçiş yapılan commit'te kodu test edin. Performans hala kötüyse, o commit'i "bad" olarak işaretleyin:

   git bisect bad

   Performans iyiyse, "good" olarak işaretleyin:

   git bisect good
   Git, her seferinde bir commit'e daha geçiş yapacak ve siz bu adımı tekrarlayacaksınız.

5. Sonuç:
   Birkaç adım sonra, Git size hatayı tanıtan ilk commit'i bildirecektir.

   abcd123 is the first bad commit
   Author: John Doe 
   Date:   Thu Oct 19 10:30:00 2023 +0300
   
       feat: Optimize database queries

6. Bisect İşlemini Bitirme:
   Hata tespiti tamamlandıktan sonra, Git'in normal durumuna geri dönmek için reset komutunu kullanın:

   git bisect reset

git bisect, karmaşık hata ayıklama süreçlerini dakikalara indirebilir ve sorunu bulmak için harcanan zamanı büyük ölçüde azaltabilir. Hatta otomatik bir test betiği kullanarak bu süreci tamamen otomatikleştirebilirsiniz: git bisect run .

Çatışmaları (Conflicts) Etkili Bir Şekilde Nasıl Çözersiniz?

Takım halinde çalışırken veya farklı dalları birleştirirken çatışmalar kaçınılmazdır. İki farklı geliştirici aynı dosyanın aynı satırlarında değişiklik yaptığında veya bir dosya bir dalda silinip diğerinde değiştirildiğinde Git, hangi değişikliğin doğru olduğuna karar veremez ve bir çatışma yaratır. Çatışmaları çözmek, Git sihirbazlığının önemli bir parçasıdır.

Çatışma oluştuğunda Git, etkilenen dosyalara özel işaretler (<<<<<<<, =======, >>>>>>>) ekler. Bu işaretler, sizin "mevcut dalınızdaki" (HEAD) değişiklikleri ve "gelen daldaki" (uzak/merge edilecek dal) değişiklikleri ayırır.

Çatışma Çözme Adımları:

1. Çatışmaları Görüntüleme:

   git status

   
   Bu komut, hangi dosyaların çatışmalı olduğunu gösterir.

2. Çatışmalı Dosyayı Düzenleme:
   Bir metin düzenleyici veya birleştirme aracı (merge tool) kullanarak çatışmalı dosyayı açın.

   
   <<<<<<< HEAD
   Ana Sayfa Başlığı
   =======
   Ürünler Sayfası Başlığı
   >>>>>>> feature/product-page
   

   
   Bu örnekte, HEAD (sizin dalınız) ve feature/product-page (gelen dal) farklı başlıklar içeriyor. Hangi başlığın kalması gerektiğine karar vermeniz ve çatışma işaretlerini kaldırmanız gerekir.

   
   Ana Sayfa Başlığı
   

   
   (Varsayalım ki Ana Sayfa Başlığını korumaya karar verdiniz.)

3. Çözülmüş Dosyayı Hazırlık Alanına Ekleme:
   Çatışmayı çözdükten sonra, dosyayı hazırlık alanına ekleyerek Git'e bu dosyanın çözüldüğünü bildirirsiniz.

   git add 

4. Birleştirme İşlemini Tamamlama:
   Tüm çatışmalı dosyaları çözdükten ve hazırlık alanına ekledikten sonra, birleştirme işlemini commit ile tamamlarsınız.

   git commit -m "Merge feature/product-page into main, conflicts resolved"

Faydalı Komutlar:

• git merge --abort: Birleştirme işlemi sırasında pişman olursanız, bu komutla birleştirme işlemini iptal edebilir ve önceki durumunuza dönebilirsiniz.
• git mergetool: Git'i harici bir birleştirme aracı (VS Code, KDiff3, Meld vb.) ile kullanmak için. Bu araçlar çatışmaları görsel olarak çözmenize yardımcı olur.

  git mergetool

Çatışmaları çözmek pratik gerektirir. Düzenli olarak pratik yaparak ve birleştirme araçlarını kullanarak bu süreci daha az korkutucu ve daha verimli hale getirebilirsiniz. Bir Git sihirbazı, çatışmaların sadece öğrenme fırsatları olduğunu bilir!

@media screen and (max-width: 768px) {
    body {
        font-size: 14px;
    }
    .main-content {
        padding: 10px;
    }
    table {
        display: block;
        overflow-x: auto;
        white-space: nowrap;
    }
}
    

Sonuç: Git Sihirbazı Yolculuğunuz Başlıyor!

Bu rehber boyunca, Git'in temel kavramlarından başlayarak, zaman kazandıran gizli güçlerine, gelişmiş iş akışlarına ve hata ayıklama tekniklerine kadar birçok konuyu ele aldık. Artık sadece Git'i kullanan biri değil, onu projenizin ve ekibinizin ihtiyaçlarına göre şekillendiren bir "Git Sihirbazı" olma yolundasınız. Git'in sunduğu olanakları keşfetmek, geliştirme süreçlerinizi optimize etmek ve karşılaşabileceğiniz sorunlara karşı daha donanımlı olmak için attığınız her adım, sizi daha verimli ve yetenekli bir geliştirici yapacaktır.

Unutmayın, Git'teki ustalığınız bir gecede gelmez. Öğrendiğiniz bu yeni komutları, alias'ları ve iş akışlarını düzenli olarak pratik yapın. Kendi projelerinizde veya küçük deneme depolarında deneyler yapmaktan çekinmeyin. Git'in "geçmişi her zaman geri alabilirsin" felsefesi, bu öğrenme sürecinde size güven verecektir. Bir Git sihirbazı, sadece komutları bilmekle kalmaz, aynı zamanda Git'i bir problem çözme aracı olarak düşünür ve onunla yaratıcı yollar bulur. Kodunuzu daha güvenli bir şekilde yönetin, ekip arkadaşlarınızla daha uyumlu çalışın ve projelerinizi daha hızlı teslim edin. Git sihirbazı yolculuğunuzda başarılar dileriz!

Sıkça Sorulan Sorular

Git kullanımıyla ilgili en çok merak edilen bazı soruları ve cevaplarını aşağıda bulabilirsiniz:

1. Git ve GitHub aynı şey midir?
   Hayır, aynı şey değildir. Git, kod değişikliklerini yerel olarak takip eden ve yöneten bir versiyon kontrol sistemidir. GitHub ise, Git depolarını barındıran, takım işbirliği ve kod paylaşımı için web tabanlı bir platformdur. Git, GitHub olmadan da kullanılabilir, ancak GitHub, Git depolarını uzaktan saklamak ve yönetmek için popüler bir hizmettir.
2. git pull ve git fetch arasındaki fark nedir?
   git fetch, uzak depodaki tüm yeni değişiklikleri yerel deponuza indirir ancak çalışma dizininize uygulamaz. Sadece uzak dal referanslarını günceller. git pull ise, git fetch'i çalıştırır ve ardından indirilen değişiklikleri mevcut yerel dalınızla otomatik olarak birleştirir (git merge). Genellikle git pull yerine git fetch yapıp ardından manuel olarak git merge veya git rebase yapmak daha güvenli bir yaklaşımdır.
3. Yanlışlıkla commit ettiğim bir değişikliği nasıl geri alabilirim?
   Eğer commit'iniz henüz uzak depoya push edilmediyse, git reset --soft HEAD~1 (commit'i geri alır ama değişiklikleri hazırlık alanında tutar) veya git reset HEAD~1 (commit'i ve hazırlık alanını geri alır, değişiklikler çalışma dizininde kalır) kullanabilirsiniz. Eğer commit uzak depoya push edildiyse ve başkalarıyla paylaşıldıysa, git revert HEAD kullanmanız daha güvenlidir. Bu, kötü commiti geri alan yeni bir commit oluşturur ve geçmişi değiştirmez.
4. main (veya master) dalıma doğrudan push yapmaktan nasıl kaçınabilirim?
   Birçok versiyon kontrol platformu (GitHub, GitLab, Bitbucket) ana dallar için korumalı dal (protected branch) ayarları sunar. Bu ayarlarla, ana dala doğrudan push yapmayı engelleyebilir, sadece pull request'ler aracılığıyla birleştirmelere izin verebilir ve belirli onaylayıcıların olmasını zorunlu kılabilirsiniz. Ayrıca, Git hooks kullanarak da yerel olarak bu tür push'ları engelleyebilirsiniz.
5. Büyük dosyaları Git ile nasıl yönetmeliyim?
   Git, büyük binary dosyaları (resimler, videolar, derlenmiş çıktılar) yönetmek için tasarlanmamıştır ve bu dosyaları doğrudan depoya eklemek performans sorunlarına yol açabilir. Bunun yerine, "Git Large File Storage" (Git LFS) gibi araçları kullanmanız önerilir. Git LFS, büyük dosyaların referanslarını Git deposunda saklarken, dosyaların kendilerini ayrı bir sunucuda tutar.