Git Worktree Eğitimi: Dallar Arasında Geçiş Yapmadan Birden Fazla Dalda Çalışın

Bir özellik dalında çalışırken bir ekip arkadaşınız sizden pull request'ini incelemenizi istiyor. Değişikliklerinizi stash'leyip dal değiştirerek nerede kaldığınızı hatırlamayı umabilirsiniz. Ya da kaybetmemek için yarım kalmış işi commit edebilirsiniz. Bir de acil hotfix var: üretim çökmüş ve siz kod tabanının yarısına dokunan bir refaktörün içindesiniz. Bu tür her bağlam değişikliği 10–15 dakikalık hazırlık süresine mal olur ve odağınızı böler.

Git worktree, aynı depo içinde ayrı dizinlerde birden fazla dalı aynı anda checkout etmenizi sağlayarak bunu çözer. Yarım kalmış işi stash'lemek veya commit'lemek yerine, başka bir dalın zaten checkout edildiği farklı bir dizine basitçe cd yaparsınız. Hotfix üzerinde çalışır, dağıtırsınız, sonra cd ile özellik çalışmanıza tam bıraktığınız yerden geri dönersiniz.

Bu eğitimde worktree'leri nasıl oluşturup yöneteceğinizi, yaygın hatalardan nasıl kaçınacağınızı ve onları günlük iş akışınıza nasıl entegre edeceğinizi göstereceğim. Git dalları, commit'ler ve temel komut satırı işlemlerini zaten biliyor olmalısınız. Önce Git temellerini tazelemeniz gerekiyorsa, DataCamp'in Git'e Giriş eğitimini öneririm; temel konuları kapsar.

Git Worktree Nedir?

Git worktree, aynı depoya bağlı ek çalışma dizinleri oluşturan yerleşik bir özelliktir. Ana çalışma dizininiz birincil worktree'dir ve oluşturduğunuz her ek worktree, kendi dizininde kendi dalı checkout edilmiş şekilde gelir. Tüm bu worktree'ler aynı .git deposuna bağlıdır.

Bu paylaşımlı depo mimarisi, herhangi bir worktree'de yaptığınız commit'lerin anında paylaşılan Git veritabanında görünmesi ve diğer tüm worktree'lerden erişilebilir olması anlamına gelir. Dosyaların kendisi ise bağımsız kalır — bir worktree'de train.py dosyasını düzenlemek, değişiklikleri commit edene kadar yalnızca o dizini etkiler.

Neden sadece farklı terminaller kullanmıyoruz?

Aynı dizinde birden fazla terminal açıp farklı dallarda eşzamanlı çalışamazsınız. Git, dizin başına yalnızca bir dalın checkout edilmesine izin verir. Bir terminalde git checkout feature-b çalıştırdığınızda, o dizine işaret eden tüm terminaller için dosyaları değiştirir.

Git worktree, her dala kendi dizinini vererek bunu çözer. Her dizin, kendi dosyaları, çalışan süreçleri ve derleme çıktılarıyla tamamen bağımsızdır. Dallar arası geçiş, git checkout different-branch yerine cd ../different-directory olur.

Git Worktree Önkoşulları

Git worktree kullanmadan önce kurulumunuzu doğrulayın:

• Git 2.5 veya üstü: Kontrol etmek için git --version çalıştırın. Git worktree 2015'te yayınlandı, bu yüzden çoğu kurulumda bulunur
• Mevcut Git deposu: En az bir dala sahip bir depoya ihtiyacınız olacak
• Komut satırına aşinalık: Tüm worktree işlemleri terminalde yapılır

Worktree'nin mevcut olduğunu kontrol edin:

git worktree --helpAltyapı:

Yardım sayfası görüntülenirse hazırsınız.

Git worktree ne zaman kullanılmalı

Dal değiştirmek mevcut işinizi bölecekse Git worktree iyi çalışır:

• Kod incelemeleri: Özellik çalışmanızı stash'lemeden bir ekip arkadaşınızın değişikliklerini test edin
• Acil hotfix'ler: Refaktörünüzü dokunulmadan bırakırken üretim hatalarını düzeltin
• Paralel geliştirme: Sürekli dal değişimi olmadan iki bağımsız özellik üzerinde çalışın
• Uzun süren süreçler: 30 dakikalık bir test paketini başlatın ve başka bir worktree'de kod yazmaya devam edin

