Yanlış Git Branch’ine Atılan Commit Nasıl Güvenle Düzeltilir?

Yanlış branch’e commit attığınızda ilk yapmanız gereken işlem yeni bir düzeltme komutu çalıştırmak değil, mevcut durumu netleştirmektir. Push edilmemiş commit çoğunlukla yeni bir branch’e alınabilir ve kaynak branch’in işaretçisi güvenli biçimde geriye taşınabilir; ancak commit uzak depoya gönderildiyse, branch’in ekip tarafından kullanılıp kullanılmadığı belirleyici olur.

Bu yazıda tüm süreci feature/login değişikliklerinin yanlışlıkla main branch’ine commit edilmesi örneği üzerinden ele alıyoruz. İlk aşamada amaç yalnızca durumu okumaktır: çalışma alanını, aktif branch’i ve yanlış commit’in gerçekten HEAD konumunda olup olmadığını doğrulamadan hiçbir taşıma, reset veya revert işlemi başlatmayın.

İlk Kural: Hiçbir Şeyi Değiştirmeden Durumu Kontrol Edin

Git’te bir commit’i yanlış branch’e atmak, commit’in hemen kaybolduğu anlamına gelmez. Commit, Git geçmişinde bir nesne olarak durmaya devam eder; asıl kritik konu, hangi branch işaretçisinin bu commit’i gösterdiği ve çalışma alanında ayrıca kaydedilmemiş değişiklik bulunup bulunmadığıdır.

Bu nedenle ilk kural basittir: önce kontrol et, sonra karar ver. Henüz hiçbir şeyi geri almayın, git reset --hard çalıştırmayın, yeni bir commit oluşturmayın ve özellikle ekip branch’inde force push düşünmeyin.

Aşağıdaki teşhis, yanlışlıkla main branch’ine commit atıldığı varsayımıyla yapılır. Komutları sırayla çalıştırın; her adımın beklenen sonucunu görmeden bir sonraki düzeltme aşamasına geçmeyin. Git’in resmî belgelerinde git status çalışma ağacını ve index durumunu, git branch --show-current aktif branch adını, git log --oneline ise kısaltılmış commit kimliğiyle tek satırlık geçmiş görünümünü verir: Git resmî komut belgeleri.

1. Çalışma alanını ve staging durumunu kontrol edin

git status

Temiz bir çalışma alanında buna benzer bir çıktı beklenir:

On branch main
nothing to commit, working tree clean

Bu çıktı, çalışma ağacında kaydedilmemiş dosya değişikliği bulunmadığını ve staging alanında commit bekleyen bir değişiklik olmadığını gösterir. Dosyanızın içeriği değişmişse Git genellikle dosyayı modified olarak; yeni ve takip edilmeyen bir dosya varsa untracked olarak bildirir. Staging alanına alınmış değişiklikler de ayrıca gösterilebilir.

Durma noktası: Çıktıda modified, untracked, Changes to be committed veya benzeri bir durum varsa düzeltme komutlarına geçmeyin. Çünkü branch değiştirirken veya bir branch’i geriye alırken bu değişikliklerin üzerine yazılma ya da değişikliklerin farklı bir branch’e taşınması riski vardır.

Bu noktada amacınız dosyaları hemen temizlemek değildir. Kaydedilmemiş değişikliğin ne olduğunu bilmiyorsanız onu silmeyin. Önce değişikliğin commit’e dahil olup olmadığını, hangi dosyaları etkilediğini ve ekip iş akışında nasıl korunacağını belirleyin. Gerekirse ayrı bir güvenli kayıt yöntemi kullanmadan reset --hard gibi çalışma ağacını etkileyen komutlara başvurmayın.

2. Aktif branch’in gerçekten main olduğunu doğrulayın

git branch --show-current

Yanlış senaryoda beklenen çıktı şudur:

main

Bu komut, üzerinde çalıştığınız yerel branch’in adını tek başına yazdırır. Burada main görmeniz, komutların main branch’i üzerinde çalıştırılacağını doğrular. Eğer beklenmedik şekilde feature/login, başka bir branch adı veya boş çıktı görürseniz, varsaydığınız durum ile gerçek durum aynı değildir.

git branch --show-current detached HEAD durumunda branch adı yazdırmayabilir. Böyle bir durumda commit doğrudan bir branch üzerinde değil, belirli bir commit noktasına bağlı geçici bir çalışma durumunda inceleniyor olabilir.

Durma noktası: Çıktı main değilse veya boşsa, main branch’ini düzeltmeye yönelik komutları çalıştırmayın. Önce hangi branch’te olduğunuzu ve neden orada bulunduğunuzu açıklığa kavuşturun. Yanlış branch’i varsayarak alınan bir reset, başka bir çalışmayı etkileyebilir.

3. Yanlış commit’in HEAD konumunda olup olmadığını görün

git log --oneline

Örneğin beklenen geçmiş şöyle görünebilir:

8f3a2c1 Add login validation
42d9b70 Update application configuration
1c4e8aa Initial project setup

git log --oneline çıktısında ilk satır, mevcut HEAD konumundaki en son commit’tir. Bu örnekte 8f3a2c1 commit’i main üzerinde görünen son noktadır. Commit mesajı, gerçekten feature/login için yaptığınız değişiklikle eşleşiyorsa yanlış commit’i bulmuş olabilirsiniz.

Ancak yalnızca commit mesajına güvenmeyin. Benzer mesajlar kullanılabilir veya commit mesajı yapılan değişikliği tam anlatmayabilir. Commit kimliğinin kısa biçimini ve ilk satırda bulunmasını birlikte değerlendirin. Eğer yanlış commit ilk satırda değilse, bu commit artık HEAD değildir; arada başka commit’ler olabilir. Bu durumda doğrudan geriye alma işlemi uygulamak, aradaki commit’leri de etkileyebilir.

Durma noktası: Yanlış commit HEAD değilse düzeltme komutlarına geçmeyin. Önce hangi commit’lerin sonradan geldiğini inceleyin. Aynı şekilde git log --oneline çıktısı beklediğiniz projeye ait görünmüyorsa veya commit mesajı login değişiklikleriyle uyuşmuyorsa işlemi durdurun.

Teşhis sonucunu nasıl yorumlamalısınız?

İlk üç kontrolden sonra güvenli bir başlangıç için şu üç koşulun aynı anda sağlanmasını bekleyin:

