Git Stash ve Tag’leri: Geliştiriciler İçin Rehber

Git Stash ve Tag’leri: Geçici Çalışmaları ve Sürümleri Yönetmek

Git stash ve Git tag’leri birbirinden çok farklı iki sorunu çözer.

Stash geçicidir. Tamamlanmamış yerel değişiklikleri bir kenara almanıza, daha temiz bir çalışma durumuna dönmenize ve çalışmayı daha sonra geri getirmenize yardımcı olur. Tag ise kalıcıdır. Önemli bir Git nesnesine—genellikle bir commit’e—sabit bir ad verir; böylece ekip bir sürümü, deployment’ı, kilometre taşını veya tarihsel kontrol noktasını tanımlayabilir.

Her ikisi de proje durumuna bir referans sağladığı için bu komutlar çoğu zaman birlikte tanıtılır; ancak birbirine karıştırılmamalıdır. Stash’ler genellikle tek bir yerel depoda kalan kişisel çalışma araçlarıdır. Tag’ler ise çoğu zaman ekiple paylaşılan ve sürüm iş akışlarında kullanılan depo referanslarıdır.

Bu rehber iki özelliği de ayrıntılı biçimde açıklar. Stash oluşturmayı, incelemeyi, uygulamayı, silmeyi ve kurtarmayı; tracked, untracked, staged ve ignored dosyaların davranışını; stash conflict’lerini çözmeyi; lightweight, annotated ve signed tag oluşturmayı; eski commit’leri etiketlemeyi; tag’leri incelemeyi ve doğrulamayı; güvenli biçimde yayınlamayı ve tehlikeli yeniden etiketleme hatalarından kaçınmayı öğreneceksiniz.

Neler Öğreneceksiniz?

Git stash’in neyi kaydettiğini ve ne zaman uygun olduğunu.
stash push, apply ve pop arasındaki farkı.
Staged, unstaged, untracked ve ignored dosyaların stash’i nasıl etkilediğini.
Seçilen path’lerin veya hunk’ların nasıl stash edileceğini.
--keep-index ile index’in nasıl korunacağını.
Yalnızca staged değişikliklerin nasıl stash edileceğini.
Stash’lerin nasıl inceleneceğini, kavramsal olarak adlandırılacağını, branch’e dönüştürüleceğini, drop edileceğini ve temizleneceğini.
Stash conflict’lerinin nasıl oluştuğunu ve çözüldüğünü.
Lightweight, annotated ve signed tag’lerin neyi temsil ettiğini.
Tag’lerin branch’lerden nasıl ayrıldığını.
Daha eski bir commit’in nasıl etiketleneceğini.
Tag’lerin nasıl listeleneceğini, filtreleneceğini, sıralanacağını, inceleneceğini, silineceğini ve değiştirileceğini.
Tekil tag’lerin ve seçilen release tag’lerinin nasıl push edileceğini.
Yayınlanmış bir tag’i değiştirmenin neden tehlikeli olduğunu.
Tag’lerin release ve deployment iş akışlarını nasıl desteklediğini.

Birinci Bölüm: Git Stash’i Anlamak

Git stash, seçilen working tree ve index değişikliklerinin mevcut durumunu kaydeder; ardından bu alanları normalde HEAD tarafından temsil edilen duruma geri döndürür.

Yaygın bir senaryo şöyledir:

Bir özelliğin ortasındasınız.
Acil bir düzeltme başka bir branch’e geçmenizi gerektiriyor.
Mevcut değişiklikler anlamlı bir commit için henüz hazır değil.
Geçerli working tree ile hedef branch’e güvenle geçilemiyor.
Tamamlanmamış çalışmayı stash’e alıyor, acil görevi tamamlıyor ve daha sonra çalışmayı geri yüklüyorsunuz.

En basit komut:

git stash push

Tarihsel olarak kullanılan kısa biçim:

git stash

Modern ve açık iş akışlarında git stash push daha anlaşılırdır; çünkü mesajları, pathspec’leri ve seçim seçeneklerini kabul eder.

Stash Normal Bir Branch veya Commit Değildir

Stash dahili olarak Git nesneleri ve commit benzeri yapılar üzerinden temsil edilir; ancak sıradan bir geliştirme branch’i yerine özel bir referans ve reflog aracılığıyla yönetilir.

Stash’ler normalde stack benzeri bir listede görünür:

stash@{0}
stash@{1}
stash@{2}

stash@{0} genellikle en yeni stash’tir.

Stash, önemli çalışmalar için kalıcı depolama sistemi haline gelmemelidir. Uzun ömürlü ve anlamlı geliştirme çalışmaları, anlaşılır commit’lere sahip bir branch üzerinde daha güvenlidir.

Git Stash Ne Zaman Kullanılmalı?

Stash şu durumlarda kullanışlıdır:

Geçici olarak başka bir branch’e geçmeniz gerektiğinde.
Pull, rebase veya test öncesinde temiz working tree gerektiğinde.
Mevcut çalışmayı temiz proje durumuyla karşılaştırmak istediğinizde.
Bir sonraki commit’e girmemesi gereken ilgisiz yerel düzenlemeler bulunduğunda.
Riskli bir işlem öncesinde kısa ömürlü yerel checkpoint istediğinizde.
Tamamlanmamış değişiklikleri yeni bir branch’e taşımak istediğinizde.

Stash şu durumlarda daha az uygundur:

Çalışma zaten commit edilebilecek anlamlı bir checkpoint olduğunda.
Çalışmanın başka bir geliştiriciyle paylaşılması gerektiğinde.
Değişikliklerin uzun vadeli ve güvenilir biçimde korunması gerektiğinde.
Belirsiz mesajlara sahip çok sayıda eski stash bulunduğunda.
Commit ve branch düzenlemekten kaçınmak için stash kullanıldığında.

Deneme Deposu Oluşturun

Örneklerde Task Notes adlı küçük bir proje kullanılacaktır.

macOS, Linux veya Git Bash

mkdir git-stash-tags-demo
cd git-stash-tags-demo
git init -b main

cat > app.txt <<'EOF'
Task Notes
Depolama: yerel
Arama: devre dışı
EOF

cat > README.md <<'EOF'
# Task Notes

Git stash ve tag’lerini uygulamak için küçük bir proje.
EOF

git add app.txt README.md
git commit -m "Task Notes projesini oluştur"

PowerShell

New-Item -ItemType Directory git-stash-tags-demo
Set-Location git-stash-tags-demo
git init -b main

