Git detached head durumu nedir, nasıl çözülür?

Kısa yanıt

Git’te detached head durumu, deponuzdaki HEAD işaretçisinin bir dal adına değil doğrudan belirli bir commit’e bağlı olduğu, bir hata sayılmayan bir durumdur. Genellikle git checkout <commit-hash> veya git checkout <etiket> gibi bir komutla belirli bir noktaya geçtiğinizde ortaya çıkar ve terminalde “You are in ’detached HEAD’ state” uyarısıyla kendini gösterir.

Üzerinde durduğunuz değişiklik önemsizse çıkmak tek bir komuttan ibarettir: git switch <dal-adı>. Commit attıysanız ve o işi kaybetmek istemiyorsanız, önce bulunduğunuz noktadan git switch -c yeni-dal komutuyla yeni bir dal açmanız gerekir; aksi halde o commit’lere giden tek yol kapanır.

Detached head durumu nedir?

Normal çalışma akışında HEAD, o an üzerinde çalıştığınız dalı gösteren bir işaretçidir. Yeni bir commit attığınızda, bulunduğunuz dal otomatik olarak o commit’e ilerler; HEAD ile dal adı her zaman birlikte hareket eder. git checkout ile doğrudan bir commit hash’ine, bir sürüm etiketine veya takip edilmeyen bir uzak referansa geçtiğinizde Git bu hareketi farklı değerlendirir: artık bir dal üzerinde değil, tek bir commit üzerinde durduğunuzu kaydeder.

Terminaldeki uyarı tam olarak bunu anlatır. HEAD artık herhangi bir dal adına bağlı değildir, doğrudan o commit’e işaret eder. Git’in kendi resmi belgelerine göre bu durum “HEAD’in adlandırılmış bir dala değil, belirli bir commit’e işaret etmesi” olarak tanımlanır; yani Git’in gözünde eksik ya da bozuk bir şey yoktur, sadece referans biçimi değişmiştir.

Asıl risk, orada yapılan yeni commit’lerin hiçbir dal tarafından takip edilmemesidir. Dal değiştirdiğiniz anda o commit’lere giden tek referans da yok olur; dosyalar depodan hemen silinmez, ama bir dal açılmadığı sürece Git’in çöp toplayıcısı tarafından temizlenmeye açık hale gelirler.

Bu duruma en sık hangi işlemler yol açar?

Detached head durumuna girmenin arkasında genellikle dört alışılmış senaryo vardır:

• Belirli bir commit’i incelemek için git checkout <commit-hash> çalıştırmak.
• Bir sürüm etiketine geçmek için git checkout v2.3.0 gibi bir komut kullanmak.
• git bisect ile hatalı bir commit’i aramak.
• Bir pull request’in uzak dalını yerel karşılığı olmadan doğrudan incelemek.

Dördü de kasıtlı ya da kasıtsız aynı sonucu üretir: Git, çalıştığınız yeri bir dal değil, tek bir nokta olarak işaretler. Bu komutlardan hiçbiri yanlış değildir; sorun, sonraki adımın ne olduğunu bilmeden devam etmekten doğar.

Detached head durumundan nasıl çıkılır?

Doğru çıkış yolu, o noktada yapılan işin saklanmaya değip değmediğine ve üzerinde ne kadar süredir çalıştığınıza bağlıdır.

Yaptığınız değişiklik önemsizse

Üzerinde durduğunuz noktada saklanması gereken bir değişiklik yoksa, herhangi bir dala geri dönmek yeterlidir:

git switch ana-dal

Eski bir Git sürümü kullanıyorsanız veya switch komutunu henüz tanımıyorsanız, aynı işi git checkout ana-dal da görür.

Yaptığınız işi korumak istiyorsanız

Detached head durumundayken commit attıysanız ve bu işi kaybetmek istemiyorsanız, bulunduğunuz noktadan yeni bir dal açın:

git switch -c yeni-dal-adi

Bu komut, o ana kadar atılan tüm commit’leri yeni dala taşır. Artık bir dal adı tarafından takip edildikleri için güvenli hale gelirler; dalı normal şekilde push edip bir pull request açabilirsiniz.

Commit’leri zaten kaybettiyseniz

Dal değiştirdikten sonra fark ettiyseniz bile kurtarmak genellikle mümkündür. git reflog komutu HEAD’in son hareketlerinin bir günlüğünü tutar ve kaybolan commit’in hash’ini çoğunlukla orada bulabilirsiniz. O hash üzerinden git switch -c kurtarma-dali <hash> komutuyla yeni bir dal açarak işi geri getirebilirsiniz.

CI/CD ortamlarında detached head neden normal kabul edilir?

GitHub Actions gibi otomasyon sistemleri bir iş akışı çalıştığında depoyu genellikle belirli bir commit’e göre checkout eder, bir dala göre değil; bu da pipeline’ı doğrudan detached head durumunda başlatır. Burada bir sorun yoktur, çünkü otomasyon ortamı o commit’ten yeni bir dal açmaya ya da oraya manuel commit atmaya ihtiyaç duymaz; sadece kodu derler, testleri çalıştırır veya dağıtımı yapar. Bir runner’ın kapanması işi kaybettirmez, çünkü zaten kalıcı bir çalışma yapılmamıştır.

