Git’te Son Commit’i Geri Alma: Bir Değişikliği Güvenle Nasıl Geri Alırsınız

Yazılım geliştirmede hatalar kaçınılmazdır; ancak özellikle ekip çalışmasında, onları nasıl ele aldığınız çok önemlidir.

Paylaşılan bir depoda Git ile çalışırken, yalnızca kötü bir commit’i geri almak istemezsiniz; bunu güvenli biçimde yapmak istersiniz. Bu yüzden kendi deneyimlerime dayanarak git revert hakkında bir yazı kaleme aldım.

git reset gibi geçmişi silmek yerine, git revert önceki bir commit’te yapılan değişiklikleri geri alan yeni bir commit oluşturur. Bu yaklaşım commit geçmişinizi korur.

Bu kavramlara yeniyseniz, Git Fundamentals beceri yolumuzu alarak depolar ve sürüm kontrolü hakkında her şeyi öğrenin.

Git Revert Nedir ve Nasıl Çalışır?

git revert’i Git’in “Bunu güvenle geri alalım.” deme biçimi olarak düşünün. Bir commit’te bir şey gözünüzden kaçtıysa — bir hata, bir yazım yanlışı ya da aceleyle yapılan bir değişiklik — onu silmeye heveslenebilirsiniz. Ancak paylaşılan bir depoda geçmişi silmek, asıl hatadan daha büyük sorunlara yol açabilir. İşte bu yüzden git revert vardır. Commit’i silmek yerine, değişiklikleri etkisiz kılan yeni bir commit ekler.

Peki, git revert ne yapar?

• Yeni bir commit ekler: Az önce belirttiğim gibi, bir şeyleri silmek yerine git revert geri aldığınız commit’teki belirli değişiklikleri geri alan taze bir commit oluşturur. Bu, proje geçmişinizi tutarlı kılar.

• Değişikliği anında uygular: Henüz söylememiştim; git revert komutunu çalıştırır çalıştırmaz geri alınan değişiklikler çalışma dizininizde görünür. Yani düzeltmeyi anında görürsünüz.

• Staging’e karışmaz (çatışma olmadıkça): Ek bir not: Git, geri almayı dahili olarak yönetir. Her şey yolunda giderse dosyaları elle stage etmenize gerek kalmaz. Ancak Git bir şeyi nasıl tersine çevireceğini çözemiyorsa (karmaşık birleştirmelerde olduğu gibi), müdahale ederek yardımcı olmanızı ister.

Bir Commit’i Geri Aldıktan Sonra Ne Olur

Diyelim ki git revert çalıştırdınız. Tam olarak ne oldu? Git, herhangi bir şeyi silmek yerine hedeflediğiniz commit’te yapılan değişiklikleri tersine çeviren yeni bir commit oluşturur. Bu yeni commit mevcut geçmişinizin üzerine eklenir; yani özgün commit dokunulmadan kalır ve tamamen görünürdür. Hiçbir şey yeniden yazılmaz ya da kaldırılmaz; bunun yerine Git, etkili biçimde “Bunu geri al.” diyen bir katman ekler. Aynı anda, bu tersine çevirmenin dosya değişiklikleri çalışma dizininize anında uygulanır. Tıpkı diğer commit’lerde olduğu gibi, düzeltmenin hemen etkisini görürsünüz.

Bu sürecin tamamı, git revert’i, paylaşılan bir dala zaten push edilmiş hataları düzeltmenin en güvenli yolu yapar. Ekipteki herkes neyin değiştiğini, neyin geri alındığını ve nedenini, devam eden çalışmaları aksatmadan ve kafa karışıklığı olmadan görebilir.

git revert ile git reset’in Karşılaştırılması

Hem git revert hem de git reset commit’leri geri almak için kullanılabilir, ancak temelde farklı şekillerde çalışırlar. git reset, yerel ve özel düzeltmeler için iyidir. Dağınık commit’leri temizlemenize ve çalışma dizininizi tam istediğiniz hale sıfırlamanıza olanak tanır. Ancak bir koşulu vardır: Çalışmanızı zaten push ettiyseniz ve ardından git reset kullandıysanız, paylaşılan commit geçmişini değiştirerek ekip arkadaşlarınız için sorun yaratabilirsiniz.

Öte yandan, git revert özellikle paylaşılan veya herkese açık dallar için tasarlanmıştır. Bir şeyleri silmek yerine, önceki bir commit’ten gelen değişiklikleri etkisiz kılan yeni bir commit oluşturur. Bu, paylaşılan projelerde daha güvenlidir.

Bunu daha net görmek için yan yana bir karşılaştırma:

Birden Fazla Commit’i Geri Alma

Bazen sorun tek bir commit değildir; bir dizi commit’i geri almanız gerekebilir. Neyse ki Git, tek bir komutta commit aralığı kullanarak birden fazla commit’i geri almanıza izin verir.

Sözdizimi şöyle görünür:

git revert OLDEST_HASH^..NEWEST_HASHAltyapı:

Bu komut, Git’e en eski commit’ten hemen önceki noktadan (^ bunun için kullanılır) başlayıp en yenisi de dahil olmak üzere her commit’i geri almasını söyler. Örneğin:

git revert a1b2c3d^..d4e5f6gAltyapı:

Bu komut, o aralıktaki her özgün commit için ayrı ayrı geri alma commit’leri oluşturur.

Dikkat: Birden fazla commit’i aynı anda geri almak, özellikle bu commit’ler aynı dosya veya satırlara dokunduysa, sıkça birleştirme çatışmalarını tetikleyebilir. Git, her commit’i sırayla geri çevirmeye çalışır; ancak çakışan değişiklikleri çözmeniz için yardımınıza ihtiyaç duyabilir.