@"
Task Notes
Depolama: yerel
Arama: devre dışı
"@ | Set-Content app.txt

@"
# Task Notes

Git stash ve tag’lerini uygulamak için küçük bir proje.
"@ | Set-Content README.md

git add app.txt, README.md
git commit -m "Task Notes projesini oluştur"

Başlangıç noktasını doğrulayın:

git status
git log --oneline

İlk Stash’inizi Oluşturun

app.txt dosyasını değiştirin:

Task Notes
Depolama: yerel
Arama: anahtar kelime

Depoyu kontrol edin:

git status
git diff

Yararlı bir mesajla stash oluşturun:

git stash push -m "WIP: anahtar kelime aramasını ekle"

Durumu inceleyin:

git status

Tracked değişiklik normalde working tree’den kaldırılarak mevcut commit durumuna dönmelidir.

Stash’leri listeleyin:

git stash list

Örnek:

stash@{0}: On main: WIP: anahtar kelime aramasını ekle

Tam çıktı branch ve commit bağlamını içerebilir.

Stash’e Her Zaman Mesaj Ekleyin

Özel mesaj olmadan birden fazla stash’i ayırt etmek zorlaşabilir:

stash@{0}: WIP on main: ...
stash@{1}: WIP on main: ...
stash@{2}: WIP on main: ...

Yararlı bir mesaj tamamlanmamış görevi açıklar:

git stash push -m "WIP: içe aktarılan görev tarihlerini doğrula"
git stash push -m "Debug: yavaş rapor sorgusunu incele"
git stash push -m "Experiment: yeni arama sonucu düzeni"

Ön ek isteğe bağlıdır. Önemli olan mesajın çalışmayı daha sonra tanımanızı sağlamasıdır.

Bir Stash’i İnceleyin

En son stash’in özetini gösterin:

git stash show

Tam patch’i gösterin:

git stash show -p

Seçilen stash’i inceleyin:

git stash show -p stash@{1}

Stat özetini kullanın:

git stash show --stat stash@{0}

Eski bir stash’i uygulamadan önce içeriğini inceleyin. Mesaj, içerdiği tüm dosyaları göstermeyebilir.

Apply ve Pop Farkı

En son stash’i listede tutarak geri yükleyin:

git stash apply

Seçilen stash’i geri yükleyin:

git stash apply stash@{1}

En son stash’i geri yükleyin ve başarılı uygulama sonrasında listeden kaldırın:

git stash pop

Seçilen stash’i pop edin:

git stash pop stash@{1}

Komut	Değişiklikleri Geri Yükler	Stash’i Otomatik Kaldırır
`git stash apply`	Evet	Hayır
`git stash pop`	Evet	Başarılı uygulamadan sonra

Daha güvenli inceleme adımı istediğinizde veya aynı stash’i birden fazla yerde kullanmanız gerektiğinde apply kullanın. Stash’in geri yüklenip kaldırılacağından eminseniz pop kullanın.

Conflict temiz bir pop işlemini engellediğinde Git normalde stash’i otomatik kaybetmemeniz için listede tutar.

Stash Untracked Dosyaları İçerir mi?

Varsayılan olarak git stash push temel olarak tracked değişiklikleri ve staged değişiklikleri kaydeder. Normal untracked dosyalar otomatik olarak dahil edilmez.

Untracked dosya oluşturun:

echo "Geçici arama notları" > search-notes.txt

Kontrol edin:

git status --short

Tracked ve untracked değişiklikleri stash’e alın:

git stash push -u -m "WIP: arama uygulaması ve notlar"

Uzun seçenek:

git stash push --include-untracked

Ardından untracked dosya normalde working tree’den kaldırılıp stash içinde saklanmalıdır.

Ignored Dosyaları Stash’e Almak

Ignored dosyalar -u ile dahil edilmez.

Ignored dosyaları da dahil etmek için:

git stash push -a -m "WIP: üretilmiş yerel dosyaları dahil et"

Uzun seçenek:

git stash push --all

--all seçeneğini dikkatli kullanın. Ignored dizinler şunları içerebilir:

Büyük dependency klasörleri.
Build çıktıları.
Log’lar.
Yerel cache’ler.
Üretilmiş asset’ler.
Ortama özel dosyalar.

Tüm ignored içeriği stash’e almak yavaş olabilir ve depo içinde önemli alan tüketebilir.

Stash İçindeki Staged ve Unstaged Değişiklikler

Bir dosya aynı anda staged ve unstaged değişiklikler içerebilir.

Örnek:

README.md dosyasını düzenleyin.
git add README.md çalıştırın.
README.md dosyasını tekrar düzenleyin.
git status --short çalıştırın.

Şunu görebilirsiniz:

MM README.md

Normal stash hem index durumunu hem working tree durumunu koruyabilir. Ancak geri yükleme biçimi apply seçeneklerine bağlıdır.

Staged durumu da geri yüklemeyi denemek için:

git stash apply --index

Veya:

git stash pop --index

--index olmadan içerik geri yüklenebilir, ancak aynı staged düzeni yeniden oluşturulmayabilir.

Mevcut depo durumu eski staging yapısının temiz biçimde yeniden oluşturulmasına izin vermediğinde index geri yüklemesi başarısız olabilir.

Staged Değişiklikleri Yerinde Tutun

Bazen tamamlanmış bir staged düzeltmeniz ve buna ek tamamlanmamış working tree değişiklikleriniz vardır. Yalnızca tamamlanmamış kısmı stash’e alıp index’i commit için hazır tutmak isteyebilirsiniz.

Şunu kullanın:

git stash push --keep-index -m "WIP: tamamlanmamış dokümantasyon düzenlemeleri"

Staged değişiklikler hazır kalırken diğer uygun değişiklikler stash’e alınır.

Uygulamalı bir iş akışı:

git add fix.php
git stash push --keep-index -m "WIP: ilgisiz deneyler"
git diff --staged
git commit -m "Fatura yuvarlamasını düzelt"
git stash pop

Stash işleminden sonra her zaman durumu inceleyin. Seçenekler farklı depo katmanlarını etkiler ve staged ile unstaged sürümlerin karışımı dikkatli inceleme gerektirir.

Yalnızca Staged Değişiklikleri Stash’e Alın

Index içeriğini stash’e alıp diğer working tree değişikliklerini görünür bırakmak istediğinizde:

git stash push --staged -m "WIP: staged arama uygulaması"