Yerel makinenizde aynı durumla karşılaşmanız farklıdır. Orada siz bir geliştiricisiniz ve elinizdeki değişiklik kalıcı olmalı; bu yüzden CI’daki davranışı örnek alıp detached head’i “zararsız” sayıp uzun süre orada çalışmak doğru bir karşılaştırma olmaz.

Hangi durumlarda dikkatli olunmalı?

Riskli olan senaryo, bir geliştiricinin detached head durumundayken günlerce fark etmeden çalışmaya devam etmesidir. Bu süre boyunca atılan commit’ler hiçbir dal tarafından korunmaz; terminal kapatılır, dal değiştirilir veya bilgisayar yeniden başlatılırsa iş kaybolma riskiyle karşı karşıya kalır.

Pratik kural basittir: bir commit’e sadece bakmak veya tek seferlik bir test çalıştırmak için gidiyorsanız sorun yoktur, ama birkaç dakikadan uzun sürecek ve saklanması gereken bir değişiklik yazacaksanız önce git switch -c ile bir dal açmak gerekir. Bu küçük alışkanlık, dal açmayı unutup saatlerce yapılan işin kaybolmasına yol açan en sık nedeni baştan ortadan kaldırır.

Editörler detached head durumunu nasıl gösterir?

Çoğu modern editör bu durumu terminal uyarısından önce fark etmenizi sağlar. VS Code’un sol alt köşesindeki dal göstergesi, normal bir dal adı yerine kısaltılmış bir commit hash’i gösteriyorsa detached head durumundasınızdır; JetBrains ürünlerinde de araç çubuğundaki dal etiketi aynı şekilde değişir ve çoğu zaman renkli bir uyarıyla desteklenir. GitHub Desktop gibi görsel arayüzler ise genellikle ayrı bir uyarı rozetiyle, hangi commit üzerinde durduğunuzu da belirterek durumu açıkça gösterir.

Bu görsel ipuçlarına güvenmek, özellikle birden fazla depo arasında geçiş yaparken terminal çıktısını satır satır okumaktan daha hızlı bir kontrol yöntemidir. Yine de editör göstergesi her zaman görünür olmayabilir; şüphe duyduğunuz anda git status çalıştırmak, hangi araçla çalıştığınızdan bağımsız olarak en güvenilir doğrulama yoludur.

Sık yapılan hatalar

Terminaldeki uyarıyı okumadan commit atmaya devam etmek, en yaygın hatadır; geliştirici çoğu zaman işini bitirdikten günler sonra commit’lerin hiçbir dalda görünmediğini fark eder. git branch komutuyla hangi dalda olduğunuzu kontrol etmeden işe başlamak da benzer bir gözden kaçırmaya yol açar; çıktıda dal adının yanında yıldız yoksa ve * (HEAD detached at ...) satırı görünüyorsa durum zaten açıktır.

Bir diğer sık karşılaşılan durum, git checkout -- ile dosya geri almayı dal değiştirmeyle karıştırmaktır; git checkout komutunun birden çok işi aynı anda yapması, hangi işlemin gerçekleştiğini anlamayı zorlaştırır. Detached head’den çıkarken dala geçmeden önce git stash ile kaydedilmemiş değişiklikleri saklamayı unutmak da çalışmanın sessizce üzerine yazılmasına neden olabilir.

Kontrol listesi

Detached head durumuyla karşılaştığınızda şu sırayla hareket etmek güvenli bir sonuç verir:

• git status komutuyla gerçekten detached head durumunda olup olmadığınızı doğrulayın.
• Elinizdeki değişikliğin saklanması gerekip gerekmediğine karar verin.
• Değer taşıyan her commit için git switch -c yeni-dal ile bir dal açın.
• Kaydedilmemiş değişiklikler varsa dal değiştirmeden önce git stash ile geçici olarak saklayın.
• Bir commit’in kaybolduğundan şüpheleniyorsanız git reflog ile geriye dönük arama yapın.

Sonraki adım

Detached head durumu, Git’in günlük kullanımında karşılaşılması kaçınılmaz, ancak doğru sırayla ele alındığında birkaç dakikada çözülen bir durumdur. Asıl önemli olan, terminaldeki uyarıyı görmezden gelmemek ve değerli bir iş yapacaksanız önce bir dal açmaktır. Benzer bir karar anı git merge sırasında da ortaya çıkar; iki durumu birlikte değerlendirmek isterseniz git merge conflict nasıl çözülür rehberimize bakabilirsiniz.

Komut satırı alışkanlıklarınızı güçlendirmek isterseniz SSH ve Linux komutları rehberimiz de işinize yarayacaktır. Ekibinizin sürüm kontrol akışını, dal stratejisini ve dağıtım sürecini baştan tasarlamak için özel yazılım geliştirme hizmetimize göz atabilir ya da doğrudan bizimle iletişime geçebilirsiniz. Grup şirketimiz Web Tasarım Ofisi, web projelerinde sürüm kontrol altyapısı ve operasyonel bakım konularında destek sağlıyor.

İlgili rehberler

• Özel yazılım geliştirme
• Git merge conflict nasıl çözülür