Git’in geri alma işlemlerini, örneğin birleştirme commit’leri gibi daha zorlu durumları nasıl ele aldığı hakkında daha fazlasını Git Revert Merge Commit: Örneklerle Rehber yazımızda okuyabilirsiniz.

Geri Alma Sırasında Birleştirme Çatışmalarını Yönetme

Geri almak kulağa basit gelebilir; ta ki Git size bir sürpriz yapıp birleştirme çatışması çıkarana kadar. Bunlar genellikle şu durumlarda ortaya çıkar:

• Geri aldığınız commit, yakın tarihli diğer commit’lerle aynı satırları değiştirdiyse.
• Bir birleştirme commit’ini veya örtüşen değişikliklere sahip bir commit grubunu geri alıyorsanız.

Git değişiklikleri temiz biçimde tersine çevirmeye çalışır; ancak belirsizlik varsa durur ve yardımınızı ister.

Bunu şöyle yönetirsiniz:

git revert HEADAltyapı:

Hangi dosyalarda çatışma olduğunu görmek içinse şunu kullanın:

git statusAltyapı:

Çatışmaları elle çözmek için kod düzenleyicinizde <<<<<<<, ======= ve >>>>>>> işaretlerini arayın.

Burada, onları çözülmüş olarak işaretliyorum:

git add <resolved-file>Altyapı:

Şimdi geri almaya devam ediyorum:

git revert-- continueAltyapı:

Fikriniz değişirse ve geri almayı tamamen iptal etmek isterseniz:

git revert --abortAltyapı:

Bu akış size tam denetim sağlar. Geri almaya devam edip etmeyeceğinize ya da tamamen vazgeçeceğinize siz karar verirsiniz.

Git’in bu tür işlemler sırasında başvuru günlüklerini nasıl takip ettiğini anlamak isterseniz, dağınık geçmişleri çözmek için ipuçları içeren Git Reflog: Referans Günlüklerini Anlama ve Kullanma yazısına göz atın.

İstisnai Durumlar: Birleştirme Commit’lerini Geri Alma

Normal bir commit’i geri almak basittir; ancak birleştirme commit’leri bambaşka bir konudur. Bunun nedeni, bir birleştirme commit’inin iki veya daha fazla ebeveyni olması ve Git’in hangi yolu (“ana hat”ı) temel alacağını bilmesi gerekmesidir.

Birleştirme commit’ini geri almak için -m bayrağını açıkça kullanmanız gerekir.

git revert -m 1 <merge-commit-hash>Altyapı:

-m bayrağı şunları yapar:

• -m “mainline” (ana hat) anlamına gelir ve Git’e hangi ebeveyn commit’in korunacağını söyler.

• 1 genellikle birinci ebeveyne, yani birleştirme gerçekleştiğinde üzerinde bulunduğunuz dala karşılık gelir.

• 2 ise sıklıkla içe birleştirilen dala (feature dalı gibi) karşılık gelir.

Peki 1 veya 2 ne zaman kullanılır?

• Ana dalınızdaki çalışmaları koruyup içe birleştirilen değişikliklerin etkisini geri almak istiyorsanız -m 1 kullanın.

• Ana hattın değişikliklerini kaldırıp feature veya birleştirilen dalın içeriğini tutmak istiyorsanız -m 2 kullanın. Bu nadirdir. Birleştirme commit’ini geri almak çatışmalara çok açıktır ve özellikle sonraki commit’ler ona bağlıysa karmaşık bir tabloya yol açabilir. Emin değilseniz, önce bir test dalında geri almayı deneyin.

git revert Kullanırken En İyi Uygulamalar

git revert’ten en iyi şekilde yararlanmak ve yaygın hatalardan kaçınmak için şu en iyi uygulamaları aklınızda bulundurun:

• Geri almadan önce commit hash’lerini doğrulayın: Doğru değişikliği hedeflediğinizden emin olmak için her zaman git log veya git log-- oneline ile commit geçmişinizi inceleyin. Bu komutları Foundations of Git kursuyla tazeleyebilir veya temel bilgileri Git Cheat Sheet sayfamızla elinizin altında tutabilirsiniz.

• Commit mesajınızı özelleştirin: Git’in varsayılan “Revert” mesajıyla yetinmeyin. Neden geri aldığınızı gibi bağlam ekleyin; bu, ekip arkadaşlarınıza (ve gelecekteki size) değişikliği anlamada yardımcı olur.

• Paylaşılan dallarda geri alırken iletişim kurun: main veya develop gibi herkese açık bir dalda değişiklikleri geri alacaksanız, önce ekibinize haber verin. Geri almalar herkesi etkiler ve koordinasyon en iyisidir. İşbirliğine dayalı iş akışları hakkında daha fazlasını GitHub Concepts ve Intermediate GitHub Concepts kurslarımızda öğrenin.

• Emin olmadıkça bir geri almayı geri almayın: Önceki bir geri almayı geri almak, istenmeyen değişiklikleri geri getirebilir veya çatışmalara neden olabilir. Bir değişikliği yeniden uygulamanız gerekiyorsa, bunun yerine git cherry-pick kullanmayı düşünün.

• Ters giderse reflog ile kurtarın: Geri alma ortasında bir hata mı yaptınız? Son işlemlerinizi görüntülemek ve kaybolan durumları kurtarmak için git reflog kullanın.

Sonuç

Profesyonel bir ortamda işbirliği yapıyorsanız, git revert HEAD kullanarak son commit’i git revert ile geri almak, şeffaflığı korurken yanlışlıkla veri kaybı riskini azaltır. İster bir hatayı temizleyin ister bir bug’ı geri alın, revert depo’nuzu herkes için istikrarlı ve anlaşılır tutar.