Staged değişiklikler ayrı bir grup oluşturuyor ve unstaged çalışma görünür kalacaksa kullanışlıdır.

Öncesinde ve sonrasında inceleyin:

git status
git diff
git diff --staged
git stash push --staged -m "WIP: staged arama uygulaması"
git status

Staged ve unstaged değişiklikler Git’in güvenle ayıramayacağı şekilde çakışıyorsa işlem durabilir veya değişiklikleri önce yeniden düzenlemeniz gerekebilir.

Seçilen Dosyaları Stash’e Alın

Tüm working tree’yi stash’e almak zorunda değilsiniz.

Tek dosyayı stash’e alın:

git stash push -m "WIP: README yeniden yazımı" -- README.md

Birden fazla path’i stash’e alın:

git stash push -m "WIP: arama dosyaları" -- app.txt search-notes.txt

Bir dizini stash’e alın:

git stash push -m "WIP: rapor modülü" -- src/Report/

--, komut seçeneklerini pathspec’lerden ayırır.

Path ile sınırlı stash, aynı working tree içinde birden fazla bağımsız görev karıştığında kullanışlıdır; ancak çalışmayı daha erken aşamada branch ve commit’lerle ayırmak çoğu zaman daha temizdir.

--patch ile Etkileşimli Stash

Seçilen hunk’ları etkileşimli biçimde stash’e alın:

git stash push -p -m "WIP: seçilen arama değişiklikleri"

Uzun seçenek:

git stash push --patch

Git hunk’ları gösterir ve her birinin dahil edilip edilmeyeceğini sorar.

Yaygın yanıtlar:

y: Bu hunk’ı dahil et.
n: Bu hunk’ı working tree içinde bırak.
s: Mümkünse hunk’ı böl.
e: Patch’i manuel düzenle.
q: Seçimi durdur.
?: Yardımı göster.

Ardından çalıştırın:

git status
git stash show -p stash@{0}

Amaçlanan hunk’ların stash’e girdiğini ve kalan düzenlemelerin working tree içinde kaldığını doğrulayın.

Temiz Working Tree’yi Stash’e Alabilir misiniz?

Uygun yerel değişiklik bulunmadığında Git normalde kaydedilecek bir şey olmadığını bildirir.

Stash, zaten commit edilmiş bir durum için adlandırılmış checkpoint oluşturmanın yerine kullanılmaz. Bu amaçla branch veya tag kullanın.

Stash’i Başka Bir Branch’te Uygulayın

Stash, oluşturulduğu branch’e kalıcı olarak bağlı değildir.

Başka branch’e geçip uygulayabilirsiniz:

git switch feature/search
git stash apply stash@{0}

Değişiklikler yanlış branch üzerinde başlatıldıysa kullanışlıdır.

Ancak stash’i farklı bir kod durumuna uygulamak conflict olasılığını artırır. Önce branch farkını ve stash patch’ini inceleyin.

Stash’ten Branch Oluşturun

Stash oluşturulduğundan beri mevcut branch önemli ölçüde değiştiyse doğrudan uygulamak conflict oluşturabilir.

Şunu kullanın:

git stash branch feature/search-recovery stash@{0}

Bu komut stash’in ilk oluşturulduğu commit’ten yeni bir branch oluşturur, ona geçer, stash’i uygular ve uygulama başarılı olursa stash’i drop eder.

Eski bir stash’i normal branch tabanlı çalışmaya dönüştürmenin en güvenli yollarından biridir.

Stash Conflict’leri

Mevcut dosyalar stash değişiklikleriyle uyumsuz biçimde değiştiğinde stash uygulaması conflict oluşturabilir.

Örnek:

Depolama satırındaki değişikliği stash’e alın.
Aynı satırda farklı bir değişikliği commit edin.
Eski stash’i uygulayın.

Git conflict işaretleri ekleyebilir:

<<<<<<< Updated upstream
Depolama: şifreli yerel
=======
Depolama: bulut
>>>>>>> Stashed changes

Conflict’i merge conflict’i gibi çözün:

git status çalıştırın.
Her conflict içeren dosyayı açın.
Mevcut ve stash içindeki niyeti anlayın.
Doğru birleşik sonucu düzenleyin.
Conflict işaretlerini kaldırın.
Çözülen dosyaları git add ile stage edin.
Testleri çalıştırın.
Geri getirilen çalışma anlamlı duruma ulaştığında commit oluşturun.

Aktif merge işleminden farklı olarak stash uygulaması aynı git merge --abort iş akışını sağlamaz. Kurtarma belirsizleşirse dosyaları reset veya restore etmeden önce mevcut çalışmayı koruyun.

Tek Bir Stash’i Drop Edin

Seçilen stash’i silin:

git stash drop stash@{1}

En son stash’i silin:

git stash drop

Drop etmeden önce stash’i inceleyin:

git stash show -p stash@{1}

Bir stash drop edildikten sonra liste reflog tabanlı olduğu için stash indeksleri değişebilir. Başka bir konuma başvurmadan önce git stash list komutunu yeniden çalıştırın.

Tüm Stash’leri Temizleyin

git stash clear

Bu komut stash referansındaki tüm girişleri kaldırır.

Varsayılan olarak etkileşimli onay istemez. Temizlemeden önce:

git stash list
git stash show -p stash@{0}
git stash show -p stash@{1}

Önemli çalışmalar stash listesinde bırakılmak yerine branch veya commit’e dönüştürülmelidir.

Drop Edilmiş Bir Stash’i Kurtarmak

Yakın zamanda drop edilmiş bir stash sınırlı süre boyunca unreachable Git nesneleri olarak kalabilir; ancak kurtarma garanti edilmez.

Olası inceleme araçları:

git fsck --unreachable
git fsck --no-reflogs

Dangling veya unreachable commit benzeri nesneleri bulabilir ve adayları şu komutla inceleyebilirsiniz:

git show <object-id>

Doğru nesne bulunursa hemen koruyun:

git branch stash-recovery <object-id>

Kurtarma; garbage collection, depo bakımı ve nesne reachability durumuna bağlıdır. Drop edilmiş veya temizlenmiş stash’leri potansiyel olarak kaybolmuş kabul edin.

Gelişmiş Stash Oluşturma Komutları

Çoğu geliştirici git stash push kullanmalıdır. Git ayrıca daha düşük seviyeli stash işlemleri sunar.

Stash Listesine Kaydetmeden Oluşturun

git stash create "geçici stash nesnesi"