10 dakikanın altındaki hızlı işler için, git checkout daha basit olduğunda veya kesinti beklemediğiniz tek bir işe odaklandığınızda bunu atlayın.

İlk Worktree'nizi Oluşturma

Git worktree'yi anlamanın en iyi yolu bir tane oluşturup çalışmasını görmektir. Temel komutları adım adım uygulayacak, Git'in oluşturduğu yapıyı keşfedecek ve değişikliklerin worktree'ler arasında nasıl aktığını gözlemleyeceğiz.

Örnek bir depo hazırlama

Worktree'lere dalmadan önce üzerinde çalışacağınız bir Git deposuna ihtiyacınız olacak. Zaten birden fazla dala sahip bir Python projeniz varsa, bir sonraki bölüme geçin. Aksi halde, hızlıca basit bir ML hattı kuralım:

mkdir ml-pipeline
cd ml-pipeline
git initAltyapı:

Bir README ve bir Python betiği oluşturun:

echo "# ML Pipeline" > README.md
echo "def load_data():" > train.py
echo "    print('Loading training data...')" >> train.pyAltyapı:

Dosyaların oluşturulduğunu doğrulayın:

ls
# You should see: README.md  train.pyAltyapı:

Bu dosyaları commit'leyin ve bir özellik dalı oluşturun:

git add .
git commit -m "Initial commit"
git branch feature-preprocessingAltyapı:

Artık iki dala sahip bir deponuz var: main (mevcut dalınız) ve feature-preprocessing.

Temel worktree oluşturma

Mevcut bir dal için worktree oluşturmak yalnızca bir komut gerektirir. feature-preprocessing dalını ayrı bir dizinde checkout edelim:

git worktree add ../ml-pipeline-preprocessing feature-preprocessingAltyapı:

Bu, mevcut konumunuzun bir seviye üstünde ml-pipeline-preprocessing adlı yeni bir dizin oluşturur, orada feature-preprocessing dalını checkout eder ve onu mevcut deponuza bağlar.

Git oluşturmayı doğrular:

Preparing worktree (checking out 'feature-preprocessing')
HEAD is now at 0a7f986 Initial commitAltyapı:

Tamamen yeni bir iş için, dalı ve worktree'yi aynı anda oluşturun:

git worktree add -b feature-visualization ../ml-pipeline-vizAltyapı:

-b bayrağı, feature-visualization adlı yeni bir dal oluşturur ve onu yeni worktree'de checkout eder.

Worktree yapısını keşfetme

Worktree oluşturduktan sonra dosya sisteminizde birden çok dizin bulunur. Hepsini görmek için:

git worktree listAltyapı:

/Users/you/projects/ml-pipeline                  0a7f986 [main]
/Users/you/projects/ml-pipeline-preprocessing    0a7f986 [feature-preprocessing]Altyapı:

İlk satır, .git klasörünü içeren orijinal dizin olan ana worktree'yi gösterir. İkinci satır bağlı worktree'yi gösterir. Her ikisi de geçerli commit özetini ve checkout edilmiş dalı gösterir.

Her worktree dizini, eksiksiz bir Git deposu gibi çalışır. İçine gidebilir, dosyaları düzenleyebilir, git status çalıştırabilir ve commit yapabilirsiniz. Bağlı worktree'ler tam bir .git dizini içermez — bunun yerine ana depoya geri işaret eden bir .git dosyası vardır. Ana .git dizini içinde, her bağlı worktree hakkında meta verileri saklayan bir worktrees klasörü bulunur.

Bir worktree içinde çalışmak

feature-preprocessing worktree'sine gidin ve bir commit yapın:

cd ../ml-pipeline-preprocessing
cat >> train.py << 'EOF'

def preprocess_features(df):
   """Normalize numeric features."""
   return (df - df.mean()) / df.std()
EOF
git add train.py
git commit -m "Add feature preprocessing function"Altyapı:

Commit normal şekilde gerçekleşir:

[feature-preprocessing 7c8d4e2] Add feature preprocessing function
1 file changed, 3 insertions(+)Altyapı:

Ana worktree'nize dönün ve commit geçmişini kontrol edin:

cd ../ml-pipeline
git log --oneline --allAltyapı:

Yeni commit'iniz görünür:

7c8d4e2 Add feature preprocessing function
0a7f986 Initial commitAltyapı:

Commit'in ek bir komuta gerek kalmadan her iki konumda da anında göründüğüne dikkat edin.

Git Worktree Kullanım Senaryoları

Artık worktree oluşturmayı ve içinde çalışmayı bildiğinize göre, gerçek geliştirme sorunlarını çözdükleri pratik senaryolara bakalım.

Kod inceleme iş akışı

Ekip arkadaşınız PR'inde geri bildiriminize ihtiyaç duyuyor. Değişikliklerinizi stash'leyip dal değiştirmek yerine, inceleme için ayrı bir dizin oluşturun:

git worktree add ../ml-pipeline-review pr/update-training
cd ../ml-pipeline-review
pip install -r requirements.txt
python train_model.py --config experiments/baseline.yamlAltyapı:

Değişiklikleri test edin ve geri bildiriminizi bırakın. İşiniz bittiğinde:

cd ../ml-pipeline
git worktree remove ../ml-pipeline-reviewAltyapı:

Orijinal çalışmanız dokunulmadan kalır. Stash veya bağlam değişimi gerekmez. Etkili kod incelemeleri için daha fazla stratejiye göz atmak isterseniz, DataCamp'in kod inceleme en iyi uygulamaları rehberine bakın.

Acil hotfix'ler

Worktree olmadan:

• Refaktör değişikliklerinizi bir yere kaydedin (stash veya WIP commit)
• Ana dalı checkout edin
• Hata düzeltmesini yapın
• Üretime gönderin
• Özellik dalını checkout edin
• Değişikliklerinizi geri yükleyin (unstash veya WIP commit'i geri alın)
• Ne yaptığınızı zihninizde yeniden kurun

Worktree ile:

git worktree add ../ml-pipeline-hotfix main
cd ../ml-pipeline-hotfixAltyapı:

Düzeltin ve dağıtın:

git add src/data/validation.py
git commit -m "Fix schema validation for nullable timestamp fields"
git push origin main
cd ../ml-pipeline
git worktree remove ../ml-pipeline-hotfixAltyapı:

Saniyeler içinde refaktör çalışmanıza, tüm dosyalar tam bıraktığınız gibi, geri dönersiniz.

Paralel özellik geliştirme

Özel metrikler ve yeni bir veri yükleyici uyguluyorsunuz — iki bağımsız özellik. Her biri için bir worktree kurun:

git worktree add -b feature-custom-metrics ../ml-pipeline-metrics
git worktree add -b feature-streaming-loader ../ml-pipeline-loaderAltyapı:

Dosya sisteminiz artık şöyle görünür:

~/projects/
 ml-pipeline/           [main] - your usual work
 ml-pipeline-metrics/   [feature-custom-metrics]
 ml-pipeline-loader/    [feature-streaming-loader]Altyapı:

Her birini kendi terminalinde olmak üzere iki özelliği paralel olarak çalıştırın:

# Terminal 1
cd ~/projects/ml-pipeline-metrics
python experiments/evaluate_custom_metrics.py

# Terminal 2 
cd ~/projects/ml-pipeline-loader
pytest tests/test_data_loader.py -vAltyapı:

Her iki süreç de çakışma olmadan eşzamanlı çalışır. Bir özellik tamamlandığında, birleştirin ve worktree'yi kaldırın:

cd ~/projects/ml-pipeline
git merge feature-custom-metrics
git worktree remove ../ml-pipeline-metricsAltyapı:

Worktree'leri Yönetme ve Temizleme

Worktree listeleme

Bir depodaki tüm worktree'leri görmek için:

git worktree listAltyapı:

/Users/you/projects/ml-pipeline                  a3f9c81 [main]
/Users/you/projects/ml-pipeline-review           b7d4e92 [pr/data-validation]
/Users/you/projects/ml-pipeline-hotfix           a3f9c81 [hotfix/schema-bug]Altyapı:

Her satır dizin yolunu, geçerli commit özetini ve checkout edilmiş dalı gösterir. İlk giriş her zaman ana worktree'nizdir (.git klasörünü içerir), diğerleri bağlı worktree'lerdir.

Betik yazımı veya hızlı gezinme için yalnızca yolları çıkarın:

git worktree list | awk '{print $1}'Altyapı:

Worktree kaldırma

Bir worktree'deki işiniz bittiğinde, onu düzgün şekilde kaldırın:

cd ~/projects/ml-pipeline
git worktree remove ../ml-pipeline-reviewAltyapı:

Git veri kaybına karşı koruma sağlar. Commit'lenmemiş değişiklikleriniz varsa:

git worktree remove ../ml-pipeline-reviewAltyapı:

fatal: '../ml-pipeline-review' contains modified or untracked files, use --force to delete itAltyapı:

Eminseniz zorla kaldırın:

git worktree remove --force ../ml-pipeline-reviewAltyapı:

Bir worktree kilitliyse, --force iki kez kullanın:

git worktree remove --force --force ../ml-pipeline-lockedAltyapı:

rm -rf veya dosya yöneticisiyle bir worktree dizinini manuel olarak sildiyseniz, Git onu içsel olarak hâlâ takip eder. Bayat referansları temizleyin:

git worktree pruneAltyapı:

Nelerin budanacağını önizleyin:

git worktree prune --dry-runAltyapı:

En İyi Uygulamalar ve Yaygın Tuzaklar

Worktree'lerden en iyi şekilde nasıl yararlanabileceğinize ve yaygın hatalardan nasıl kaçınacağınıza bakalım. 

Worktree organizasyonu

Worktree'leri nereye koyduğunuz önemlidir. Çoğu geliştirici onları ana deponun kardeş dizinleri olarak yerleştirir:

~/projects/
 ml-pipeline/                    # main worktree
 ml-pipeline-feature-auth/       # linked worktree
 ml-pipeline-hotfix-login/       # linked worktreeAltyapı:

Bu yapı her şeyi tek yerde tutar ve yolları öngörülebilir kılar. projectname-branchname kalıbı, her dizinin tam olarak ne içerdiğini söyler.

Bazı geliştiriciler özel bir klasörü tercih eder:

~/projects/
 ml-pipeline/                    # main worktree
 ml-pipeline-worktrees/
   feature-auth/
   hotfix-login/Altyapı:

Bir yaklaşım seçin ve tutarlı şekilde kullanın. ml-pipeline-user-authentication gibi açıklayıcı adlar dizinleri kendiliğinden belgeleyici yapar; ml-pipeline-temp veya ml-pipeline-2 gibi genel adlar ise içindekileri kontrol etmeye zorlar. Worktree'leri geçici olarak değerlendirin — belirli bir görev için oluşturun, işiniz bitince kaldırın.

Yaygın tuzaklar

Aynı dalın birden fazla worktree'de kullanılması

Git, aynı dalın iki worktree'de checkout edilmesini engeller:

git worktree add ../ml-pipeline-duplicate mainAltyapı:

fatal: 'main' is already used by worktree at '/Users/you/projects/ml-pipeline'Altyapı:

Bu koruma, çakışan commit'ler yapabilme ihtimaliniz nedeniyle vardır. Aynı koda iki yerde ihtiyacınız varsa, yeni bir dal oluşturun.

Unutulan worktree'ler ve disk alanı

Her worktree, siz açıkça kaldırana kadar dosya sisteminizde kalır. Eski worktree'ler birikir; projeler gigabaytlar tüketen 15+ unutulmuş worktree'ye sahip olabilir.

Her worktree, deponuzun dosyalarının tam bir kopyasını içerir. 5 worktree'li 500MB'lık bir depo 2.5GB tüketir. İşiniz bitince worktree'leri kaldırın:

git worktree list
git worktree remove ../ml-pipeline-old-featureAltyapı:

İç içe worktree oluşturma

Başka bir worktree'nin dizini içinde worktree oluşturmayın. Git buna izin verse de kafa karıştırıcı dizin yapıları oluşturur ve temizliği hataya açık hale getirir.

İş akışı optimizasyonu

Worktree'leri sık oluşturuyorsanız kabuk kısayolları zaman kazandırır:

alias gwl='git worktree list'
alias gwa='git worktree add'
alias gwr='git worktree remove'Altyapı:

Daha karmaşık kurulumlar için, bir worktree oluşturan ve geliştirme ortamınızı tek adımda yapılandıran bir işlev yazın:

wt() {
 git worktree add "../${PWD##*/}-$1" -b "$1"
 cd "../${PWD##*/}-$1"
 python -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt
}Altyapı:

${PWD##*/} mevcut dizin adınızı çıkarır. ml-pipeline içinde wt feature-logging çalıştırmak, ml-pipeline-feature-logging oluşturur, içine gider ve bağımlılıklarıyla bir Python sanal ortamı kurar.

Worktree oluşturmak tek komuta iner:

wt feature-custom-metricsAltyapı:

Bunu kendi dilinize uyarlayın: Ruby için bundle install, Rust için cargo build veya Node.js için npm install ile Python kurulumunu değiştirin.

Editörünüz veya IDE'niz, özel bir yapılandırma olmadan worktree'lerle çalışır. Her worktree yalnızca bir dizindir; bu yüzden herhangi bir proje klasörü gibi açın. Çoğu modern editör birden çok proje kökünü aynı anda açmayı destekler — tek pencerede üç worktree açabilir ve kenar çubuğunda aralarında geçiş yapabilirsiniz.

İleri Düzey Worktree'ler: Yapay Zekâ Destekli Paralel Geliştirme

Yapay zekâ kod yardımcıları kullanıyorsanız, worktree'ler güçlü bir paralel iş akışının kapılarını açar. Bu yaklaşım 2024–2025 arasında geliştiriciler ve ekipler arasında ilgi gördü.

Farklı görevler için ayrı worktree'ler oluşturun:

git worktree add -b feature-add-logging ../ml-pipeline-logging
git worktree add -b feature-optimize-preprocessing ../ml-pipeline-optim
git worktree add -b bugfix-memory-leak ../ml-pipeline-bugfixAltyapı:

Her worktree için bir terminal bölmesi açın ve yapay zekâ asistanınızı başlatın:

# Pane 1
cd ~/projects/ml-pipeline-logging
claude

# Pane 2
cd ~/projects/ml-pipeline-optim
claude

# Pane 3
cd ~/projects/ml-pipeline-bugfix
claudeAltyapı:

Her yapay zekâ örneği, müdahale olmadan farklı bir özellik üzerinde çalışır. Ekipler, daha önce günler süren işleri saatler içinde tamamladıklarını bildiriyor. Örneğin, incident.io bu deseni kullanarak 4–5 Claude Code aracını paralel çalıştırıyor. Bir durumda Claude, bir UI iyileştirmesinin 2 saat süreceğini tahmin etti ancak 10 dakikada bitirdi.

Dikkate alınacak ödünler:

• Token tüketimi: Birden fazla yapay zekâ oturumu daha fazla API kredisi kullanır ve hız limitlerine takılabilir
• Kurulum yükü: Her worktree kendi sanal ortamına ve bağımlılıklarına ihtiyaç duyar
• Bilişsel yük: Farklı görevler arasında birden fazla sohbeti yönetmek

Bu yöntem, aynı dosyalara dokunmayan büyük, bağımsız özellikler (her biri 30+ dakika) ve yeterli API kotası olduğunda iyi çalışır. Hızlı hata düzeltmeleri, sıkı bağlanmış özellikler veya API hız limitlerine yakın olduğunuz durumlarda atlayın.

Sonuç

Başlangıçtaki senaryoyu hatırlayın — siz özellik ortasındayken bir ekip arkadaşınız PR incelemesi istiyor. Artık çözümü biliyorsunuz: git worktree add ../ml-pipeline-review pr/branch-name, ardından incelemeye başlamak için cd. Özellik çalışmanız dokunulmadan kalır. Stash yok, yarım kalmış kodu commit etmek yok, geri döndüğünüzde zihinsel bağlamı yeniden kurma yok. İki dizin, iki dal, sıfır sürtünme.

Git worktree iş akışınıza karmaşıklık katmaz — onu azaltır. Her worktree, checkout edilmiş bir dala sahip bir dizinden ibarettir. Ancak bu sadelik, stash, checkout ve zihinsel modelinizi yeniden inşa etmenin bilişsel yükü olmadan görevler arasında anında bağlam değiştirme gücünü açığa çıkarır. 

Worktree'leri pull request ve kod incelemeleri gibi ekip iş birliği iş akışlarıyla entegre etmeniz gerektiğinde, DataCamp'in GitHub Foundations yetkinlik programı dağıtık ekiplerle etkili çalışmanın temel uygulamalarını kapsar.