• git status, çalışma alanının temiz olduğunu göstermeli.
• git branch --show-current, gerçekten main yazdırmalı.
• git log --oneline, yanlışlıkla atılan login commit’ini ilk satırda göstermeli.

Bu üç koşuldan biri sağlanmıyorsa henüz “commit’i taşıma” aşamasında değilsiniz. Önce durumu açıklığa kavuşturmanız gerekir. Özellikle temiz olmayan çalışma alanı ile yanlış commit’in aynı anda bulunması, yeni başlayanların en sık karıştırdığı durumlardan biridir: Commit edilmiş değişiklik ile henüz commit edilmemiş çalışma ağacı değişikliği aynı şey değildir.

Temiz bir çalışma alanı, mevcut commit’i güvenle taşıyacağınız anlamına da tek başına gelmez. Bir sonraki karar için commit’in push edilip edilmediğini, main branch’inin yalnızca size mi ait olduğunu yoksa ekip tarafından mı kullanıldığını ve commit’in yalnızca login değişikliklerini mi içerdiğini belirlemeniz gerekir.

Doğru Yolu Belirleyen Üç Soru: Push, Branch ve İçerik

Yanlış branch commit düzeltme işlemi için tek bir evrensel komut yoktur. Aynı hata, commit’in uzak depoya gönderilip gönderilmediğine, branch’in ortak kullanıma açık olup olmadığına ve commit’in yalnızca feature/login değişikliklerini mi içerdiğine göre farklı şekilde ele alınır.

Karar vermeden önce üç soruyu yanıtlayın: Push edildi mi? Branch ortak mı? Commit’in içeriği gerçekten tek amaçlı mı, yoksa main ile login çalışmasını birbirine karıştıran bir yapı mı var?

Push durumu neden ilk sorudur?

Push edilmemiş bir commit yalnızca yerel depoda bulunur. Bu durumda branch işaretçilerini düzenleme alanınız daha geniştir; yine de işlemden önce yedek almak gerekir. Push edilmiş bir commit ise uzak depoda ve ekip arkadaşlarının yerel geçmişlerinde bulunabilir. Böyle bir geçmişi değiştirmek, başkalarının branch’lerini güncellemelerini zorlaştırabilir.

Bu yüzden “commit’i nasıl silerim?” sorusu yerine önce “bu commit’i kimler görmüş olabilir?” sorusunu sorun. Uzak depoya gönderilip gönderilmediğini bilmiyorsanız, push edilmemiş gibi davranarak reset uygulamayın. Emin olunmayan durumda işlemi durdurup ekip sorumlusuyla veya proje yöneticisiyle konuşmak, birkaç komutla geri dönüşü zor bir durum oluşturmaktan daha güvenlidir.

Branch kişisel mi, ortak mı?

Kendi yerel branch’inizde yaptığınız bir geçmiş düzenlemesi ile ekibin kullandığı main branch’inde yapılan geçmiş düzenlemesi aynı risk düzeyinde değildir. main çoğu takımda ortak referans noktasıdır; burada commit’i yok etmek veya branch’i geriye taşımak, branch’i çeken diğer kişilerin geçmişiyle uyuşmazlık oluşturabilir.

Bu nedenle ekip branch’lerinde force push koşulsuz önerilmez. Force push, uzak branch’in geçmişini değiştirebilir ve başka kişilerin henüz yerel depolarına yansımış commit’leriyle çakışabilir. Kişisel branch’te bile force push ancak branch’in gerçekten kişisel olduğundan ve ekip politikasının buna izin verdiğinden emin olduktan sonra değerlendirilmelidir.

Commit’in içeriği tek amaçlı mı?

Yanlış commit yalnızca feature/login için yazılmış dosyaları içeriyorsa, commit’i doğru branch’e taşımak genellikle daha anlaşılır bir düzeltme yoludur. Fakat aynı commit içinde login ekranı, yapılandırma dosyası, veritabanı ayarı ve main branch’ine ait başka bir düzeltme birlikte bulunuyorsa, commit’i bütünüyle taşımak doğru sonucu vermeyebilir.

Karışık bir commit’i anlamak için önce içerik incelemesi yapın:

git show --stat HEAD
git show HEAD
git diff HEAD^ HEAD

git show --stat HEAD hangi dosyaların ve yaklaşık ne büyüklükte bir değişikliğin commit’e girdiğini hızlıca gösterir. git show HEAD commit mesajı, değişen dosyalar ve satır bazındaki farkları birlikte incelemenizi sağlar. git diff HEAD^ HEAD ise mevcut commit ile bir önceki commit arasındaki farkı karşılaştırır.

Bu komutlar yalnızca inceleme yapar; branch işaretçisini veya dosyaları değiştirmez. Ancak çıktıda hem login çalışmasına hem de main üzerinde kalması gereken dosyalara ait değişiklikler görürseniz taşıma adımına geçmeyin. Önce değişikliklerin nasıl ayrıştırılacağına karar verin.

Karar ağacında güvenli durma ilkesi

Üç sorudan herhangi birinin yanıtı belirsizse güvenli varsayım, işlem yapmamak ve ek bilgi toplamaktır. Özellikle aşağıdaki durumlarda komut zincirini durdurun:

• Commit’in uzak depoya push edilip edilmediği bilinmiyorsa.
• main branch’inin başka geliştiriciler tarafından kullanılıp kullanılmadığı net değilse.
• Yanlış commit’in yalnızca feature/login değişikliklerini içerdiği doğrulanmadıysa.
• Çalışma alanında kaydedilmemiş değişiklikler varsa.
• Yanlış commit, HEAD konumundaki en son commit değilse.
• Hedef branch’in mevcut geçmişi ve çalışma durumu incelenmediyse.

Bu noktadaki amaç en hızlı komutu bulmak değil, geri dönüşü mümkün bir yol seçmektir. Yedek al, içeriği doğrula, ekip etkisini değerlendir sırası; başlangıç seviyesinde Git kullanırken komut ezberlemekten daha güvenli bir çalışma alışkanlığıdır.

Push Edilmemiş Commit’i feature/login Branch’ine Taşıma

Şimdi şu koşulların sağlandığını varsayalım: Yanlış commit main branch’inde HEAD konumunda, commit henüz push edilmemiş, çalışma alanı temiz ve commit yalnızca feature/login değişikliklerini içeriyor. Bu durumda ilk hedef, mevcut commit’e erişimi garanti altına almak; ikinci hedef ise aynı commit’i doğru branch adıyla göstermektir.

