Git geçmişindeki belirli bir düzeltmeyi nasıl kaldırırsınız?

Git geçmişinizin şöyle olduğunu varsayalım:

1 2 3 4 5

1–5 ayrı düzeltmelerdir. Hala 1, 2, 4 ve 5'i tutarken 3'ü kaldırmanız gerekir. Bu nasıl yapılabilir?

Silinecek olandan sonra yüzlerce düzeltme olduğunda etkili bir yöntem var mı?

Revizyon 3 ve 4'ü tek bir revizyonda birleştirmek için git rebase'i kullanabilirsiniz. Düzeltme 3'teki değişiklikleri kaldırmak istiyorsanız, etkileşimli rebase modunda edit komutunu kullanmanız gerekir. Değişiklikleri tek bir revizyonda birleştirmek istiyorsanız squash kullanın.

Bu squash tekniğini başarıyla kullandım, ancak daha önce bir revizyonu kaldırmak zorunda kalmadım. "Bölme işlemleri" altındaki git-rebase belgeleri, umarım bunu anlamanız için yeterince fikir vermelidir. (Ya da başka biri biliyor olabilir).

Gönderen git belgeler :

Olduğu gibi tutmak istediğiniz en eski taahhütle başlayın:

git rebase -i <after-this-commit>

Mevcut şubenizdeki tüm taahhütlerle (birleştirme taahhütlerini göz ardı ederek), verilen taahhütten sonra gelen bir editör çalıştırılacaktır. Bu listedeki taahhütleri kalbinizin içeriğine göre yeniden sıralayabilir ve kaldırabilirsiniz. Liste aşağı yukarı böyle görünüyor:

deadbee seç Bu taahhüdün sonucu
fa1afe1 pick Bir sonraki işlemin sonucu
...

Oneline açıklamaları sadece sizin zevkiniz içindir; git-rebase bunlara bakmaz, ancak taahhüt adlarına (bu örnekte "deadbee" ve "fa1afe1"), bu nedenle adları silmeyin veya düzenlemeyin.

"Pick" komutunu "edit" komutuyla değiştirerek, git-rebase'e bu komutu uyguladıktan sonra durmasını söyleyebilir, böylece dosyaları ve / veya taahhüt mesajını düzenleyebilir, taahhüdü değiştirebilir ve yeniden baslamaya devam edebilirsiniz.

İki veya daha fazla komutu bire katlamak istiyorsanız, ikinci ve sonraki işlem için "pick" komutunu "squash" ile değiştirin. Komisyonların farklı yazarları olsaydı, ezilmiş taahhüdü ilk taahhüdün yazarına bağlar.

Bu yorum başına (ve bunun doğru olduğunu kontrol ettim), rado'nun cevabı çok yakın ama ayrık bir kafa durumunda git bırakır. Bunun yerine, bulunduğunuz şubeden HEADkaldırmak için bunu kaldırın ve kullanın <commit-id>:

git rebase --onto <commit-id>^ <commit-id>

Aşağıda, <commit-id>yalnızca <commit-id>kaldırmak istediğinizi bilerek etkileşimli olmayan bir şekilde kaldırmanın bir yolu vardır :

git rebase --onto <commit-id>^ <commit-id> HEAD

Daha önce belirtildiği gibi git-rebase (1) arkadaşınızdır. Taahhütlerin şubenizde olduğunu varsayarsak master, şunları yaparsınız:

git rebase --onto master~3 master~2 master

Önce:

1---2---3---4---5  master

Sonra:

1---2---4'---5' master

Git-rebase'den (1):

Rebase ile bir dizi taahhüt de kaldırılabilir. Aşağıdaki durumumuz varsa:

E---F---G---H---I---J  topicA

sonra komut

git rebase --onto topicA~5 topicA~3 topicA

F ve G komisyonlarının kaldırılmasıyla sonuçlanır:

E---H'---I'---J'  topicA

Bu, F ve G bir şekilde kusurluysa veya A konusunun bir parçası değilse faydalıdır. --Onto ve parametresinin bağımsız değişkeninin geçerli herhangi bir kesinleştirme olabileceğini unutmayın.