Bu komut stash benzeri bir commit nesnesi oluşturup kimliğini yazdırır; normal stash referansını güncellemez.

Mevcut Stash Nesnesini Saklayın

git stash store -m "Kurtarılan geçici çalışma" <object-id>

Bu komutlar script ve kurtarma iş akışlarında kullanışlıdır; ancak push komutuna göre yanlış kullanıma daha açıktır.

Stash İçin En İyi Uygulamalar

Açıklayıcı mesajlar kullanın.
Stash oluşturmadan önce working tree’yi inceleyin.
Yalnızca untracked dosyalar gerekli olduğunda -u kullanın.
Ignored dosyaların gerçekten korunması gerekmiyorsa -a kullanmaktan kaçının.
Bir stash’i uygulamadan veya drop etmeden önce inceleyin.
Durum riskliyse pop yerine apply tercih edin.
Staged düzeni geri yüklemek önemli olduğunda --index kullanın.
Uzun ömürlü stash’leri branch’e dönüştürün.
Stash’i anlamlı commit’lerin yerine kullanmayın.
Artık gerekmediğini doğruladıktan sonra eski stash’leri temizleyin.

İkinci Bölüm: Git Tag’lerini Anlamak

Git tag’i, belirli bir nesneye—genellikle bir commit’e—okunabilir bir ad verir.

Tag’ler yaygın olarak şu amaçlarla kullanılır:

Yazılım sürümleri.
Production deployment’ları.
Herkese açık kilometre taşları.
Uyumluluk baseline’ları.
Önemli tarihsel checkpoint’ler.
İmzalı release referansları.

Branch’ten farklı olarak tag, yeni commit’ler oluşturulduğunda otomatik olarak hareket etmez.

Tag ve Branch Farkı

Bir branch ve tag’in ikisinin de C commit’ine işaret ettiğini varsayın:

A---B---C
        ^ main
        ^ v1.0.0

main üzerinde yeni commit oluşturun:

A---B---C---D
        ^     ^
      v1.0.0  main

Branch D commit’ine ilerler. Tag C üzerinde kalır.

Branch	Tag
Yeni commit’ler oluşturuldukça hareket eder	Normalde sabit kalır
Aktif bir geliştirme hattını temsil eder	Belirli bir nesneyi veya kilometre taşını işaretler
Devam eden çalışma için genellikle checkout edilir	Genellikle incelenir veya release referansı olarak kullanılır
Branch referansları altında saklanır	Tag referansları altında saklanır

Tag’leri Listeleyin

Tüm tag’leri listeleyin:

git tag

Eşdeğer liste biçimi:

git tag --list

Shell tarzı pattern ile filtreleyin:

git tag --list "v1.*"

Varsa annotation bilgileriyle listeleyin:

git tag -n

Daha fazla mesaj satırı gösterin:

git tag -n3

Lightweight Tag’ler

Lightweight tag, doğrudan bir nesneye—genellikle commit’e—işaret eden bir addır.

Geçerli commit üzerinde oluşturun:

git tag v0.1.0

İnceleyin:

git show v0.1.0

Lightweight tag; tagger, tarih ve mesaj içeren ayrı bir annotated tag nesnesi oluşturmaz.

Lightweight tag’ler şu amaçlarla kullanılabilir:

Geçici yerel etiketler.
Kişisel bookmark’lar.
Kısa ömürlü test işaretleri.
Basit dahili checkpoint’ler.

Resmî sürümlerde annotated tag’ler genellikle daha fazla bilgi sağlar.

Annotated Tag’ler

Annotated tag oluşturun:

git tag -a v1.0.0 -m "Sürüm 1.0.0"

Annotated tag şu meta verileri içeren tag nesnesi oluşturur:

Etiketlenen nesnenin referansı.
Tag adı.
Tagger adı ve e-posta adresi.
Oluşturulma tarihi.
Annotation mesajı.
Signing kullanıldığında isteğe bağlı kriptografik imza.

İnceleyin:

git show v1.0.0

Çıktı normalde tag mesajını ve referans verilen commit hakkındaki bilgileri içerir.

Lightweight ve Annotated Tag Farkı

Özellik	Lightweight Tag	Annotated Tag
Ayrı tag nesnesi	Hayır	Evet
Tagger kimliği	Özel tagger meta verisi yok	Evet
Tag mesajı	Hayır	Evet
Tag nesnesinde oluşturulma tarihi	Hayır	Evet
Tag imzası taşıyabilir	Hayır	Evet
Tipik kullanım	Geçici veya kişisel etiketler	Sürümler ve önemli kilometre taşları

Bazı Git komutları açık release tarzı tag nesnelerini temsil ettikleri için varsayılan olarak annotated tag’leri tercih eder.

Tarihsel Bir Commit’i Etiketleyin

Yalnızca geçerli commit’i etiketlemek zorunda değilsiniz.

Hedefi bulun:

git log --oneline

Daha eski bir commit üzerinde annotated tag oluşturun:

git tag -a v0.9.0 7a93c2e -m "Release candidate baseline"

Tarihsel lightweight tag oluşturun:

git tag test-baseline 7a93c2e

Etiketlemeden önce hedefi doğrulayın:

git show --no-patch --format=fuller 7a93c2e

Yanlış commit’i etiketlemek özellikle yayınlamadan sonra deployment ve release karışıklığı oluşturabilir.

Tag Referanslarını Kesin Biçimde İnceleyin

Tag adının referans verdiği nesneyi gösterin:

git rev-parse v1.0.0

Annotated tag için bu normalde tag nesnesinin kendisini tanımlar.

Tag’i nihai olarak referans verdiği commit’e peel edin:

git rev-parse v1.0.0^{}

Referans verilen nesnenin commit olmasını zorunlu kılın:

git rev-parse v1.0.0^{commit}

Referans türünü gösterin:

git cat-file -t v1.0.0

Tipik sonuçlar:

Annotated tag nesnesi için tag.
Doğrudan commit’e işaret eden lightweight tag için commit.

Bir Commit’e İşaret Eden Tag’leri Gösterin

Doğrudan HEAD’e işaret eden tag’leri listeleyin:

git tag --points-at HEAD

Başka bir revision’ı kontrol edin:

git tag --points-at 7a93c2e

Seçilen commit üzerinde release tag’inin zaten bulunup bulunmadığını doğrulamaya yardımcı olur.

Bir Commit’i İçeren Tag’leri Listeleyin