1. Önce main için açık isimli bir yedek branch oluşturun

Hâlâ yanlış commit’i gösteren main branch’indeyken aşağıdaki komutu çalıştırın:

git branch backup/main-before-fix

git branch komutu bu kullanımda yeni bir branch işaretçisi oluşturur. backup/main-before-fix adı, bu işaretçinin düzeltme öncesi main konumunu koruduğunu açıkça anlatır. Komut, mevcut HEAD commit’ini değiştirmez ve sizi otomatik olarak yeni branch’e geçirmez.

Beklenen sonuç, genellikle terminalde bir hata mesajı görülmemesi ve komut satırının normal şekilde dönmesidir. Yedek branch’in oluşturulduğunu kontrol etmek için şu komutu kullanabilirsiniz:

git branch --list "backup/*"

Beklenen örnek çıktı şöyledir:

  backup/main-before-fix
* main

Buradaki * işareti hâlâ main üzerinde olduğunuzu gösterir. Yedek branch’in aynı commit’i gösterdiğini doğrulamak için:

git log --oneline --decorate --all -3

Çıktıda yanlış commit’in yanında hem main hem de backup/main-before-fix etiketlerini görmeniz beklenir. Bu, düzeltme sırasında bir hata olsa bile eski commit noktasına yedek branch üzerinden ulaşabileceğiniz anlamına gelir.

Durma noktası: Yedek branch oluşturma komutu hata verirse veya yedek branch’in hangi commit’i gösterdiği net değilse devam etmeyin. Özellikle aynı isimde bir yedek branch zaten varsa, üzerine yazmaya çalışmayın. Önce mevcut branch’in neyi gösterdiğini inceleyin.

2. Mevcut commit noktasından feature/login branch’ini oluşturun

Yedek alındıktan sonra hâlâ yanlış commit’in bulunduğu main konumundasınız. Bu noktadan yeni bir feature/login branch’i oluşturup doğrudan ona geçebilirsiniz:

git switch -c feature/login

switch -c seçeneği yeni branch’i mevcut başlangıç noktasından oluşturur ve başarılı olursa sizi aynı anda yeni branch’e geçirir. Bu senaryoda başlangıç noktası mevcut HEAD, yani yanlışlıkla main üzerinde oluşturulan login commit’idir.

Beklenen çıktı buna benzer olabilir:

Switched to a new branch 'feature/login'

Bu adımdan sonra feature/login branch’i yanlış commit’i göstermeli, backup/main-before-fix yedek işaretçisi de aynı commit’e erişimi korumalıdır. Henüz main üzerinde herhangi bir düzeltme yapılmış değildir.

Durma noktası: feature/login branch’i zaten varsa git switch -c feature/login komutu yeni branch oluşturamaz ve hata verir. Bu durumda -C seçeneğini kullanarak mevcut branch’i körlemesine sıfırlamayın. Var olan branch’in hangi commit’i gösterdiğini, üzerinde çalışma yapılıp yapılmadığını ve ekip tarafından kullanılıp kullanılmadığını önce inceleyin.

Benzer şekilde, ilk teşhiste yanlış commit’in HEAD olmadığı ortaya çıktıysa bu adımı uygulamayın. Yeni branch’i mevcut HEAD üzerinden oluşturmak, aradığınız login commit’ini değil daha sonraki başka bir commit’i taşıyabilir.

3. Yeni branch’in doğru commit’i gösterdiğini doğrulayın

Branch değişikliğinden sonra aktif branch’i ve kısa geçmişi birlikte kontrol edin:

git branch --show-current
git log --oneline -3

Beklenen örnek çıktı:

feature/login
8f3a2c1 Add login validation
42d9b70 Update application configuration

İlk komutun feature/login yazdırması, aktif branch’in doğru olduğunu gösterir. İkinci komutta yanlışlıkla main üzerinde oluşturulan login commit’inin ilk satırda kalması gerekir. Böylece commit’in içeriğini silmeden doğru branch adı altında erişilebilir hâle getirmiş olursunuz.

İsterseniz yedek branch ile yeni branch’in aynı commit’i gösterdiğini de karşılaştırabilirsiniz:

git log --oneline --decorate --all -3

Çıktıda aşağıdakine benzer bir görünüm arayın:

8f3a2c1 (HEAD -> feature/login, backup/main-before-fix, main) Add login validation

Bu görünüm, üç branch işaretçisinin aynı commit’e ulaştığını anlatır. Bu aşamada bu normaldir: main henüz geriye alınmamıştır. Düzeltmenin devamındaki işlem, main branch’inin artık login commit’ini göstermemesi için kontrollü biçimde düzenlenmesidir; ancak bu işlemin seçimi push durumu, branch’in ortak olup olmadığı ve ekip politikasına bağlıdır.

Son bir kez çalışma alanını da kontrol edin:

git status

Çalışma alanı temiz görünüyorsa taşıma işleminin ilk kısmı tamamlanmıştır. Bundan sonraki adımda amaç, doğru commit’i feature/login üzerinde bırakırken main branch’ini güvenli biçimde düzeltmektir. Bu nedenle yedek branch’i silmeyin; düzeltmenin sonucu doğrulanana ve ekip akışıyla uyumlu olduğu kesinleşene kadar saklayın.

Main Branch’ini Düzeltirken Revert ve Reset Nasıl Seçilir?

