Git 2.56, git add --resolved ile alakasız düzenlemeleri merge commit'lerin dışında tutuyor

Git 2.56, versiyon kontrolünün en yaygın küçük kazalarından birine çözüm getiriyor: çakışmaları çözerken alakasız working tree değişikliklerini bir merge commit'e dahil etmek. Bir dev.to anlatımına göre, günlük işler için öne çıkan yenilik git add --resolved; yalnızca gerçekten çakışma yaşamış dosyalara dokunan ve başka hiçbir şeye dokunmayan bir staging komutu.

Aşırı stage'leme tuzağı

Süreç şöyle işler: çakışmaları çözersiniz, sonra sonuçları stage'lersiniz. Çoğu insan alışkanlıkla git add -u veya git add . yazar ve her iki komut da depodaki değiştirilmiş tüm izlenen dosyaları stage'ler. Working tree'de bekleyen herhangi bir artık düzenleme — bir debug print'i, başka bir şeyi araştırırken eklenmiş bir set -x satırı — merge commit ile birlikte yolculuğuna devam eder.

dev.to yazarı tam olarak bunun kurbanı olduğunu anlatıyor: bir debug satırı sessizce bir merge commit'e karışmış, merge commit'ler normal commit'lere kıyasla çok daha az incelediği için fark edilmemiş ve haftalar sonra biri başlangıç scriptinin neden her komutu ekrana yazdırdığını sorduğunda ortaya çıkmış. Dikkatli alternatif, çakışan her yolu elle yazmaktı; ama o bile conflict marker'ların gerçekten kaldırılıp kaldırılmadığını doğrulamıyordu.

Yeni flag ne yapıyor

dev.to yazısına göre git add --resolved şöyle davranıyor:

• Yalnızca unmerged yollara bakar — git status çıktısında görünen UU, AA ve UD girdilerine.
• Bu dosyaların her birini kalan conflict marker'lar açısından kontrol eder.
• Herhangi bir dosyada hâlâ marker varsa hiçbir şeyi stage'lemez ve daha fazla iş gerektiren dosyaları listeler.
• Aksi halde hepsini stage'ler; çakışma içinde olmayan izlenen dosyalara ise asla dokunmaz.

Komut kapsamını daraltmak için bir pathspec de kabul ediyor, örneğin git add --resolved config.ini, ve -u veya -A ile birlikte kullanılamıyor.

Yazar, iki dalın bir config dosyasında bitişik satırları düzenlediği, iki dosyada çakışma oluşurken bir başlangıç scriptindeki alakasız yerel değişikliğin stage'lenmemiş halde durduğu bir demo depoyu adım adım anlatıyor. Egzersizin amacı, bu iki grubu merge bitene kadar ayrı tutmak — yeni flag bunu otomatik olarak yapıyor.

2.56'daki diğer değişiklikler

dev.to makalesi 2.56'yı kapsamlı bir sürüm olarak nitelendiriyor ve birkaç yaşam kalitesi iyileştirmesi daha listeliyor:

• git branch --delete-merged, işi izlenen upstream'a ulaşmış yerel dalları siler; çıkış yapılmış dalı, merge edilmemiş dalları ve tutulacak şekilde işaretlenmişleri koruyan güvenlik kurallarıyla birlikte.
• git bisect --reset-when-found, bozuk commit tespit edildiğinde bisect oturumunu kendi kendine sonlandırır.
• git history drop, geçmişin ortasındaki bir commit'i kaldırır; bağımlı dallar da peşinden gider.
• Yeni git refs ailesi (create, update, delete, rename), sessiz üzerine yazma olmadan ve compare-and-swap güncellemesiyle daha güvenli ref manipülasyonu sağlar.
• git replay --linearize, merge ağırlıklı bir dalı bellekte düzleştirir; bare depolarda bile çalışır.
• git log --graph artık alakasız geçmişleri bağlı görünümünde çizmiyor.
• [includeIf "worktree:..."], koşullu dizin bazlı yapılandırmayı bağlı worktree'lere genişletiyor.
• fetch.followRemoteHEAD, tek bir ayarla origin/HEAD'i remote ile senkron tutuyor.
• git repack --drop-filtered, partial clone'larda disk alanı geri kazandırıyor.

Daha küçük dokunuşlar arasında push hedefleri için yazım ipuçları var — git push origin/main artık git push origin main öneriyor — ve -h çoğu komutta artık 129 yerine 0 çıkış koduyla sonlanıyor, böylece scriptli bir yardım kontrolü artık başarısızlık olarak görünmüyor.

Yeni sürümü edinmek

Linux dağıtımları yeni Git sürümlerini paketlemek için zaman alıyor; yazar Fedora'nın hâlâ 2.55 sunduğunu bildiriyor. Kaynaktan derlemek yerine, mise'in conda backend'iyle (henüz deneysel olarak işaretli) önceden derlenmiş Git 2.56.0 kurmuşlar. Bir mise.toml dosyası üzerinden yapılandırılan yeni Git yalnızca o proje içinde geçerli oluyor ve sistem kurulumuna dokunmuyor.

Neden önemli

Merge çakışmaları rutindir ve onları çözdükten hemen sonra geçen an, tam da aceleyin "her şeyi stage'lemek istediğinizi" varsayan komutlarla buluştuğu andır. git add --resolved, daha önce kişisel disipline bağlı olan — ve çoğu zaman hiç gerçekleşmeyen — bir güvenlik kontrolünü aracın kendisine taşıyor. Kalan marker kontrolü tartışmasız daha büyük kazanç: elle staging, bir çözümün tamamlandığını asla doğrulamıyordu. Sürümün geri kalan artımlı düzeltmeleriyle birleşince, sıradan bir Git iş akışının sessizce ters gitme yollarını azaltıyor — ve her gün karşılığını veren tam da bu tür show-off olmayan iyileştirmeler.