Referans verdikleri commit geçmişi seçilen commit’i içeren tag’leri gösterin:

git tag --contains <commit>

Commit’i içermeyen tag’leri gösterin:

git tag --no-contains <commit>

Şu soruları yanıtlamaya yardımcı olabilir:

Hangi sürümler güvenlik düzeltmesini içeriyor?
Bir hata release öncesinde mi sonrasında mı eklendi?
Hangi release hatları seçilen commit’i içeriyor?

Containment, aynı kodun başka yerde bağımsız olarak eklenmesine değil commit ancestry’sine dayanır.

Tag’leri Sıralayın

Lexicographic sıralama şaşırtıcı sonuçlar verebilir:

v1.10.0
v1.2.0
v1.9.0

Version-aware sıralama kullanın:

git tag --sort=version:refname

Ters sıralayın:

git tag --sort=-version:refname

Annotated tag’leri tagger tarihine göre sıralayın:

git tag --sort=-taggerdate

Lightweight tag’lerin özel tagger tarihi yoktur; bu nedenle tarihe dayalı gösterimler tag türüne göre farklı alanlar gerektirebilir.

Özel tag listesi biçimlendirin:

git for-each-ref \
  --sort=-version:refname \
  --format="%(refname:short) %(objecttype) %(subject)" \
  refs/tags

Tag Adlarında Arama Yapın

Kararlı version-one tag’lerini listeleyin:

git tag -l "v1.*"

Release candidate tag’lerini listeleyin:

git tag -l "*-rc.*"

Wildcard pattern’ları tırnak içine alın; böylece shell, Git pattern’ı almadan önce bunları dosya adlarıyla genişletmez.

Yerel Tag’i Silin

git tag -d v0.1.0

Bu komut yerel tag referansını kaldırır.

Daha önce remote depoya yayınlanmış tag’i otomatik olarak kaldırmaz.

Silmeden önce:

git show v0.1.0
git rev-parse v0.1.0^{}

Amaçlanan referansı kaldırdığınızı doğrulayın.

Yerel Tag’i Değiştirin veya Taşıyın

Tag’lerin sabit kalması beklenir; ancak özel yerel hazırlık sırasında bir tag’i düzeltmeniz gerekebilir.

Silip yeniden oluşturun:

git tag -d v1.0.0
git tag -a v1.0.0 <correct-commit> -m "Sürüm 1.0.0"

Veya yerelde zorlayarak değiştirin:

git tag -f -a v1.0.0 <correct-commit> -m "Sürüm 1.0.0"

Force replacement, adın tanımladığı nesneyi değiştirir. Tag paylaşıldıktan sonra bunu dikkatsizce yapmayın.

Yayınlanmış Tag’ler Neden Değişmez Kabul Edilmelidir?

Bir ekibin v1.0.0 tag’ini A commit’ine işaret edecek şekilde yayınladığını düşünün. Kullanıcılar, CI sistemleri, deployment araçları ve package builder’lar bu tag’i indirmiş veya cache’lemiş olabilir.

Tag daha sonra B commit’ine taşınırsa aynı release adı farklı kişiler için farklı anlamlara gelebilir:

Geliştirici 1: v1.0.0 -> A
Geliştirici 2: v1.0.0 -> B
Build cache: v1.0.0 -> A
Deployment sistemi: v1.0.0 -> B

Bu durum yeniden üretilebilirliği ve güveni zedeler.

Yayınlanmış release yanlışsa daha güvenli yaklaşım genellikle yeni bir version oluşturmaktır:

v1.0.1
v1.0.0-hotfix.1
v1.0.1-rc.1

Projenin benimsediği versioning kuralını kullanın.

Signed Tag’ler

Signing anahtarları ve Git yapılandırması hazırlandığında annotated tag kriptografik olarak imzalanabilir.

Signed tag oluşturun:

git tag -s v1.0.0 -m "Sürüm 1.0.0"

Yapılandırılmış signing formatına ve anahtar ayarlarına bağlı olarak Git, tag nesnesinde bir imza oluşturur.

Tag imzasını doğrulayın:

git tag -v v1.0.0

Veya:

git verify-tag v1.0.0

Doğrulama uygun public key veya trust yapılandırmasına erişim gerektirir.

Geçerli kriptografik imza, tag nesnesinin karşılık gelen private key sahibince imzalandığını doğrular. Yazılımın güvenli, hatasız veya organizasyonunuzca onaylanmış olduğunu otomatik olarak kanıtlamaz.

Signed Tag ve Signed Commit Farkı

Signed tag, tag nesnesini imzalar. Signed commit ise tek bir commit nesnesini imzalar.

Birbirlerinden bağımsız kullanılabilirler:

Signed release tag, unsigned commit’lere işaret edebilir.
Signed commit, unsigned tag’e sahip olabilir.
Proje ikisini de zorunlu tutabilir.
Proje hosting platformundaki release attestation’larına veya başka doğrulama sistemine dayanabilir.

Tek bir imzanın tüm artifact ve süreçleri kapsadığını varsaymak yerine projenin belirlediği release trust politikasını izleyin.

Uygulamalı Release Tag Oluşturun

Release’i etiketlemeden önce:

Doğru branch’i doğrulayın.
Working tree’nin temiz olduğundan emin olun.
Ekip politikasına göre remote durumunu fetch edin veya senkronize edin.
Testleri ve build kontrollerini çalıştırın.
Etiketlenecek commit’i inceleyin.
Version numarasını doğrulayın.
Annotated veya signed tag oluşturun.
Yayınlamadan önce tag’i inceleyin.

Örnek:

git switch main
git status
git log -1 --format=fuller
git diff HEAD^ HEAD
git tag -a v1.0.0 -m "Task Notes 1.0.0 sürümünü yayınla"
git show v1.0.0

Tag, commit edilmemiş working directory yerine test edilmiş tam bir commit’i tanımlamalıdır.

Tek Tag’i Remote’a Push Edin

Normal branch push işlemleri tüm yerel tag’leri otomatik olarak yayınlamayabilir.

Tek tag’i açıkça push edin:

git push origin v1.0.0

Bu, tam olarak amaçlanan tag’i yayınladığı için en güvenli yaygın release davranışıdır.

Tüm Yerel Tag’leri Push Edin

git push origin --tags

Bu komut remote’da bulunmayan tüm yerel tag’leri push eder.

Dikkatli kullanın. Geliştiricinin yayınlanmaması gereken geçici, kişisel, deneysel veya eski yerel tag’leri olabilir.

