Git Switch ve Checkout: Farkı Anlama

Uzun süre boyunca, git checkout bir depoda dolaşma, dallar arasında geçiş yapma, dosyaları geri yükleme ve eski commit’leri inceleme gibi neredeyse her şeyi yönetiyordu. Bu esneklik belirsizlik yarattı. Aynı sözdizimi, bağlama bağlı olarak farklı şeyler ifade edebiliyordu.

Küçük bir yazım hatası, bir dosyayı geri yüklemek isterken sizi yanlışlıkla başka bir dala geçirebilirdi. git checkout <commit-hash> ile yapılan hızlı bir geçmiş kontrolü, farkında olmadan ayrık bir HEAD durumunda kalmanıza neden olabilirdi. Komut çalışıyordu, ancak birden fazla davranışının sürekli farkında olmayı gerektiriyordu.

İşte bu noktada Git 2.23, dal işlemlerini yönetmek için daha uzmanlaşmış bir komut olan git switch’i tanıttı.

Bu rehberde, git switch’in git checkout’tan nasıl farklı olduğunu göstereceğim. Ayrıca her komutun modern iş akışlarındaki yerini ve kapsamlarını inceleyeceğiz.

Git sizin için hâlâ yeniyse, temel bilgileri Introduction to Git kursumuzda öğrenmenizi öneririm.

Git Switch Nedir?

git switch, Git 2.23’te dal gezinimi ve oluşturmayı yönetmek için sunulan özel bir komuttur. Dallar arasında geçişi daha temiz, daha güvenli ve daha az hataya açık hâle getirir.

Bu komuttan önce geliştiriciler dallar arasında geçiş yapmak için git checkout kullanıyordu. Sorun şuydu: git checkout birbiriyle ilgisiz birden çok görevi üstleniyordu: 

• Dallar arasında geçiş
• Dosyaları geri yükleme
• Commit’leri inceleme

Bu da komutu aşırı yüklenmiş ve yanlış kullanıma daha açık hâle getiriyordu.

Git, sorumlulukları bölerek bunu çözdü. Artık git switch dal geçişi ve oluşturmayı, git restore ise dosya geri yüklemeyi üstleniyor. Bu ayrım belirsizliği azaltır ve kazara dosya değişiklikleri riskini düşürür.

Pratikte, git switch branch-name geçerli HEAD işaretçinizi belirtilen dal adına taşır. git switch -c new-branch ile yeni bir dal oluşturup ona geçiş de yapabilirsiniz.

Git Switch ve Checkout: Çekirdek Mekanikler

git switch’in neden tanıtıldığını anladığınıza göre, şimdi perde arkasında git checkout’tan gerçekte nasıl farklılaştığına bakalım.

Amaca yönelik dal yönetimi

Git 2.23’ten önce git checkout hem dal gezinimini hem de dosya geri yüklemeyi yönetiyordu. Bu tasarım iş görüyordu ama temelde iki farklı kavramı karıştırıyordu. HEAD’i taşır, dosyaları geri yükler ve commit’leri checkout eder. Nasıl kullandığınıza bağlı olarak HEAD işaretçisini, index’i ve çalışma ağacını (working tree) değiştirir.

git switch yalnızca HEAD işaretçisini dallar arasında taşımaya odaklanır. git switch branch-name çalıştırdığınızda, Git HEAD’i o dala işaret edecek şekilde günceller ve çalışma dizinini ona uygun hâle getirir. Yani bu komut, özellikle dal gezinimi ve oluşturma içindir. git switch ve git restore ile sorumluluklar net biçimde ayrılır:

• git switch, HEAD’i dallar arasında taşır.

• git restore, çalışma ağacındaki veya index’teki dosyaları değiştirir.

Örneğin, geçmişte bir dosyayı geri yüklemek için şunu kullanmak gerekiyordu: git checkout HEAD -- file.txt. Bugün önerilen yaklaşım: git restore file.txt.

Burada yaptığınız şey bir dosyayı geri yüklemek; dal gezintisi yapmak değil. Betiklerde ve ekip dokümantasyonunda bu ayrım, okunabilirliği artırır ve hataları azaltır.

Git komutlarının evrimi

Git 2.23, sorumlulukları ayırarak git switch’i dal işlemleri ve git restore’u dosya geri yükleme için tanıttı.

Bu sürümden önce git checkout çok amaçlı bir araç gibi işliyordu. Dalları değiştirebilir, dosyaları geri yükleyebilir veya rastgele commit’lere geçebilirdi. Ancak bu durum özellikle yeni kullanıcılar için kafa karışıklığı yaratıyordu. Komutu bölerek Git belirsizliği azalttı ve yaygın iş akışlarını daha net hâle getirdi.

