Git'te bir dalı silmek geçmişten kaldırıyor mu?

Svn'den geliyor, git'e aşina olmaya başlıyor.

Git'te bir şube silindiğinde, geçmişten kaldırılır mı?

Svn'de silme işlemini (ters birleştirme) geri alarak bir dalı kolayca kurtarabilirsiniz. Svn'deki tüm silmeler gibi, şube hiçbir zaman gerçekten silinmez, sadece mevcut ağaçtan kaldırılır.

Şube git'teki geçmişten gerçekten silinirse, o şubeden birleştirilen değişikliklere ne olur? Onlar korunuyor mu?

Şubeler git'te taahhüt için sadece işaretçilerdir. Git'te her komut tam bir kaynak ağacına sahiptir, tüm dalların ve etiketlerin (konvansiyonla) özel 'gövde' ile birlikte havuzun ayrı 'klasörlerinde' yaşadığı svn'den çok farklı bir yapıdır.

Şube silinmeden önce başka bir şubeye birleştirildiyse, ilk şube silindiğinde tüm taahhütlere diğer şubeden erişilebilecektir. Tam olarak oldukları gibi kalırlar.

Şube başka bir şubeye birleştirilmeden silinirse, o şubedeki taahhütler (hala ulaşılabilir bir taahhütten çatallıya kadar olan noktaya kadar) görünür olmayacaktır.

Taahhütler yine de depoda tutulur ve silindikten hemen sonra bunları kurtarmak mümkündür, ancak sonunda çöp toplanır.

Git'te dallar, taahhütlerin bir asiklik grafiğinde (DAG) taahhütlere sadece işaretçilerdir (referanslar). Bu, bir şubeyi silmenin yalnızca taahhütlere yapılan referansları kaldırdığı anlamına gelir, bu da DAG'daki bazı taahhütlere ulaşılamaz, dolayısıyla görünmez olabilir. Ancak, silinen bir dalda bulunan tüm taahhütler, en azından ulaşılamayan taahhütler budanana kadar (örn. Kullanarak git gc) depoda olacaktır .

git branch -dBir şubeyi silmenin erişilemez taahhütler bırakmayacağından emin olamazsa, bir şubeyi silmeyi reddedeceğini unutmayın . git branch -DUlaşılamayan taahhütler bırakabiliyorsa, bir dalın silinmesini zorlamak için daha güçlü kullanmanız gerekir .

Ulaşılamaz taahhütlerin, eğer mevcutsa, sadece silinmiş bir dalın son ucu ile mevcut başka bir dalla birleştirilen bir taahhüt, herhangi bir etiketlenmiş taahhüt veya dallanma noktası arasındaki taahhütler olduğuna dikkat edin; hangisi daha sonra. Örneğin aşağıdaki durumda:

---- O ---- * ---- * ---- / M ---- * <- master <- KAFA
     \ /
      \ --. ---- .-- / - x --- y <- silinen şube

yalnızca 'x' ve 'y' işlemlerine şube silindikten sonra erişilemez hale gelir.

Silinen bir dalda gc.reflogExpire, varsayılan 90 gün içinde ameliyat olsaydınız, silinen bir dalın son ucunu HEAD reflog'a kaydedersiniz (bkz . git reflog show HEADVeya git log --oneline --walk-reflogs HEAD). Silinmiş işaretçiyi kurtarmak için HEAD reflog'u kullanabilmeniz gerekir. Ayrıca, bu durumda, yalnızca silinen bir daldaki erişilemez taahhütlerin, gc.reflogExpireUnreachablevarsayılan olarak 30 gün olan bu süre içinde budama (kaldırma) işleminden korunacağını unutmayın.

HEAD için reflog'da yeni silinen bir dalın ucunu git fsckbulamazsanız, "erişilemeyen <sha1>" değerini bulmak için kullanmayı deneyebilir ve silinen dalın ucunu bulmak için ( git show <sha1>veya aracılığıyla git log <sha1>) inceleyebilirsiniz .

Silinmiş bir dalın ucunu nasıl bulduğunuzdan bağımsız olarak, silme işlemini geri alabilir veya daha önce silinen bir dalı yeniden oluşturabilirsiniz.

git branch <deleted-branch> <found-sha1-id>

Bununla birlikte, bir şube için yeniden yapılanmanın kaybedileceğini unutmayın.

Ayrıca, verilen bir adla bir şube ipucununcontrib/ izlerini bulmaya ve yeniden diriltmeye ( silmeyi geri almaya) yardımcı olan git-resurrect.sh komut dosyası da vardır .

Yanlışlıkla silinen şubelerden endişe duyuyorsanız ve artık deponuzun yerel bir kopyasına sahip değilseniz, Gerrit gibi kurumsal Git sunucularına geçmiş yeniden yazmalarını ve şube silme işlemlerini algılayacak, özel bir ref altında yedekleyecekleri uzantılar var. gerekirse geri yüklenebilir ve çöp toplama ile budanmayacaktır. Gerrit yöneticileri, yasal nedenlerden dolayı gerekirse seçilen taahhütleri kaldırabilir.