Çalıştırmadan önce:

git tag --list
git for-each-ref --format="%(refname:short) %(objecttype) %(subject)" refs/tags

--follow-tags ile Ulaşılabilir Annotated Tag’leri Push Edin

Branch’leri push ederken şunu kullanın:

git push --follow-tags

Bu seçenek remote’da bulunmayan ve push edilen commit’lerden ulaşılabilir annotated tag’leri push edebilir.

--tags ile tamamen aynı davranmaz ve tüm yerel lightweight tag’leri yayınlamaz.

Bu nedenle annotated tag kullanan ve ilgisiz yerel etiketleri yayınlamak istemeyen release iş akışlarında kullanışlıdır.

Remote Tag’i Silin

Açık remote ref işlemiyle silin:

git push origin --delete v1.0.0

Başka bir açık biçim:

git push origin :refs/tags/v1.0.0

Remote tag’i silmek, diğer kullanıcıların daha önce fetch ettiği kopyaları otomatik olarak silmez.

Yayınlanmış tag’in değiştirilmesi gerekiyorsa açık iletişim kurun, açık refspec’ler kullanın ve istemcilerin eski tag’i bilinçli olarak güncelleyene veya silene kadar saklayabileceğini anlayın.

Tag’leri Fetch Edin

Normal fetch işlemleri Git’in tag-following davranışına göre fetch edilen geçmişe işaret eden tag’leri çoğu zaman alır.

Tag’leri açıkça fetch edin:

git fetch --tags

Tek tag’i açık refspec ile fetch edin:

git fetch origin tag v1.0.0

Fetch sonrasında inceleyin:

git tag --list
git show v1.0.0

Bir tag’in remote üzerinde bulunması nedeniyle güvenilir olduğunu varsaymayın. Projenin güvenlik modeline göre hedefini, meta verisini ve imzasını doğrulayın.

Bir Tag’i Checkout Edin

Etiketlenmiş sürümü detached-HEAD modunda inceleyin:

git switch --detach v1.0.0

Şu işler için kullanışlıdır:

Eski bir release’i build etmek.
Tarihsel testleri çalıştırmak.
Production sürümünü incelemek.
Sürümler arasındaki davranışı karşılaştırmak.

Çalışmayı korumayı planlamıyorsanız detached modda devam eden geliştirme yapmayın.

Tag’den maintenance branch oluşturun:

git switch -c support/1.0 v1.0.0

Artık yeni commit’ler maintenance branch’i hareket ettirirken tag sabit kalır.

Release’leri Karşılaştırın

Sürümler arasında eklenen commit’leri listeleyin:

git log --oneline v1.0.0..v1.1.0

İçeriği karşılaştırın:

git diff v1.0.0 v1.1.0

Özet istatistikleri gösterin:

git diff --stat v1.0.0 v1.1.0

Değişen path’leri gösterin:

git diff --name-status v1.0.0 v1.1.0

Bu komutlar release note’ları, regression araştırması ve deployment incelemesi için kullanışlıdır.

Commit’i Tag’lere Göre Tanımlayın

git describe, yakındaki ulaşılabilir tag’e dayalı okunabilir bir ad oluşturur:

git describe

Örnek:

v1.0.0-5-g7a93c2e

Bu genellikle şu anlama gelir:

Dikkate alınan en yakın tag v1.0.0.
Commit bu tag’den beş commit sonra.
Kısaltılmış nesne kimliği 7a93c2e ile başlıyor.

Lightweight tag’leri dahil edin:

git describe --tags

Uygun tag bulunamadığında bile fallback nesne kimliği gösterin:

git describe --tags --always

Development build kimlikleri için kullanışlı olabilir.

Tag Adlandırma Kuralları

Yaygın release adları:

v1.0.0
v1.2.3
v2.0.0-rc.1
release-2026.07
production-2026-07-10

Yararlı bir kural şunları sağlamalıdır:

Tutarlılık.
Dokümante edilmiş olması.
Release araçlarınca sıralanabilir veya parse edilebilir olması.
Package ve deployment sistemleriyle uyumluluk.
Yayınlandıktan sonra kararlılık.

Açık bir neden olmadan ilgisiz birden fazla şemayı karıştırmayın.

Semantic Versioning’e Genel Bakış

Birçok proje şu version yapısını kullanır:

MAJOR.MINOR.PATCH

Örneğin:

2.4.1

Tipik yorum:

MAJOR: Geriye uyumsuz public değişiklikler.
MINOR: Geriye uyumlu yeni işlevler.
PATCH: Geriye uyumlu düzeltmeler.

Prerelease tanımlayıcıları candidate sürümleri temsil edebilir:

2.5.0-alpha.1
2.5.0-beta.1
2.5.0-rc.1

Git Semantic Versioning’i zorunlu kılmaz. Tag adı yalnızca bir referans adıdır. Version’ın anlamı proje ve release politikası tarafından tanımlanmalıdır.

Tag Nesneleri Commit Dışındaki Nesnelere de İşaret Edebilir

Release tag’leri normalde commit’e işaret etse de Git tag referansı başka türde bir nesneyi tanımlayabilir.

Annotated tag nesneleri commit, tree, blob veya başka tag nesnelerine işaret edebilir.

Çoğu geliştirici iş akışı commit’leri etiketlemelidir; çünkü commit tam proje anlık görüntüsünü ve geçmiş bağlamını tanımlar.

Release Tag’leri ve Hosting Platformu Release’leri

Git tag’i ile hosting platformu release’i ilişkili ancak aynı şey değildir.

Git tag’i depo referansıdır. Platform release’i şu ekleri sağlayabilir:

Release note’ları.
İndirilebilir arşivler.
Derlenmiş binary dosyalar.
Asset’ler.
Onay iş akışları.
Deployment entegrasyonu.
Provenance veya attestation bilgileri.

Release arayüzü genellikle Git tag’ini kaynak version olarak kullanır; ancak çevresindeki meta veriler hosting platformuna aittir.

Uygulamalı İş Akışı: Acil Düzeltme İçin Özelliği Duraklatmak

1. Tamamlanmamış Çalışmayı İnceleyin

git status
git diff
git diff --staged

2. Untracked Dosyalarla Birlikte Stash’e Alın

git stash push -u -m "WIP: görev arama filtrelemesi"

3. Temiz Durumu Doğrulayın

git status
git stash list

4. Düzeltme Branch’ine Geçin