Ayrık HEAD davranışı

Git’te HEAD normalde bir dalı işaret eder. Bu dal da en son commit’i işaret eder. Yeni bir commit oluşturduğunuzda Git dalı ileri taşır. Bu standart iş akışıdır.

Ayrık HEAD, HEAD’in bir dal yerine doğrudan bir commit’i işaret etmesiyle oluşur. Bu durumda artık bir dal üzerinde değilsiniz. Yeni bir commit oluşturursanız Git onu oluşturur, ancak hiçbir dal adı ona referans vermez. Açıkça bir dal oluşturmadığınız sürece bu commit’ler referanssız kalır ve daha sonra bulunmaları zorlaşabilir.

git checkout <commit-hash> çalıştırdığınızda Git otomatik olarak ayrık HEAD moduna girer. Git o commit’e geçer ve ekstra onay gerekmeden HEAD’i ayırır. Bu davranış geçerlidir, ancak ayrık moda otomatik olarak girilmesini kolaylaştırır.

Öte yandan git switch açık ifade ister. HEAD’i ayırmak için git switch --detach <commit-hash> kullanmanız gerekir. --detach bayrağı olmadan git switch yalnızca dallar üzerinde çalışır. Bu tasarım, kazara ayrık durumları azaltır ve dal iş akışlarını daha güvenli ve öngörülebilir kılar.

Git Switch ve Checkout’un Temel İşlevsel Farkları

İki komut arasındaki üst düzey farkları ele aldığımıza göre şimdi sözdizimi, kapsam ve güvenlik konularına bakalım.

Komut sözdizimi ve oluşturma

git switch ile yeni bir dal oluşturup ona geçmek için git switch -c <branch-name> çalıştırırsınız. git checkout’ta bunun karşılığı git checkout -b <branch-name>’dir.

Her iki komut da yeni bir dal oluşturup ona geçer, ancak fark komutun amacını ne kadar açık ifade ettiğindedir. git switch’teki -c bayrağı doğrudan bir dal oluşturduğunuzu belirtir; git checkout’taki -b ise tarihsel olarak “branch” anlamına gelir, ancak niyeti daha az açık belirtir.

git switch ayrıca -C bayrağını sunar: git switch -C <branch-name>. Etkisi -c bayrağından daha güçlüdür: Dalı zorla oluşturur veya zaten varsa sıfırlar. Bu davranış açık ve dal odaklıdır. git checkout’ta benzer bir zorlama davranışı vardır, ancak komut birden çok amaca hizmet ettiğinden semantik ayrım daha az nettir.

İşlemlerin kapsamı

git switch yalnızca dallarla çalışır. Dosyaları geri yükleyemez, değişikliklerin aşamasını kaldırmaz (unstage) veya geçmiş commit’lerden belirli yolları checkout edemez. Özetle, dosya düzeyinde işlemleri desteklemez.

Buna karşılık, git checkout dosya düzeyinde çalışabilir. Örneğin, git checkout <commit> -- <file> geçmiş bir commit’ten belirli bir dosyayı geri yükler. 

Ancak modern Git dokümantasyonu bu amaçla git restore kullanılmasını önerir. Önemli nokta, git switch’in kapsamını dar ve öngörülebilir tutmak için dosya manipülasyonunu bilinçli olarak dışarıda bırakmasıdır.

Güvenlik ve belirsizliğin giderilmesi

git checkout ile yaygın bir sorun belirsizliktir. Bir dal adıyla bir dosya adı aynıysa, bağlama bağlı olarak dal değiştirebilir veya bir dosyayı geri yükleyebilir. git switch bu belirsizliği tamamen önler. Yalnızca dallar üzerinde çalışır. Geçerli bir dal adı sağlamazsanız, Git tahmin yürütmek yerine net bir şekilde hatayla sonlanır. 

git switch, yerel değişiklikler hedef dal ile çakıştığında daha net hata işleme de sağlar. Dal değiştirmek, commit edilmemiş çalışmanızı üzerine yazacaksa Git işlemi durdurur ve aşağıdakilere benzer doğrudan hata mesajları gösterir: 

• Dal yoksa: fatal: invalid reference: feature/login

• Yerel değişiklikler üzerine yazılacaksa: error: Your local changes to the following files would be overwritten by checkout

