Ana içeriğe atla

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

Aynı anda birden fazla dalda çalışmayı, incelemeleri hızlandırmayı ve stash veya bağlam değiştirmeden kaçınmayı gösteren pratik bir Git worktree eğitimi.
Güncel 16 Nis 2026  · 9 dk. oku

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.

Depo mimarisini gösteren diyagram - ortada .git klasörü bulunan ana worktree, ona bağlanan birden çok worktree. Oklar her worktree dizininde "paylaşılan commit'ler/dallar/referanslar" ile "bağımsız çalışma dosyaları"nı gösteriyor

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 --help

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 init

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.py

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

ls
# You should see: README.md  train.py

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

git add .
git commit -m "Initial commit"
git branch feature-preprocessing

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-preprocessing

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 commit

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

git worktree add -b feature-visualization ../ml-pipeline-viz

-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 list
/Users/you/projects/ml-pipeline                  0a7f986 [main]
/Users/you/projects/ml-pipeline-preprocessing    0a7f986 [feature-preprocessing]

İ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.

GÖRSEL YER TUTUCU: Worktree'ler arasındaki ilişkiyi gösteren dosya sistemi diyagramı. Ana dizin ml-pipeline/ içinde worktrees/ alt dizinine sahip .git/ klasörü bulunur. Bağlı worktree ml-pipeline-preprocessing/ içinde, ana .git/ klasörüne geri işaret eden .git dosyası (klasör değil) bulunur. Her iki dizin de kendi dosyalarını (README.md, train.py) gösterir ancak aynı Git veritabanını paylaşır.

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"

Commit normal şekilde gerçekleşir:

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

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

cd ../ml-pipeline
git log --oneline --all

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

7c8d4e2 Add feature preprocessing function
0a7f986 Initial commit

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.yaml

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

cd ../ml-pipeline
git worktree remove ../ml-pipeline-review

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

Yan yana iş akışı karşılaştırması. Sol tarafta "Geleneksel yaklaşım": 7 ardışık adımı gösterir (stash → checkout → düzelt → gönder → checkout → unstash → bağlamı geri kazan) 15+ dakika alır. Sağ tarafta "Worktree ile": 3 paralel kutu gösterir (ana worktree çalışmaya devam eder, hotfix worktree oluşturulur/düzeltilir/kaldırılır) 2 dakika sürer, basit cd komutlarıyla.

Worktree ile:

git worktree add ../ml-pipeline-hotfix main
cd ../ml-pipeline-hotfix

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-hotfix

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-loader

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]

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 -v

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-metrics

Worktree'leri Yönetme ve Temizleme

Worktree yaşam döngüsünü gösteren akış şeması - Oluştur → Çalış → Commit → Kaldır/Budama, karar noktalarıyla: "İş bitti mi?", "Temiz durum mu?", "Manuel silme mi?"

Worktree listeleme

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

git worktree list
/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]

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}'

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-review

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

git worktree remove ../ml-pipeline-review
fatal: '../ml-pipeline-review' contains modified or untracked files, use --force to delete it

Eminseniz zorla kaldırın:

git worktree remove --force ../ml-pipeline-review

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

git worktree remove --force --force ../ml-pipeline-locked

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 prune

Nelerin budanacağını önizleyin:

git worktree prune --dry-run

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 worktree

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/

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 main
fatal: 'main' is already used by worktree at '/Users/you/projects/ml-pipeline'

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-feature

İç 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'

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
}