git switch main
git switch -c hotfix/task-import

5. Düzeltmeyi Uygulayın ve Commit Edin

git add -p
git commit -m "Hatalı içe aktarılan görev tarihlerini reddet"

6. Özelliğe Geri Dönün

git switch feature/search

7. Stash’i İnceleyin ve Uygulayın

git stash show -p stash@{0}
git stash apply stash@{0}

8. Drop Etmeden Önce Doğrulayın

git status
# Testleri çalıştırın ve dosyaları inceleyin
git stash drop stash@{0}

apply kullanıp sonrasında bilinçli drop işlemi yapmak bir doğrulama adımı sağlar.

Uygulamalı İş Akışı: Eski Stash’i Branch’e Dönüştürmek

Stash’i inceleyin:

git stash list
git stash show -p stash@{2}

İlk base’inden branch oluşturun:

git stash branch feature/recovered-search stash@{2}

Ardından:

git status
git diff
git diff --staged

Kurtarılan değişiklikleri anlamlı commit’ler halinde düzenleyin.

Uygulamalı İş Akışı: Release Tag Oluşturup Yayınlamak

1. Release Commit’ini Doğrulayın

git switch main
git status
git log -1 --format=fuller
git show --stat HEAD

2. Release Kontrollerini Çalıştırın

# Yalnızca örnekler; projenin gerçek komutlarını kullanın
php vendor/bin/phpunit
npm run build

3. Annotated Tag Oluşturun

git tag -a v1.0.0 -m "Task Notes 1.0.0 sürümünü yayınla"

4. Tag’i İnceleyin

git show v1.0.0
git rev-parse v1.0.0^{commit}

5. Yalnızca Amaçlanan Tag’i Yayınlayın

git push origin v1.0.0

6. Remote Release Otomasyonunu Doğrulayın

CI, package oluşturma, deployment ve release-note iş akışlarının başarıyla tamamlandığını doğrulayın.

Yaygın Stash Hataları

Untracked Dosyaların Otomatik Dahil Edildiğini Sanmak

Untracked dosyalar stash’e dahil olacaksa -u kullanın.

Ignored İçeriği İncelemeden --all Kullanmak

Ignored dependency ve build dizinleri stash’i beklenmedik ölçüde büyütebilir.

Eski Stash’i İncelemeden Pop Kullanmak

Önce stash show kullanın ve apply seçeneğini değerlendirin.

Önemli Çalışmayı Aylarca Stash’te Tutmak

Önemli çalışmayı commit içeren bir branch’e dönüştürün.

Yanlış Stash Numarasını Drop Etmek

Silme sonrasında stash konumları değişebilir. Drop işleminden hemen önce git stash list çalıştırın.

--index Seçeneğinin Her Zaman Kusursuz Geri Yüklemesini Beklemek

Mevcut depo durumu eski index düzeninin temiz biçimde uygulanmasını engelleyebilir.

Stash’in Remote ile Paylaşıldığını Sanmak

Stash girişleri normalde yereldir ve sıradan branch push işlemleriyle yayınlanmaz.

Düzensiz Working Tree’yi Gizlemek İçin Stash Kullanmak

Mesajsız ve temizlenmeyen tekrar eden stash kullanımı anlaşılması zor ikinci bir backlog oluşturur.

Yaygın Tag Hataları

Tag ile Branch’i Karıştırmak

Tag normalde sabit kalır; branch geliştirmeyle birlikte hareket eder.

Yanlış Commit’i Etiketlemek

Release tag’i oluşturmadan önce commit’i ve test sonucunu inceleyin.

Resmî Release İçin Bilinçsizce Lightweight Tag Kullanmak

Annotated tag’ler release’e özel meta verileri ve mesajları korur.

Tüm Tag’leri Körlemesine Push Etmek

git push --tags kişisel veya deneysel yerel tag’leri yayınlayabilir.

Yayınlanmış Version Tag’ini Taşımak

Farklı kullanıcılar ve build sistemleri aynı ad için farklı hedefleri saklayabilir.

Signed Tag’in Yazılım Güvenliğini Kanıtladığını Sanmak

İmza, yazılımın doğruluğunu değil tag nesnesini ve anahtar ilişkisini doğrular.

Remote Tag’i Silince Her Yerden Kaybolacağını Sanmak

Diğer clone’lar eski yerel tag’i bilinçli olarak silene veya değiştirene kadar saklayabilir.

Temiz Olmayan Working Tree’den Release Oluşturmak

Tag commit edilmiş bir nesneyi tanımlar. Commit edilmemiş yerel dosyalar release referansına dahil edilmez.

Stash Komutları Referansı

Komut	Amacı
`git stash push -m "message"`	Tracked working tree ve index değişikliklerini mesajla stash’e almak
`git stash push -u`	Untracked dosyaları dahil etmek
`git stash push -a`	Untracked ve ignored dosyaları dahil etmek
`git stash push --keep-index`	Staged değişiklikleri index içinde tutmak
`git stash push --staged`	Staged değişiklikleri stash’e almak
`git stash push -p`	Hunk’ları etkileşimli biçimde seçmek
`git stash push -- path`	Seçilen path’leri stash’e almak
`git stash list`	Stash girişlerini listelemek
`git stash show -p`	En son stash patch’ini incelemek
`git stash apply`	Değişiklikleri geri yükleyip stash’i korumak
`git stash apply --index`	Değişiklikleri ve staged durumu geri yüklemeyi denemek
`git stash pop`	Değişiklikleri geri yükleyip başarıdan sonra drop etmek
`git stash branch name stash@{n}`	Stash’in ilk base’inden branch oluşturup stash’i uygulamak
`git stash drop stash@{n}`	Tek bir stash girişini kaldırmak
`git stash clear`	Tüm stash girişlerini kaldırmak

Tag Komutları Referansı