Tek yapmanız gereken revizyon 3'te yapılan değişiklikleri kaldırmaksa git revert komutunu kullanmak isteyebilirsiniz.

Git revert, geri almakta olduğunuz revizyondaki tüm değişiklikleri geri alan değişikliklerle yeni bir revizyon oluşturur.

Bunun anlamı, hem istenmeyen taahhüt hem de bu değişiklikleri kaldıran taahhüt hakkında bilgi tutmanızdır.

Birisi deponuzdan birisinin bu süre zarfında çekmiş olması mümkünse, bu muhtemelen çok daha dostudur, çünkü geri dönüş temelde sadece standart bir taahhüttür.

Şimdiye kadar olan tüm cevaplar, takip eden endişeyi gidermiyor:

Silinecek olandan sonra yüzlerce düzeltme olduğunda etkili bir yöntem var mı?

Adımlar takip edilir, ancak referans için aşağıdaki geçmişi varsayalım:

[master] -> [hundreds-of-commits-including-merges] -> [C] -> [R] -> [B]

C : kaldırılacak taahhüdü takip eden taahhüt (temiz)

R : Kaldırılacak taahhüt

B : kaldırılacak taahhütten hemen önceki taahhüt (taban)

"Yüzlerce düzeltme" kısıtlaması nedeniyle, aşağıdaki ön koşulları varsayıyorum:

1. hiç var olmamak istediğin utanç verici bir taahhüt var
2. aslında bu utanç verici taahhüdüne bağlı olan SIFIR müteakip taahhütleri vardır (geri dönüşte sıfır çatışma)
3. müdahale eden yüzlerce taahhüdün 'Committer' olarak listelenmesini umursamazsınız ('Yazar' korunacaktır)
4. depoyu hiç paylaşmadın
   • ya da aslında tarihini klonlayan tüm insanlar üzerinde, yeni tarihinizi kullanmaya ikna etmek için yeterince etkiniz var.
   • ve umurumda değil yaklaşık tarihini yeniden yazma

Bu oldukça kısıtlayıcı bir dizi kısıtlamadır, ancak aslında bu köşe durumunda çalışan ilginç bir cevap var.

İşte adımlar:

1. git branch base B
2. git branch remove-me R
3. git branch save
4. git rebase --preserve-merges --onto base remove-me

Eğer gerçekten çatışma yoksa, bu daha fazla kesinti olmaksızın devam etmelidir. Çatışmalar varsa, bunları çözebilir verebase --continue veya utançla yaşamaya karar verebilirsiniz rebase --abort.

Şimdi, masterartık R'yi taahhüt etmemiş olmalısınız . saveDaha önce bulunduğunuz yere geri şube noktaları, eğer uzlaştırmak istiyorum.

Başkalarının yeni geçmişinize aktarımını nasıl düzenlemek istediğiniz size bağlıdır. Sen tanımak gerekir stash, reset --hardve cherry-pick. Ve silebilir base, remove-meve savedalları

Ben de benzer bir duruma düştüm. Aşağıdaki komutu kullanarak etkileşimli rebase kullanın ve seçerken 3. kesinti bırakın.

git rebase -i remote/branch

İşte karşılaştığım senaryo ve bunu nasıl çözdüğüm.

[branch-a]

[Hundreds of commits] -> [R] -> [I]

işte Rkaldırılmam gereken taahhüt ve Ibundan sonra gelen tek bir taahhütR

Bir geri dönüş yaptım ve onları birlikte ezdim

git revert [commit id of R]
git rebase -i HEAD~3

Etkileşimli rebase squash sırasında son 2 taahhüt.

Rado ve kareem'in cevapları benim için hiçbir şey yapmaz (sadece "Şimdiki şube güncel." Mesajı görünür). Muhtemelen bu, '^' sembolü Windows konsolunda çalışmadığı için olur. Ancak, bu yoruma göre , '^' yerine '~ 1' kullanılması sorunu çözmektedir.

git rebase --onto <commit-id>^ <commit-id>