${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-metrics

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-bugfix

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
claude

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.

Git Worktree SSS

Git worktree&#39;leri GitHub Desktop, VS Code veya diğer GUI araçlarıyla kullanabilir miyim?

Evet. Worktree'ler editörler ve Git GUI'leri için normal proje klasörleri gibi görünür. Her worktree'yi ayrı bir proje olarak açabilirsiniz ve VS Code, IntelliJ ve GitHub Desktop dahil çoğu araç, özel bir yapılandırmaya gerek olmadan bunları destekler.

Git worktree&#39;ler origin gibi uzaklarla nasıl etkileşime girer?

Tüm worktree'ler aynı .git dizinini paylaşır, bu nedenle aynı uzak yapılandırmayı ve fetch geçmişini paylaşırlar. Her worktree'de git fetch çalıştırmanız gerekmez — birinde fetch yapmak, hepsi için uzakları günceller. Dal izleme, tek worktree'li bir kurulumdakiyle tamamen aynı şekilde davranır.

Bir worktree dizinini git worktree remove yerine manuel olarak silersem ne olur?

Git, worktree'nin hâlâ var olduğunu düşünecek ve onu “budanabilir” olarak işaretleyecektir. Depoyu bozmazsınız, ancak Git komutları uyarılar gösterebilir. Eski girdiyi güvenle temizlemek ve yetim meta verileri kaldırmak için git worktree prune çalıştırın.

Git worktree&#39;leri büyük monorepo&#39;lar veya Bazel, Pants, Nx gibi derleme sistemleriyle kullanmak güvenli midir?

Evet, ancak derleme çıktıları hızla çoğalabilir. Her worktree kendi çalışma dizinine sahiptir; bu nedenle önbellekler, sanal ortamlar ve derleme çıktıları çoğaltılır. Monorepo'larda, aşırı disk kullanımından kaçınmak için önbellekleri worktree dışında saklayacak şekilde derleme araçlarını yapılandırmak yaygındır.

Git worktree&#39;lerini alt modüller veya seyrek checkout&#39;larla kullanabilir miyim?

Evet. Alt modüller ve seyrek checkout'lar worktree'lerde normal şekilde çalışır, ancak çalışma dizini içeriği paylaşılmadığından bunları her worktree'de ayrı ayrı başlatmanız veya güncellemeniz gerekir. Temel Git verisi yine paylaşımlıdır, ancak checkout edilen dosyalar bağımsızdır.


Bex Tuychiev's photo
Author
Bex Tuychiev
LinkedIn

2 yılı aşkın deneyime sahip bir veri bilimi içerik üreticisiyim ve Medium'da en büyük takipçi kitlelerinden birine sahibim. Yapay zeka ve makine öğrenimi üzerine, biraz da alaycı bir üslupla, ayrıntılı yazılar yazmayı seviyorum; çünkü bu konuları biraz olsun sıkıcılıktan çıkarmak gerekiyor. 130'dan fazla makale ve bir DataCamp kursu hazırladım; bir diğeri de yolda. İçeriklerim 5 milyondan fazla kişi tarafından görüntülendi; bunların 20 bini Medium ve LinkedIn'de takipçim oldu. 

Konular

En İyi Git Kursları

Kurs

Git'e Giriş

2 sa
71.6K
Yazılım ve veri projelerinizde sürüm kontrolü için Git'in temellerini keşfedin.
Ayrıntıları GörRight Arrow
Kursa Başla
Devamını GörRight Arrow
İlgili

blog

Hızlı Sevkiyat İçin Pratik Vibe Kodlama Teknoloji Yığını

Ön uç, arka uç, veritabanları, kimlik doğrulama, depolama, e-posta, test, dağıtım ve izleme için en iyi araçları keşfedin.
Abid Ali Awan's photo

Abid Ali Awan

14 dk.

blog

2026’da En Popüler 40 Yazılım Mühendisi Mülakat Sorusu

Algoritmalar, sistem tasarımı ve davranışsal senaryoları kapsayan bu temel sorularla teknik mülakat sürecine hakim olun. Uzman cevapları, kod örnekleri ve kanıtlanmış hazırlık stratejileri edinin.
Dario Radečić's photo

Dario Radečić

15 dk.

Eğitim

.gitignore Nasıl Kullanılır: Örneklerle Pratik Bir Giriş

Git deponuzu temiz tutmak için .gitignore’u nasıl kullanacağınızı öğrenin. Bu eğitim; temelleri, yaygın kullanım durumlarını ve başlamanıza yardımcı olacak pratik örnekleri kapsar!
Kurtis Pykes 's photo

Kurtis Pykes

Eğitim

Python'da Listeyi String'e Nasıl Dönüştürürsünüz

Bu hızlı eğitimde, Python'da bir listeyi string'e nasıl dönüştüreceğinizi öğrenin.
Adel Nehme's photo

Adel Nehme

Devamını GörDevamını Gör