Komut	Amacı
`git tag`	Yerel tag’leri listelemek
`git tag v1.0.0`	Lightweight tag oluşturmak
`git tag -a v1.0.0 -m "message"`	Annotated tag oluşturmak
`git tag -s v1.0.0 -m "message"`	Signed annotated tag oluşturmak
`git tag -a v1.0.0 commit`	Seçilen tarihsel commit’i etiketlemek
`git show v1.0.0`	Tag’i ve referans verilen nesneyi incelemek
`git tag --points-at HEAD`	Revision’a işaret eden tag’leri listelemek
`git tag --contains commit`	Geçmişleri commit’i içeren tag’leri listelemek
`git tag --sort=version:refname`	Adları version-aware sıralamayla sıralamak
`git tag -d v1.0.0`	Yerel tag’i silmek
`git tag -v v1.0.0`	Signed tag’i doğrulamak
`git push origin v1.0.0`	Tek tag’i yayınlamak
`git push origin --tags`	Tüm yerel tag’leri yayınlamak
`git push --follow-tags`	Branch güncellemeleriyle uygun ulaşılabilir annotated tag’leri push etmek
`git push origin --delete v1.0.0`	Remote’daki tag’i silmek
`git switch --detach v1.0.0`	Etiketlenmiş sürümü incelemek
`git switch -c support/1.0 v1.0.0`	Tag’den branch oluşturmak

Stash Kontrol Listesi

Stash oluşturmadan önce:

git status çalıştırın.
Untracked veya ignored dosyaların gerekli olup olmadığına karar verin.
Staged ve unstaged değişiklikleri inceleyin.
Açıklayıcı mesaj kullanın.
Branch ve commit’in daha güvenli olup olmayacağını değerlendirin.

Stash’i uygulamadan veya drop etmeden önce:

git stash list çalıştırın.
Seçilen patch’i inceleyin.
Geçerli branch’i ve working tree’yi kontrol edin.
Doğrulama gerekiyorsa apply tercih edin.
Geri yüklemeden sonra testleri çalıştırın.
Çalışmanın başka yerde korunduğunu doğruladıktan sonra drop edin.

Release Tag Kontrol Listesi

Amaçlanan release commit’i kontrol edilmiş ve test edilmiştir.
Working tree temizdir.
Version adı proje kurallarına uygundur.
Tag türü release politikasına uygundur.
Annotation release’i açıklar.
Tag doğru commit’e işaret eder.
Gerekli signing ve doğrulama adımları tamamlanmıştır.
Yalnızca amaçlanan tag yayınlanır.
Release artifact’leri etiketlenmiş commit’ten oluşturulur.
Yayınlanan tag dikkatsizce taşınmaz.

Sık Sorulan Sorular

Git Stash Untracked Dosyaları Kaydeder mi?

Varsayılan olarak hayır. Untracked dosyaları dahil etmek için git stash push -u kullanın.

-u Ignored Dosyaları Dahil Eder mi?

Hayır. Ignored dosyaların da dahil edilmesi gerektiğinde -a veya --all kullanın.

Apply ve Pop Arasındaki Fark Nedir?

İkisi de stash değişikliklerini geri yükler. apply stash girişini korur; pop başarılı uygulamadan sonra kaldırır.

Stash’i Başka Branch’e Uygulayabilir miyim?

Evet; ancak hedef branch stash’in ilk base’inden önemli ölçüde farklıysa conflict olasılığı artar.

Stash’i Paylaşabilir miyim?

Normal stash girişleri yereldir. İş birliği için branch oluşturup çalışmayı commit edin veya bilinçli gelişmiş transfer iş akışı kullanın.

Stash Uzun Vadeli Çalışma İçin Güvenli mi?

Temel olarak geçici yerel çalışma için tasarlanmıştır. Önemli uzun vadeli değişiklikler branch, commit ve remote kopyalarıyla korunmalıdır.

Lightweight ve Annotated Tag Arasındaki Fark Nedir?

Lightweight tag doğrudan referanstır. Annotated tag ise tagger meta verisi, tarih, mesaj ve isteğe bağlı imza içeren tag nesnesi oluşturur.

Release’lerde Annotated Tag Kullanılmalı mı?

Annotated veya signed tag’ler açık release meta verisi sakladıkları için resmî sürümlere genellikle daha uygundur.

git push Tag’leri Otomatik Yayınlar mı?

Normal branch push işlemi her yerel tag’i zorunlu olarak yayınlamaz. Amaçlanan tag’i açıkça yayınlayın veya dikkatle seçilmiş tag-push seçeneği kullanın.

Tag’i Değiştirebilir miyim?

Yerel tag değiştirilebilir; ancak yayınlanmış tag’i değiştirmek clone’lar ve sistemler arasında tutarsız release kimlikleri oluşturabilir.

Tag Bir Branch’e İşaret Edebilir mi?

Tag, branch’in gelecekteki hareketine değil bir nesneye çözülür. Branch adı kullanılarak tag oluşturulduğunda branch’in o anda referans verdiği nesne etiketlenir.

Tag Checkout Edilmişken Commit Oluşturabilir miyim?

Detached-HEAD modunda commit oluşturabilirsiniz; ancak hiçbir branch otomatik ilerlemez. Çalışmanın açık biçimde korunması gerekiyorsa önce branch oluşturun.

Signed Tag Release Binary’sinin İmzalandığı Anlamına mı Gelir?

Hayır. Git tag nesnesini imzalar. Release binary’leri, container’lar, package’lar ve attestation’lar ayrı signing ve doğrulama gerektirebilir.

Sonuç

Git stash ve tag’ler geliştirme iş akışının iki farklı ucunda çalışır.

Stash tamamlanmamış yerel çalışmayı yönetir. Working tree’yi geçici olarak temizlemenizi, seçilen tracked veya untracked değişiklikleri korumanızı, çalışmayı başka branch’e taşımanızı ve daha sonra geri dönmenizi sağlar. Bu güç sorumluluk getirir: neyin saklandığını inceleyin, açıklayıcı mesajlar kullanın, dikkatli geri yükleyin ve önemli uzun ömürlü çalışmayı normal commit’lere dönüştürün.

Tag’ler kararlı tarihsel noktaları tanımlar. Lightweight tag’ler basit etiketler sunarken annotated ve signed tag’ler daha güçlü release meta verisi taşır. İyi yönetilen tag test edilmiş bir commit’e işaret eder, tutarlı versioning kuralını izler ve yayınlandıktan sonra sabit kalır.

En önemli fark dayanıklılık ve amaçtır. Stash geçici ve kişisel bir çalışma kapsayıcısıdır. Release tag’i ise belirli bir adın belirli bir proje durumunu tanımladığına dair paylaşılan bir sözdür.

Bir sonraki makale Git iş akışlarını inceleyecektir: feature branch’ler, GitHub Flow, Git Flow, trunk-based development, release branch’leri, hotfix stratejileri ve ekip boyutuna ve teslimat modeline uygun iş akışının nasıl seçileceği.

Resmî Kaynaklar ve Ek Okumalar