• -c kullanırken dal zaten varsa: fatal: a branch named 'feature/login' already exists

Bu tür net hata mesajları, kazara durum değişikliklerini azaltır.

Git Switch Uygulamalı Örnekler

Gerçek iş akışlarında gördüğünüzde git switch’i anlamak çok daha kolay olur. Bu örnekler, günlük dal yönetiminde nasıl davrandığını ve neden git checkout’tan daha güvenli ve öngörülebilir hissettirdiğini gösterir.

Standart dal işlemleri

Günlük geliştirmede çoğunlukla dallar arasında gezinir veya yenilerini oluşturursunuz.

• Var olan bir yerel dala geçmek için şunu kullanın: git switch <branch_name>. Burada Git, HEAD’i belirtilen dal adına taşır ve çalışma dizininizi o dala uyacak şekilde günceller.

• “new_ui” adlı yeni bir özellik için dal oluşturup tek adımda ona geçmek isterseniz git switch -c feature/new-ui kullanın. Bu, dalı geçerli commit’inizden oluşturur ve HEAD’i hemen ona taşır.

• Var olan bir dalı sıfırlamanız veya üzerine yazmanız gerekirse şunu kullanın: git switch -C feature/new-ui. Büyük -C dalı zorla oluşturur veya dal işaretçisini sıfırlar. Bu, yıkıcı niyeti açıkça belirtir.

• Ayrıca git switch - ile son iki dalınız arasında hızlıca gidip gelebilirsiniz. Bu, bir dalda kod incelerken tekrar tekrar özellik dalınıza dönmek için çok pratiktir.

Uzak dallarla çalışma

Çoğu zaman bir dal uzak depoda vardır ama yerelde yoktur. Örneğin biri origin/bugfix’i push’lar, ancak siz henüz oluşturmamışsınızdır.

• git switch bugfix çalıştırırsanız, Git yerelde bir bugfix dalı oluşturur ve uzak origin/bugfix dalını takip edecek şekilde ayarlar; origin’de net bir eşleşme varsayılır. Bu, işbirliğini kolaylaştırır çünkü upstream takibini elle ayarlamanız gerekmez.

• Git’in tahminde bulunmasını istemezseniz şunu kullanın: git switch --no-guess bugfix. Artık dal yerelde yoksa Git başarısız olur. Otomatik takibin karışıklık yaratabileceği daha sıkı iş akışlarında bu yararlıdır.

• İzleme dalı oluştururken açık olmayı tercih ediyorsanız git switch -c bugfix --track origin/bugfix kullanın. Bu, izleme ilişkisini doğrudan komutun içinde netleştirir.

Deneysel commit inceleme

Bazen yalnızca eski bir commit’e bakmak istersiniz. Belki önceki bir sürümü test etmek ya da bir hatanın ne zaman girdiğini doğrulamak istersiniz. Bu durumda, geçici olarak tarihte o noktaya gitmek istersiniz.

git switch ile bunu açıkça belirtmelisiniz: git switch --detach <commit-hash>.

--detach bayrağı Git’e şunu söyler: HEAD’i bir dala değil, doğrudan bu commit’e taşı. Artık kodu keşfedebilir, testleri çalıştırabilir veya projeyi derleyebilirsiniz. Bu durumda yeni commit’ler yaparsanız, bir dal oluşturmadığınız sürece hiçbir dala bağlı olmazlar.

git checkout <commit-hash> ile aynı eylem ekstra bir bayrak olmadan otomatik gerçekleşir. Bu, istemeden ayrık moda girmenizi kolaylaştırır; git switch’te --detach gerekliliği ise kazara ayrık HEAD durumlarını önler. 

Git Switch’i İş Akışına Entegre Etme

Sırada, git switch’i tipik Git iş akışlarına nasıl entegre edebileceğinizi görelim.

Senaryoya göre seçim

Modern geliştirme iş akışlarında, dal ile ilgili tüm işleri git switch yönetmelidir. Buna 

• Rutin özellik geliştirme
• Pull request’lerin incelenmesi
• Yerel rebase işlemleri
• Derlemeler sırasında dalları checkout eden CI/CD betikleri

git switch yalnızca dal yönetimine odaklandığı için niyeti net olarak iletir.

git checkout’un hâlâ bir rolü vardır, ancak artık daha dardır. Git 2.23’ten önce yazılmış eski otomasyon betikleri ona sıklıkla dayanır. Bazı dosya düzeyindeki geri alma görevleri de hâlâ onu kullanabilir; ancak ileriye dönük olarak tercih edilen ikame git restore’dur.