Yanlış commit’i önce feature/login branch’i üzerinde güvence altına aldıysanız, main branch’ini düzeltmek için iki temel seçeneğiniz vardır: git revert ve git reset. Aralarındaki en önemli fark şudur: git revert geçmişi koruyarak hatalı değişikliği tersine çeviren yeni bir commit oluşturur; git reset ise mevcut branch’in HEAD işaretçisini daha eski bir commit’e taşır. Bu nedenle iki komut aynı hatayı hedefleyebilse de aynı Git geçmişini üretmez. ([git-scm.com](https://git-scm.com/docs/git-revert?utm_source=openai))

Paylaşılmış veya korunması gereken main için git revert

main üzerinde yanlışlıkla oluşturulan commit henüz uzak depoya gönderilmemiş olsa bile, branch’in geçmişini açık ve izlenebilir tutmak istiyorsanız git revert daha kontrollü seçenektir. Özellikle ekip arkadaşlarının inceleyeceği, CI süreçlerinin takip ettiği veya yakında paylaşılacak bir branch’te bu yaklaşım daha anlaşılır bir kayıt bırakır.

Örnekte abc1234, yanlışlıkla main branch’ine atılan login değişikliğini temsil ediyor. Commit daha önce feature/login üzerinde güvence altına alınmış kabul edilmektedir:

git switch main
git status --short
git branch backup/main-before-revert
git log --oneline -3
git revert abc1234
git log --oneline -4

Beklenen sonuç: Git, abc1234 commit’inin yaptığı değişiklikleri tersine çeviren yeni bir commit oluşturur. Log çıktısında hem eski yanlış commit’i hem de onu geri alan yeni commit’i görürsünüz. Örneğin geçmiş kabaca şu hâle gelebilir:

91de222 Revert "Login doğrulaması eklendi"
abc1234 Login doğrulaması eklendi
7ab9010 Kullanıcı oturumu düzenlendi

Burada abc1234 geçmişten silinmez. Onun etkisi, yeni oluşturulan revert commit’i ile geri alınır. Git’in resmî dokümantasyonuna göre git revert, daha önceki bir commit’in getirdiği değişiklikleri tersine çevirir ve bu işlemi kaydeden yeni commit veya commit’ler oluşturur. İşlem başlamadan önce çalışma alanının temiz olması beklenir. ([git-scm.com](https://git-scm.com/docs/git-revert?utm_source=openai))

• Durma noktası: git status --short çıktısı kaydedilmemiş değişiklik gösteriyorsa önce durun.
• Revert işlemi çatışma üretirse hemen yeni komutlar sıralamayın; önce hangi dosyalarda çatışma olduğunu inceleyin.
• Hatalı commit’in gerçekten abc1234 olduğundan emin değilseniz git show abc1234 ile içeriği kontrol edin.
• Revert sonrasında git diff ve git log --oneline çıktısını incelemeden sonucu tamamlanmış kabul etmeyin.

Bu yöntemin ana riski, eski commit’in içeriği üzerine daha sonra yeni değişiklikler geldiyse revert işleminin çatışma oluşturabilmesidir. Ayrıca bir commit’in etkisini geri almak, commit’in kendisini geçmişten çıkarmadığı için log daha uzun hâle gelir. Bu bir hata değil, işlemin izlenebilir olmasının sonucudur. Git’in kullanıcı dokümantasyonu da geçmişi başkalarıyla paylaşılmış bir hatayı yeni bir commit oluşturarak geri almayı, geçmişi yeniden yazmaya kıyasla uygun yaklaşım olarak açıklar. ([git-scm.com](https://git-scm.com/docs/user-manual?utm_source=openai))

Yalnızca paylaşılmamış son commit için git reset

git reset, yanlış commit’i branch geçmişinden çıkarılmış gibi göstermek için branch işaretçisini daha eski bir commit’e taşır. Bu nedenle yalnızca henüz paylaşılmamış, başka geliştiricilerin çekmediği ve genellikle HEAD konumunda bulunan son commit için değerlendirilmelidir. Yanlış commit’in arkasından başka commit’ler geldiyse veya commit uzak depoya gönderildiyse, hedefi ve etkileri ayrıca doğrulamadan reset uygulamak güvenli değildir.

Yalnızca yanlış commit’in main üzerindeki son commit olduğu, feature/login branch’inde korunduğu ve çalışma alanında kaydedilmemiş değişiklik bulunmadığı senaryoda kısa akış şöyledir:

git switch main
git status --short
git branch backup/main-before-reset
git log --oneline -3
git reset --hard HEAD~1
git log --oneline -3

Beklenen sonuç: main branch’i bir önceki commit’i göstermeye başlar. Yanlış commit artık main branch’inin normal log akışında görünmez; ancak oluşturduğunuz backup/main-before-reset branch’i ve yerel reflog sayesinde hâlâ erişilebilir durumdadır.

7ab9010 Kullanıcı oturumu düzenlendi
6cd4400 Proje başlangıç ayarları

Git’in resmî açıklamasında reset’in son biçiminin mevcut branch’in HEAD konumunu belirtilen commit’e taşıdığı ve seçilen moda göre index ile çalışma alanını da değiştirebildiği belirtilir. --hard seçeneği çalışma alanını ve index’i hedef commit ile eşleştirdiği için kaydedilmemiş değişiklikleri kaybetme riski taşır. ([git-scm.com](https://git-scm.com/docs/git-reset/2.51.0.html))

git reset --hard öncesi durma kontrolü:

• Çalışma alanı temiz mi? git status --short boş sonuç vermeli.
• Gerçekten main branch’inde misiniz? git branch --show-current ile kontrol edilmeli.
• Geri dönülecek commit kimliği veya hedefi doğrulandı mı? En azından git log --oneline ile incelenmeli.
• Mevcut durumu koruyan bir yedek branch var mı? Örneğin backup/main-before-reset.

Bu dört şarttan biri sağlanmıyorsa git reset --hard komutunu çalıştırmayın. Özellikle “yanlış branch’te miyim?” sorusunun cevabı belirsizse, önce durumu incelemek güvenli düzeltmenin parçasıdır. --hard seçeneğini körlemesine kullanmak, henüz commit edilmemiş başka dosya değişikliklerini de ortadan kaldırabilir.

Kısa karar çerçevesi şöyledir:

Bu ayrımı öğrendikten sonra Git geçmişi, branch işaretçileri ve hata düzeltme akışlarını yazılım geliştirme rehberleri arşivinde farklı örneklerle inceleyebilirsiniz.

Commit Push Edildiyse Kişisel ve Ortak Branch’i Ayırın

Yanlış commit uzak depoya gönderildiyse ilk soru “Hangi komutu çalıştırmalıyım?” değil, bu remote branch’i kimler kullanıyor? olmalıdır. Commit main branch’ine push edildiyse bu branch’in ekip tarafından çekilmiş veya CI/CD süreçlerince takip ediliyor olma ihtimali vardır. Buna karşılık yalnızca size ait, kimsenin kullanmadığı bir çalışma branch’i farklı değerlendirilebilir.

Ortak main branch’inde geçmişi yeniden yazmayın

Yanlış commit’i feature/login üzerinde koruduğunuzu varsayalım. Ortak main branch’inde amaç, geçmişi yok etmek değil, hatalı değişikliğin etkisini yeni bir commit ile geri almaktır:

git switch main
git fetch origin
git branch backup/main-before-revert
git log --oneline --decorate -5
git revert abc1234
git log --oneline --decorate -5
git push origin main

Beklenen sonuç: Yerel main üzerinde yeni bir revert commit’i oluşur ve normal push ile uzak main branch’ine gönderilir. Uzak geçmişte yanlış commit ile onu geri alan commit birlikte bulunur. Böylece ekip arkadaşlarının mevcut commit zinciri değişmez; yalnızca son duruma hatalı değişikliği geri alan yeni bir adım eklenir. git revert paylaşılmış geçmişte bu nedenle daha güvenli bir iletişim biçimidir. ([git-scm.com](https://git-scm.com/docs/git-revert?utm_source=openai))

git fetch origin sonrasında remote üzerinde sizden sonra yeni commit’ler olduğunu görürseniz, özellikle push reddedilirse zorlamayın. Önce ekip arkadaşlarınızla hangi değişikliklerin geldiğini ve revert’in bu değişikliklerle çakışıp çakışmadığını inceleyin. Bu bölümde amaç, ortak branch’in geçmişini tek kişinin kararıyla yeniden yazmamak ve beklenmedik kayıp oluşturmamaktır.

• Yanlış commit’in kimliğini doğrulamadan revert etmeyin.
• main branch’inde yeni commit’ler varsa revert’in etkisini inceleyin.
• Normal push reddedilirse --force ile devam etmeyin.
• Revert sonrasında testleri ve ilgili login akışını kontrol edin.

Kişisel ve paylaşılmamış branch’te reset ihtimali

Yanlış commit yalnızca size ait bir feature/login branch’ine push edildiyse, geçmişi yeniden düzenlemek teknik olarak değerlendirilebilir. Ancak “branch benim” demek tek başına yeterli değildir. Önce ekip politikası, remote branch’in son durumu ve başka bir commit gelip gelmediği kontrol edilmelidir.

git switch feature/login
git fetch origin
git branch backup/feature-login-before-reset
git log --oneline origin/feature/login..feature/login
git log --oneline feature/login..origin/feature/login
git reset --hard HEAD~1
git push --force-with-lease origin feature/login

Burada iki log komutu farklı soruları yanıtlar. İlk komut, yerel branch’te remote’da bulunmayan commit’leri gösterir. İkinci komut ise remote branch’te yerel branch’inizde bulunmayan commit’leri gösterir. İkinci komut çıktı veriyorsa veya remote’un güncel durumu belirsizse remote ilerlemiş kabul edin ve durun. Reset’i geri almaya ve force push yapmaya çalışmadan önce remote’daki yeni commit’lerin kime ait olduğunu netleştirin.

git push --force-with-lease, normal push’ın reddedeceği bir geçmiş değişikliğini gönderirken remote referansının beklenen konumda olup olmadığını kontrol eden bir koruma sağlar. Buna karşılık düz git push --force, bazı güvenlik kontrollerini devre dışı bırakabilir ve remote repository’deki commit’lerin kaybolmasına neden olabilir. Bu yüzden force push gerekli görülse bile --force-with-lease tercih edilmelidir. ([git-scm.com](https://git-scm.com/docs/git-push?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2NzI5ODE2OTMsImZpbGVHVUlEIjoiUXZMYnZIZnEwbTBteVFuTiIsImlhdCI6MTY3Mjk4MTM5MywiaXNzIjoidXBsb2FkZXJfYWNjZXNzX3Jlc291cmNlIiwidXNlcklkIjo2MjMyOH0.7I38f2qXVP0n5LaO6ZHZ5hThxqOXSpKotPMuS6T5s6k))

Yine de --force-with-lease risksiz bir onay mekanizması değildir. Git’in resmî dokümantasyonu, bu seçeneğin varsayılan kullanımının yerel remote-tracking bilgisine dayandığını ve arka planda çalışan bir fetch işleminin bu bilgiyi güncelleyebileceğini belirtir. Bu nedenle komutu çalıştırmadan önce remote durumu bilinçli biçimde kontrol edilmelidir. ([git-scm.com](https://git-scm.com/docs/git-push?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2NzI5ODE2OTMsImZpbGVHVUlEIjoiUXZMYnZIZnEwbTBteVFuTiIsImlhdCI6MTY3Mjk4MTM5MywiaXNzIjoidXBsb2FkZXJfYWNjZXNzX3Jlc291cmNlIiwidXNlcklkIjo2MjMyOH0.7I38f2qXVP0n5LaO6ZHZ5hThxqOXSpKotPMuS6T5s6k))

Force push için son durma noktası:

• Branch’in gerçekten kişisel olduğundan emin değilseniz durun.
• Remote branch’te sizden sonra commit varsa durun.
• Yedek branch oluşturulmadıysa durun.
• Remote’un beklenen commit’te olduğu doğrulanmadıysa durun.
• --force-with-lease reddedilirse zorlamadan işlemi sonlandırın; plain --force kullanmayın.

Karışık Commit’leri İnceleme ve Hatalı İşlemden Kurtarma

Yanlış commit yalnızca login ekranına ait değişiklikleri içermiyorsa, onu bütünüyle feature/login branch’ine taşımak beklenmeyen sonuçlar doğurabilir. Örneğin aynı commit içinde login doğrulaması, veritabanı şeması, test dosyaları ve başka bir ekranın değişiklikleri bulunuyorsa, commit’in tamamını taşımak feature branch’ine ilgisiz veya henüz hazır olmayan kodları da ekler.

Önce commit’in gerçekten ne içerdiğini görün

Bir commit’i yalnızca commit mesajına bakarak değerlendirmeyin. git show, commit mesajını ve commit’in oluşturduğu metinsel farkı gösterir. Dosya listesini daha hızlı görmek için --stat seçeneği kullanılabilir. ([git-scm.com](https://git-scm.com/docs/git-show.html))

git show --stat --oneline abc1234
git show abc1234
git diff main...feature/login

Beklenen inceleme: İlk komut hangi dosyaların değiştiğini özetler. İkinci komut satır satır değişiklikleri gösterir. Üçüncü komut ise iki branch’in ortak atasından feature/login tarafına kadar oluşan farkı incelemenizi sağlar. git diff, commit’ler, branch’ler ve çalışma alanı arasındaki değişiklikleri karşılaştırmak için kullanılır. ([git-scm.com](https://git-scm.com/docs/git-diff))

İnceleme sonucunda yalnızca login ile ilgili parçaları almak gerekiyorsa, commit’in tamamını taşımak yerine yeni ve temiz bir branch üzerinde gerekli değişiklikleri seçerek yeniden commit edin. Başlangıç seviyesinde güvenli yaklaşım, her adımda hazırlanan dosyaları kontrol etmektir:

git switch -c rescue/login-selected main
git diff main...backup/feature-login-before-reset
git add -p
git diff --cached
git commit -m "Login değişikliklerini ayır"

git add -p ile değişiklik parçalarını tek tek seçebilirsiniz. Ardından git diff --cached çıktısı, bir sonraki commit’e gerçekten hangi parçaların gireceğini gösterir. Bu çıktı beklediğiniz login değişikliklerini içermiyorsa commit komutuna geçmeyin. Buradaki amaç, karışık commit’i olduğu gibi taşımak değil, gerekli değişiklikleri bilinçli bir inceleme sonrasında ayrı bir commit olarak oluşturmaktır.

Reset sonrasında commit görünmezse reflog ile erişin

Bir reset işleminden veya branch değişikliğinden sonra commit git log çıktısında görünmeyebilir. Bu durum commit’in anında yok olduğu anlamına gelmez. Git’in reflog mekanizması, yerel repository’de branch uçlarının ve HEAD konumunun nasıl değiştiğini kaydeder. Bu kayıtlar branch değiştirme ve reset gibi hareketlerden önceki commit kimliklerini bulmaya yardımcı olabilir. Reflog yerel kapsamlıdır; uzak repository’nin ortak geçmişi olarak değerlendirilmemelidir. ([git-scm.com](https://git-scm.com/docs/git-reflog.html))

git reflog --oneline
# abc1234 HEAD@{1}: commit: Login doğrulaması eklendi
# 7ab9010 HEAD@{2}: checkout: moving from feature/login to main

git branch rescue/login-commit abc1234
git show --stat rescue/login-commit
git log --oneline rescue/login-commit -1

Beklenen sonuç: rescue/login-commit adlı kurtarma branch’i abc1234 commit’ini gösterir. Böylece reset sonrasında normal branch log’unda görünmeyen login commit’i yeniden erişilebilir hâle gelir. Bu branch oluşturulduktan sonra içeriği inceleyebilir, gerekli parçaları seçebilir veya ekip politikanıza uygun başka bir düzeltme planı hazırlayabilirsiniz.

Reflog kaydında ilgili commit’i bulamıyorsanız, commit kimliği belirsizse veya çalışma alanında önemli kaydedilmemiş değişiklikler varsa yeni bir riskli komut çalıştırmayın. Özellikle bu durumda tekrar reset --hard, force push veya dosya silmeye yönelik bir işlem yapmak sorunu büyütebilir. Önce mevcut dosyaları güvenli bir yere kopyalayın, branch ve remote durumunu not edin ve hangi commit’in korunması gerektiğini kesinleştirin.

• git show ile kurtarmaya çalıştığınız commit’in içeriğini doğrulayın.
• git diff ile branch’ler arasındaki gerçek farkı inceleyin.
• Reflog’da commit kimliği bulunmuyorsa tahminî bir hash kullanmayın.
• Önemli kaydedilmemiş değişiklikler varsa önce onları koruyun.
• Kurtarma branch’i oluşturulmadan önce yeni bir geçmiş değişikliği yapmayın.

Kontrol Et, Taşı, Doğrula, Sonra Düzelt

Yanlışlıkla main branch’ine attığınız commit’i güvenle düzeltmenin en sağlam sırası şudur: kontrol et, taşı, doğrula, sonra düzelt. Önce hangi branch’te olduğunuzu ve çalışma alanınızda kaydedilmemiş değişiklik bulunup bulunmadığını görürsünüz. Ardından yanlış commit’in erişilebilir bir yedeğini oluşturur, bu commit’i feature/login branch’ine taşıdıktan sonra sonucu incelersiniz. En son, commit’in push edilip edilmediğine göre git revert veya uygun koşullarda git reset uygularsınız.

Bu akışın amacı yalnızca komutları çalıştırmak değildir. Her adımda “Şu anda hangi branch değişecek?”, “Commit’in kimliği elimde mi?”, “Uzak depodaki geçmişi etkiliyor muyum?” sorularını yanıtlamaktır. Güvenli Git alışkanlıklarını gerçek proje pratiğiyle geliştirmek isteyenler, bu düşünme biçimini canlı yazılım eğitimleri kapsamında farklı senaryolar üzerinde uygulayabilir.

İşleme devam etmeden önce kontrol listesi

• Doğru branch: Şu anda gerçekten main üzerinde olduğunuzu doğrulayın.
• Temiz çalışma alanı: Kaydedilmemiş dosya değişiklikleri, staged dosyalar veya devam eden bir işlem olmadığından emin olun.
• Kayıtlı commit kimliği: Yanlış commit’in tam veya güvenilir kısa commit kimliğini not edin.
• Yedek branch: Yanlış commit’i işaret eden geçici bir yedek branch oluşturun.
• Push durumu: Commit’in yalnızca yerelde mi kaldığını, yoksa origin/main gibi uzak bir branch’e gönderilip gönderilmediğini kontrol edin.

Bu maddelerden biri doğrulanamıyorsa düzeltme işlemine geçmeyin. Özellikle çalışma alanı temiz değilse, sonraki bir switch, revert veya reset işlemi beklenmedik çatışmalara yol açabilir. Git’in resmî belgelerinde de git revert işleminin temiz bir çalışma ağacı gerektirdiği belirtilir. ([git-scm.com](https://git-scm.com/docs/git-revert?utm_source=openai))

1. Aktif branch’i ve çalışma alanını kontrol edin

   Senaryomuzu somutlaştıralım: Giriş ekranı için hazırladığınız commit’i yanlışlıkla main branch’ine attınız. Önce hiçbir şeyi değiştirmeden terminalde şu komutları çalıştırın:

   git branch --show-current
   git status --short
   git log --oneline --decorate -5

   git branch --show-current çıktısının main olduğunu görmelisiniz. git status --short boş çıktı veriyorsa çalışma alanı temizdir. Son komut ise son commit’leri kısa kimlikleriyle gösterir. Burada giriş ekranı değişikliklerini içeren commit’i belirleyin ve kimliğini not edin; örneğin a1b2c3d.

   Durma noktası: Aktif branch main değilse veya status kaydedilmemiş değişiklik gösteriyorsa sonraki adıma geçmeyin. Önce doğru branch’e geçin ya da yerel değişikliklerinizi ayrı bir commit veya güvenli bir stash ile koruyun.

2. Yanlış commit için yedek branch oluşturun

   Yanlış commit henüz push edilmemiş olsa bile, onu yalnızca “HEAD’in bir önceki hali” olarak düşünmeyin. Önce mevcut konumu isimlendirilmiş bir branch ile sabitleyin:

   git branch backup/main-wrong-login
   git branch --list

   Bu komut, mevcut HEAD konumunu backup/main-wrong-login adlı yeni bir branch ile işaretler. Branch oluşturmak çalışma ağacını değiştirmez; ancak daha sonra bir hata yaparsanız yanlış commit’e yeniden ulaşmanız kolaylaşır.

   Yedek branch’in gerçekten oluştuğunu listede kontrol edin. Bu branch’i işlem bitmeden silmeyin. Git’in reset belgelerinde de bir commit’i topic branch olarak koruyup asıl branch’i geriye almak, yanlış yerde oluşturulmuş commit’leri ayırma senaryosu olarak gösterilir. ([git-scm.com](https://git-scm.com/docs/git-reset?utm_source=openai))

3. Commit’i feature/login üzerinde erişilebilir hâle getirin

   Artık yanlış commit’in güvenli bir referansı vardır. Sıradaki amaç, giriş ekranı değişikliklerini feature/login branch’inde görünür kılmaktır. feature/login zaten mevcutsa şu akışı kullanabilirsiniz:

   git switch feature/login
   git cherry-pick a1b2c3d
   git log --oneline --decorate -3

   Buradaki a1b2c3d yerine kendi yanlış commit kimliğinizi yazın. cherry-pick, seçtiğiniz commit’in değişikliklerini mevcut branch üzerinde yeni bir commit olarak uygular. Böylece feature/login artık giriş ekranı özelliğini içerir; ancak oluşan yeni commit’in kimliği, main üzerindeki ilk commit’ten farklı olabilir.

   Bu adımda beklenen sonuç, feature/login geçmişinde login özelliğini taşıyan bir commit görmenizdir. Eğer cherry-pick sırasında çatışma oluşursa yeni bir düzeltme komutu denemeyin. Çatışmanın nedenini inceleyin; hangi dosyaların etkilendiğini anlamadan devam etmek, yanlış içeriği yeni branch’e taşımaya neden olabilir.

   Durma noktası: git log --oneline --decorate -3 çıktısında login commit’ini göremiyorsanız main branch’ini düzeltmeye başlamayın.

4. Taşınan commit’i log, show ve diff ile doğrulayın

   Bir branch’in commit’i içeriyor görünmesi tek başına yeterli değildir. Commit mesajını, değişen dosyaları ve iki branch arasındaki farkı ayrı ayrı kontrol edin:

   git log --oneline --decorate --all --graph -8
   git show --stat a1b2c3d
   git diff main...feature/login
   git status --short

   git log, commit’in hangi branch referansları tarafından erişilebilir olduğunu görmenize yardımcı olur. git show --stat, yanlış commit’in hangi dosyalara dokunduğunu özetler. git diff main...feature/login ise ortak geçmişten itibaren iki branch arasındaki içerik farkını incelemenizi sağlar. Git belgelerinde git log commit geçmişini, git show commit içeriğini ve git diff değişiklikler arasındaki farkı görüntülemek için tanımlanır. ([git-scm.com](https://git-scm.com/docs/git-log?utm_source=openai))

   Bu karşılaştırmada login dosyalarının feature/login tarafında bulunduğunu, main tarafında ise bulunmadığını veya etkin değişiklik olarak taşınmadığını doğrulayın. git status --short yine boş olmalıdır. Dosya farkı beklediğinizden fazlaysa durun; commit birden fazla işe ait değişiklik içeriyor olabilir.

5. En son main branch’ini commit’in push durumuna göre düzeltin

   Commit’in feature/login üzerinde güvenli biçimde erişilebilir olduğunu doğruladıktan sonra main branch’ine dönün:

   git switch main
   git status --short
   git log --oneline --decorate -3

   Burada tekrar main üzerinde olduğunuzu kontrol edin. Bundan sonraki seçim, yanlış commit’in uzak depoya gönderilip gönderilmediğine bağlıdır.

   Commit yalnızca yerelde kaldıysa

   Commit hiç push edilmediyse ve başka bir geliştirici bu commit’i temel alarak çalışmaya başlamadıysa, main branch’ini commit’in ebeveynine döndürmek düşünülebilir. Önce yedek branch’in varlığını ve çalışma alanının temizliğini yeniden kontrol edin:

   git branch --list
   git status --short
   git reset --keep HEAD~1
   git log --oneline --decorate -3
   git status --short

   --keep, branch işaretçisini geriye alırken çalışma alanındaki yerel değişiklikleri mümkün olduğunca korumayı amaçlar. Ancak bu seçeneği de körlemesine kullanmayın: komut beklemediğiniz bir durum bildirirse işlemi zorlamayın. git reset --hard özellikle kaydedilmemiş çalışma alanı değişikliklerini kaybettirebileceğinden, bu senaryoda ilk tercih olmamalıdır.

   Durma noktası: Reset sonrasında main geçmişinde login commit’i görünmemeli, feature/login ise özelliği içermeye devam etmelidir. Çalışma alanı temiz değilse veya commit beklenmedik biçimde hâlâ görünüyorsa sonraki adıma geçmeyin.

   Commit push edildiyse

   Yanlış commit uzak main branch’ine gönderildiyse, ortak geçmişi yeniden yazmak yerine genellikle git revert daha güvenli yaklaşımdır:

   git revert --no-edit a1b2c3d
   git log --oneline --decorate -3
   git status --short

   Bu işlem eski commit’i geçmişten silmez; onun yaptığı değişiklikleri tersine çeviren yeni bir commit oluşturur. Böylece ekip arkadaşlarının yerel geçmişi, branch’i zorla yeniden yazılmış gibi bozulmaz. Git’in resmî açıklamasına göre git revert, daha önceki commit’in etkisini tersine çevirmek için yeni bir commit kaydeder. ([git-scm.com](https://git-scm.com/docs/git-revert?utm_source=openai))

   Revert sonrasında login değişikliğinin main üzerinde etkin olmadığını, buna karşılık feature/login branch’inde korunduğunu kontrol edin. Revert sırasında çatışma çıkarsa işlemi tamamlanmış kabul etmeyin; Git’in gösterdiği dosyaları inceleyin ve gerekirse devam etmeden önce işlemi iptal edin.

6. Uzak depo durumunu yeniden kontrol edin

   Yerel branch’leri düzeltmek, uzak depodaki branch’lerin otomatik olarak düzeldiği anlamına gelmez. Son kontrolde yerel ve uzak referansları birlikte inceleyin:

   git fetch origin
   git status -sb
   git log --oneline --decorate --all --graph -10

   git fetch origin uzak depodaki referans bilgilerini günceller; çalışma alanınızdaki dosyaları doğrudan değiştirmez. Ardından status -sb ile branch’in upstream durumu, log --all ile de main, feature/login ve ilgili uzak branch’lerin konumu karşılaştırılır.

   Uzak depoda hangi branch’in güncelleneceği netleşmeden push yapmayın. feature/login kişisel ve henüz paylaşılmamışsa normal push yeterli olabilir. Ortak main branch’inde ise revert commit’ini normal push ile göndermek, geçmişi zorla yeniden yazmaktan daha güvenli bir ekip pratiğidir.

   Final senaryoda beklenen durum

   İşlem başarıyla tamamlandığında şu tabloyu görmelisiniz:

   • feature/login, giriş ekranı özelliğini taşıyan commit’i içerir.
   • main, bu özelliği etkin olarak taşımamalıdır.
   • main üzerinde kullanılan yönteme bağlı olarak ya yanlış commit’in öncesindeki geçmişe dönülmüş ya da onu tersine çeviren yeni bir revert commit’i oluşturulmuştur.
   • Çalışma alanı temizdir; git status --short boş çıktı verir.
   • Uzak depodaki branch durumu son kez kontrol edilmiştir.
   • backup/main-wrong-login branch’i, son kontrol tamamlanana ve uzak durum doğrulanana kadar silinmemiştir.

   Yedek branch’i ancak hem yerel hem uzak geçmişin beklenen durumda olduğunu doğruladıktan sonra silmeyi düşünün. Kurtarma ihtimali kalmadığından emin değilseniz branch’i saklamak, birkaç dakikalık temizlikten daha değerlidir.

   Sık Sorulan Sorular

   Yanlış branch’e attığım commit’i dosyaları kaybetmeden nasıl taşırım?

   Önce yanlış commit’in bulunduğu noktadan bir yedek branch oluşturun. Ardından feature/login branch’ine geçip commit’i git cherry-pick COMMIT_ID ile bu branch üzerinde erişilebilir hâle getirin. git show, git diff ve git status ile dosyaların doğru taşındığını doğrulamadan main branch’ini düzeltmeyin. Dosyaları kaybetmemenin temel güvencesi, riskli işlemden önce commit’i işaretleyen yedek branch’in oluşturulmasıdır.

   Push edilmiş yanlış commit için git reset mi, git revert mü kullanılmalı?

   Push edilmiş ve özellikle ekip tarafından kullanılan bir branch söz konusuysa genellikle git revert tercih edilir. Revert, hatalı commit’i silmek yerine etkisini tersine çeviren yeni bir commit oluşturur. git reset ise branch işaretçisini geriye taşıyarak geçmişi yeniden yazabilir; bu nedenle daha çok henüz paylaşılmamış, kişisel ve yerel commit’lerde değerlendirilmelidir.

   git reset --hard sonrasında kaybolan commit git reflog ile kurtarılabilir mi?

   Evet, çoğu durumda commit yerel reflog kayıtlarında hâlâ görülebiliyorsa kurtarılabilir. Önce git reflog ile reset öncesindeki HEAD konumunu bulun, ardından o kayda işaret eden yeni bir kurtarma branch’i oluşturun: git branch rescue/lost-commit HEAD@{N}. Reflog yerel depodaki branch ve HEAD hareketlerini kaydeder; uzak depoya paylaşılmaz ve eski kayıtlar zaman içinde temizlenebilir. Bu yüzden kurtarma kaydını bulduğunuz anda yeni bir branch ile sabitleyin. ([git-scm.com](https://git-scm.com/docs/git-reflog.html?utm_source=openai))

   git push --force-with-lease hangi durumda değerlendirilebilir?

   git push --force-with-lease, kişisel bir branch’in geçmişini yeniden yazmanız gerektiğinde ve uzak branch’in siz son kontrol ettikten sonra başka bir commit ile ilerlemediğini doğruladığınızda değerlendirilebilir. Öncesinde uzak durumu güncelleyin, ilgili branch’in gerçekten kişisel veya koordineli bir çalışma alanı olduğunu teyit edin ve beklenen uzak commit’i bildiğinizden emin olun. Ortak main branch’inde veya ekip arkadaşlarının kullandığı bir branch’te koşulsuz kullanılmamalıdır. Git belgeleri, bu seçeneğin uzak branch’teki beklenmeyen değişiklikleri korumaya yönelik bir güvenlik kontrolü sunduğunu; ancak arka planda yapılan fetch işlemleriyle birlikte dikkat gerektirdiğini belirtir. ([git-scm.com](https://git-scm.com/docs/git-push?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2NzI5ODE2OTMsImZpbGVHVUlEIjoiUXZMYnZIZnEwbTBteVFuTiIsImlhdCI6MTY3Mjk4MTM5MywiaXNzIjoidXBsb2FkZXJfYWNjZXNzX3Jlc291cmNlIiwidXNlcklkIjo2MjMyOH0.7I38f2qXVP0n5LaO6ZHZ5hThxqOXSpKotPMuS6T5s6k&utm_source=openai))

   Yanlış commit birden fazla işe ait değişiklik içeriyorsa ne yapılmalı?

   Commit hem login ekranını hem de başka bir özelliği içeriyorsa onu tek parça olarak taşımak yerine önce yedek branch’te koruyun ve git show COMMIT_ID ile değişiklikleri ayırın. Hangi dosya veya kod bloklarının feature/login kapsamına girdiğini belirledikten sonra yalnızca ilgili parçaları yeni commit’lere ayırmak daha güvenlidir. Diğer değişiklikleri de ayrı bir branch veya ayrı commit olarak koruyun. Kapsamı net olmayan büyük bir commit’i doğrudan main üzerinde resetlemek ya da revert etmek, doğru login değişikliklerini de geri alabilir.

   Git’te güvenli düzeltme, en hızlı komutu seçmekten çok her adımda hangi geçmişi koruduğunuzu bilmektir.