Yaygın hataları gidermek

git switch kullanırken sorun yaratabilecek iki belirgin senaryo vardır.

“Yerel değişikliklerinizin üzerine yazılacak”

Yerel değişiklikler varken dal değiştirmeye çalıştığınızda sık görülen bir sorun “error: Your local changes would be overwritten” uyarısıdır. Git, dal değişikliğinin commit edilmemiş çalışmanızın üzerine yazacağı için işlemi engeller. Bunu aşmak için iki güvenli seçeneğiniz vardır:

1. Değişiklikleri daha sonra kullanmak üzere saklamak istiyorsanız hedef dala geçmeden önce git stash çalıştırın. Geçişten sonra git stash pop ile geri alabilirsiniz.

2. Yerel değişiklikleri bilerek atmak istiyorsanız şunu kullanın: git switch --discard-changes target-branch. Bu seçenek Git’e yerel değişiklikleri atmasını ve index’i ile çalışma ağacını hedef dal ile eşleşecek şekilde sıfırlamasını söyler (izlenmeyen dosyaları kaldırmaz).

Kazara ayrık HEAD durumuna girme

Bir diğer senaryo, kazara ayrık bir HEAD durumuna girmektir. Bir dal üzerinde olmadığınızı fark eder fakat korumak istediğiniz çalışmalarınız varsa hemen yeni bir dal oluşturun: git switch -c recovery-branch. Bu, geçerli commit geçmişinizi adlandırılmış bir dala bağlar ve değişikliklerinizi korur.

Git Switch’i Benimserken En İyi Uygulamalar

git switch’i benimsemek sadece bir komut tercihi değildir. Ekiplerin Git iş akışlarını düşünme şeklinde küçük bir yapısal iyileştirmedir. Benimseme dokümantasyon, işe alıştırma ve otomasyon genelinde tutarlı olduğunda faydalar katlanır.

Ekip geçiş stratejileri

Önce dahili dokümantasyonunuzla başlayın. “Başlarken” rehberleriniz hâlâ dal değiştirmek için git checkout öğretiyorsa, bunları git switch ile güncelleyin. checkout’u yalnızca gerçekten gerektiği yerlerde tutun.

Eğitim de rol oynar. dern Git komutları özellikle yerel değişiklikler bir dal geçişi ile çakıştığında daha net hata mesajları sağlar. Geliştiricileri bu mesajları genel hatalar gibi görmezden gelmek yerine okumaya ve anlamaya teşvik edin. Daha yeni komut seti daha açıktır; bunu fark etmek güveni artırır ve hataları azaltır.

Otomasyonda tutarlılık

Kabuk betiklerinde, CI hatlarında ve Git kısaltmalarında (alias) dal gezinimi için git switch’i tercih edin; çünkü niyeti anında iletir. git switch main kullanan bir betik, birden çok anlama gelebilen git checkout’a dayanan bir betiğe göre yorumlaması daha kolaydır. 

Git kısaltmaları tanımlıyorsanız, bunları modern kullanımı yansıtacak şekilde güncelleyin. Örneğin, özellik dalları oluşturan bir kısaltma git checkout -b yerine git switch -c’yi sarmalamalıdır.

Son olarak, ortamlar arasında Git sürümlerini doğrulayın. git switch Git 2.23 veya sonrası gerektirir. Yeni komutta standardizasyon yapmadan önce yerel geliştirici makineleri, CI çalıştırıcıları ve derleme sunucularının bu gereksinimi karşıladığından emin olun. Basit bir sürüm kontrolü, ince uyumluluk sorunlarını önler.

Sonuç

Daha geniş açıdan bakarsanız, git switch’in gerçek avantajı basittir. Dal yönetimini daha net, daha güvenli ve daha kasıtlı hâle getirir. Komutu çalıştırdığınızda ne yaptığı konusunda hiçbir belirsizlik yoktur. Dalları değiştirirsiniz. Hepsi bu. Ve bu küçük netlik, günlük geliştirmeden şaşırtıcı derecede fazla sürtünmeyi kaldırır.

Bununla birlikte, git checkout kullanımdan kaldırılmadı; dosyaları geri yüklemek, dallar arasında geçiş yapmak veya daha karmaşık senaryoları ele almak için hâlâ kullanabilirsiniz. Ancak günlük dal gezinimi için Git, git switch kullanmanızı teşvik eder.

Bir sonraki adım olarak, Git ile işbirliğine odaklanan Intermediate Git kursumuzu almanızı öneririm.