Belirli taahhüdü kaldır


287

Bir arkadaşımla bir projede çalışıyordum ve düzenlenmemesi gereken bir sürü dosyayı düzenledi. Her nasılsa, onu çektiğimde ya da istediğim dosyaları seçmeye çalıştığımda çalışmasını bir araya getirdim. Uzun zamandır bakıyorum ve oynuyorum, bu dosyaların düzenlemelerini içeren taahhütlerin nasıl kaldırılacağını anlamaya çalışıyorum, geri dönüş ve rebase arasında bir atış gibi görünüyor ve basit örnekler yok ve dokümanlar benden daha fazlasını bildiğimi varsayar.

İşte sorunun basitleştirilmiş bir versiyonu:

Aşağıdaki senaryo göz önüne alındığında, kesinleştirme 2'yi nasıl kaldırabilirim?

$ mkdir git_revert_test && cd git_revert_test

$ git init
Initialized empty Git repository in /Users/josh/deleteme/git_revert_test/.git/

$ echo "line 1" > myfile

$ git add -A

$ git commit -m "commit 1"
[master (root-commit) 8230fa3] commit 1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 myfile

$ echo "line 2" >> myfile

$ git commit -am "commit 2"
[master 342f9bb] commit 2
 1 files changed, 1 insertions(+), 0 deletions(-)

$ echo "line 3" >> myfile

$ git commit -am "commit 3"
[master 1bcb872] commit 3
 1 files changed, 1 insertions(+), 0 deletions(-)

Beklenen sonuç

$ cat myfile
line 1
line 3

İşte nasıl geri almaya çalıştığımın bir örneği

$ git revert 342f9bb
Automatic revert failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result.

5
Herkes aynı sorunu ararken bulursa, işte sonunda ne yaptım: Kopyala ve yapıştır. Ciddi anlamda. Önerilen çözümleri işe yaramaya çalışmak için 6+ saat geçirdik. Sonunda, zamanım bitti, orijinali çıkardım ve yaklaşık 20 dosyayı kopyaladım / yapıştırdım. 5 dakikadan az sürdü ve o zamandan beri işler iyi oldu (bu dosyalar bu fiyaskodan önce gerçekleşen diğer dallardaki değişikliklerle birleştirilse bile). Ben de bu yaklaşımı benimsemenizi öneririm. Sadece en basit değil, aynı zamanda çalışan tek şey olduğundan şüpheleniyorum.
Joshua Cheek

Benzer bir sorunla karşı karşıya kaldım, ama belki de daha karmaşık: ezmek istediğim yüzlerce taahhüt içeren bir şubem vardı. Maalesef başka bir şubeden alınan taahhütler ara noktada tekrar şubeye birleştirildi. Aşağıda tk tarafından önerilen benzer bir yola indim (kiraz toplama + aralık gösterimini kullanarak), ancak diğer bazı dosyalarda çakışmalar üretti. Son kopyala & yapıştır + 'da birkaç manuel düzenleme, ilerlemenin en kolay ve öngörülebilir yoluydu. Kendinizi bu konuda çok fazla zaman harcıyorsanız kesinlikle dikkate değer.
Federico

Yanıtlar:


73

Git'in geri döndürülecek farkları hesaplarken kullandığı algoritma,

  1. geri döndürülen satırlar daha sonraki taahhütler tarafından değiştirilmez.
  2. tarihin ilerleyen kısımlarında başka bir “bitişik” taahhüt olmadığı.

"Bitişik" tanımı, bir bağlam farkının varsayılan satır sayısını temel alır. Bu 3'tür. Eğer 'dosyam' böyle inşa edilmişse:

$ cat >myfile <<EOF
line 1
junk
junk
junk
junk
line 2
junk
junk
junk
junk
line 3
EOF
$ git add myfile
$ git commit -m "initial check-in"
 1 files changed, 11 insertions(+), 0 deletions(-)
 create mode 100644 myfile

$ perl -p -i -e 's/line 2/this is the second line/;' myfile
$ git commit -am "changed line 2 to second line"
[master d6cbb19] changed line 2
 1 files changed, 1 insertions(+), 1 deletions(-)

$ perl -p -i -e 's/line 3/this is the third line/;' myfile
$ git commit -am "changed line 3 to third line"
[master dd054fe] changed line 3
 1 files changed, 1 insertions(+), 1 deletions(-)

$ git revert d6cbb19
Finished one revert.
[master 2db5c47] Revert "changed line 2"
 1 files changed, 1 insertions(+), 1 deletions(-)

Sonra hepsi beklendiği gibi çalışır.

İkinci cevap çok ilginçti. Henüz resmi olarak yayınlanmamış bir özellik var (Git v1.7.2-rc2'de mevcut olsa da) Revert Strategy adlı. Git'i şu şekilde çağırabilirsiniz:

git revert --strateji çözüm < komut >

ve ne demek istediğinizi anlamak için daha iyi bir iş çıkarmalı. Mevcut stratejiler listesinin ne olduğunu bilmiyorum veya herhangi bir stratejinin tanımını da bilmiyorum.


1
perl -psed'e benzer şekilde girişlerini çıkışa geçiren ve ileten çok kısa (tek satır) programlar yazmak için kullanışlıdır . perl -idosyaları yerinde düzenlemek için kullanılır . değerlendirilecekperl -e kodun nasıl gönderileceği .
Hal Eisen

281

Bunu yapmanın dört yolu vardır:

  • Temiz bir şekilde, geri dönüyor, ancak geri dönmeye devam et:

    git revert --strategy resolve <commit>
    
  • Sert bir şekilde, sadece son taahhüdü tamamen kaldır:

    git reset --soft "HEAD^"
    

Not: git reset --hardSon işlemden bu yana dosyalardaki tüm değişiklikleri de atacağından kaçının . Eğer --softişe yaramazsa, --mixedya da deneyin --keep.

  • Yeniden oluştur (son 5 işlemin günlüğünü gösterin ve istemediğiniz satırları silin veya birden fazla işlemin birini yeniden düzenleyin veya ezin veya istediğiniz başka bir şey yapın, bu çok yönlü bir araçtır):

    git rebase -i HEAD~5
    

Ve bir hata yapılırsa:

git rebase --abort
  • Hızlı rebase: kimliğini kullanarak yalnızca belirli bir taahhüdü kaldırın:

    git rebase --onto commit-id^ commit-id
    
  • Alternatifler: Şunları da deneyebilirsiniz:

    git cherry-pick commit-id
    
  • Yine başka bir alternatif:

    git revert --no-commit
    
  • Son çare olarak, tam tarih düzenleme özgürlüğüne ihtiyacınız varsa (örneğin, git istediğinizi düzenlemenize izin vermediğinden), bu çok hızlı açık kaynak uygulamasını kullanabilirsiniz: reposurgeon .

Not: elbette, tüm bu değişiklikler yerel olarak yapılır, git pushdaha sonra değişiklikleri uzaktan kumandaya uygulamanız gerekir . Ayrıca, repo'nuz taahhüdü kaldırmak istemiyorsa (zaten itmiş olduğunuz bir taahhüdü kaldırmak istediğinizde gerçekleşen "hızlı ileriye izin verilmez"),git push -f değişiklikleri zorlamak .

Not2: bir dal üzerinde çalışıyor ve zorla itmeniz gerekiyorsa, kesinlikle kaçınmalısınız git push --forceçünkü bu, diğer dalların üzerine yazabilir (mevcut kasanız başka bir dalda olsa bile, bunlarda değişiklik yaptıysanız). Push : komutunu zorladığınızda her zaman uzak dalı belirtmeyi tercih edingit push --force origin your_branch .


@Gaborous'un önerilerine dayanarak: "git rebase -i HEAD ~ 2" yapın. Şimdi birkaç seçeneğiniz var. Vim'de yorum yapılan bazı satırlar görebilirsiniz: bunlardan biri size sadece bir satırı silebileceğinizi söyler (kurtulmak istediğiniz taahhüt olmalıdır) ve bu taahhüt geçmişinizdeki günlüğü ile birlikte kaldırılacaktır.
Ilker Cat

git revert --strategy çözmek <commit> .Bu komut benim için çalıştı. teşekkürler :)
Swathin

2
git rebase -i HEAD~5benim için çalıştı. Sonra ihtiyacım olmayan taahhütleri kaldırdım ve sorunu 30 saniyeden daha kısa sürede çözebildim. Teşekkür ederim.
lv10

119

İşte kolay bir çözüm:

git rebase -i HEAD~x

(Not: xtaahhüt sayısıdır)

çalıştırdıktan sonra not defteri dosyası açılacaktır. Taahhüdünüzün dropyanına girin .
Vim'i bilmiyorsanız, düzenlemek istediğiniz her kelime seçimini tıklayın ve ardından "I" tuşuna basın (ekleme modu için). Yazmayı bitirdikten sonra ekleme modundan çıkmak için "esc" tuşuna basın.



resim açıklamasını buraya girin

işte bu kadar, işiniz bitti ... Sadece git kontrol panelini senkronize edin ve değişiklikler uzaktan kumandaya aktarılacak.

Bıraktığınız taahhüt zaten uzaktan kumandadaysa, zorla itmeniz gerekecek. --Force zararlı olduğu için kullanın git push --force-with-lease.


Sadece söz konusu taahhüdün karmasını biliyorsanız, 'x'in ne olması gerektiğini öğrenmenin iyi bir yolu var mı?
jlewkovich

1
Cpp-zihniyet insanlar için: x (taahhüt sayısı) kapsayıcıdır. örneğin HEAD ~ 4 son 4 taahhüdü içerir.
Herpes Ücretsiz Mühendis

mükemmel öneri. sadece eklemek istiyorum, bu da bırakılan taahhüdü değişiklikleri atmak.
celerno

3 taahhüt geri almaya çalıştı: git rebase -i HEAD-3 ölümcül hata aldı: Tek yönlü bir revizyon geçersiz 'HEAD-3' gerekli
Ustin

1
@Ustin bu ~ 3 değil -3
JD-V

37

Seçiminiz arasında

  1. hatayı tutma ve bir düzeltme getirme ve
  2. Hatayı kaldırma ve geçmişi değiştirme.

(1) Hatalı değişiklik başkaları tarafından kabul edilmişse ve (2) hata özel itilmemiş bir dalla sınırlıysa seçmelisiniz.

Git revert yapmak için otomatik bir araçtır (1), önceki bazı taahhütleri geri alarak yeni bir taahhüt oluşturur. Proje geçmişinde hatayı ve kaldırma işlemini görürsünüz, ancak deponuzdan alan kişiler güncelleme sırasında sorun yaşamayacaklardır. Örneğinizde otomatik bir şekilde çalışmıyor, bu yüzden 'myfile' dosyasını (2. satırı kaldırmak için) düzenlemeniz, yapmanız git add myfileve git commitçakışmayla başa çıkmanız gerekir . Daha sonra, tarih 4'te taahhüt 4 geri dönüş taahhüdü 2 ile sonuçlanacaksınız.

Kimse geçmişinizin değişmesini umursamıyorsa, yeniden yazabilir ve 2. taahhüdü kaldırabilirsiniz (2. seçenek). Bunu yapmanın kolay yolu kullanmaktır git rebase -i 8230fa3. Bu sizi bir düzenleyiciye bırakır ve hatalı taahhüdü dahil etmemeyi seçebilirsiniz ve taahhüdü kaldırarak (ve diğer taahhüt mesajlarının yanında "al" seçeneğini saklayarak bunu yapmanın sonuçlarını okuyun .


Rebase zor olabilir, çünkü bir birleşme varmış gibi görünüyor.
Cascabel

3
git rebase -i 8230fa3, ve taahhüt satırını silmek benim için sadece yerel değişiklikler ile harika çalıştı. Teşekkürler!
Samuel

26

Yaklaşım 1

Önce geri almanız gereken işlem karmasını (ör: 1406cd61) alın. basit düzeltme komutun altında olacak,

$ git revert 1406cd61

1406cd61 işleminden sonra 1406cd61 dosyalarıyla ilgili daha fazla değişiklik yaptıysanız, Basit komutun üstünde çalışmaz. Sonra kiraz toplama olan aşağıdaki adımları yapmak zorunda.

Yaklaşım 2

Lütfen aşağıdaki eylemleri takip edin, --force kullandığımız için bunu yapmak için git repo üzerinde yönetici haklarına sahip olmanız gerekir .

1. Adım: Kaldırmak istediğiniz taahhütten önce taahhüdü bulungit log

2. Adım: Tamamlanan ödemegit checkout <commit hash>

3. Adım: Mevcut ödeme işleminizi kullanarak yeni bir şube oluşturungit checkout -b <new branch>

Adım 4: Artık kaldırılan taahhüdün ardından taahhüdü eklemeniz gerekiyorgit cherry-pick <commit hash>

Adım 5: Şimdi saklamak istediğiniz diğer tüm taahhütler için Adım 4'ü tekrarlayın.

Adım 6: Tüm taahhütler yeni şubenize eklendikten ve taahhüt edildiğinde. Her şeyin doğru durumda olduğunu ve gerektiği gibi çalıştığını kontrol edin. Her şeyin yapıldığını bir kez daha kontrol edin:git status

Adım 7: Kırık dalınıza geçingit checkout <broken branch>

Adım 8: Şimdi kaldırmak istediğiniz daldan önce kesinti olmayan dalda sıfırlama gerçekleştiringit reset --hard <commit hash>

Adım 9: Sabit dalınızı bu dalda birleştiringit merge <branch name>

10. Adım: Birleştirilen değişiklikleri başlangıç ​​noktasına geri itin. UYARI: Bu, uzaktan repo üzerine yazacaktır!git push --force origin <branch name>

Adım 2 ve 3'ü Adım 8 ile değiştirerek yeni bir dal oluşturmadan işlemi yapabilirsiniz, ardından Adım 7 ve 9'u gerçekleştirmeyin.


1
İlk yaklaşım bir cazibe gibi çalıştı. İstediğiniz taahhüdün geri alındığını belirten bir taahhüt içerir; bu, izleme amaçları için gerçekten güzeldir.
Mart'ta

18

İle istenmeyen işlemleri kaldırabilirsiniz git rebase. İş arkadaşınızın konu dalından bazı taahhütlerinizi konu dalınıza eklediğinizi, ancak daha sonra bu taahhütleri istemediğinize karar verin.

git checkout -b tmp-branch my-topic-branch  # Use a temporary branch to be safe.
git rebase -i master  # Interactively rebase against master branch.

Bu noktada metin düzenleyiciniz etkileşimli rebase görünümünü açacaktır. Örneğin

Git-Rebase-todo

  1. Çizgilerini silerek istemediğiniz taahhütleri kaldırın
  2. Kaydet ve çık

Rebase başarılı olmazsa, geçici dalı silin ve başka bir strateji deneyin. Aksi takdirde aşağıdaki talimatlara devam edin.

git checkout my-topic-branch
git reset --hard tmp-branch  # Overwrite your topic branch with the temp branch.
git branch -d tmp-branch  # Delete the temporary branch.

Konu dalınızı bir uzaktan kumandaya aktarıyorsanız, tamamlama geçmişi değiştiği için zorlamayı zorlamanız gerekebilir. Diğerleri aynı dalda çalışıyorlarsa, onlara kulak verin.


Lütfen 'başka bir strateji dene' örneği verebilir misiniz?
pfabri

@pfabri, örneğin kötü taahhüdü bıraktığınız iki komisyon aralığını kiraz olarak seçebilirsiniz. Kötü sözleri geri alabilirsin. Değişiklikleri manuel olarak geri alarak ya da kötü bir işlem yapmadan yeni bir daldan başlayıp iyi değişiklikleri manuel olarak yeniden yaparak bir git çözümünü kullanmaktan kaçınabilirsiniz. Kötü taahhüt hassas veriler içeriyorsa, daha dikkatli bir stratejiye ihtiyacınız olacaktır: help.github.com/en/articles/…
Dennis

8

Buradaki diğer cevaplardan, nasıl bir şekilde kafam karıştı git rebase -i bir taahhüdü kaldırmak için kullanılabileceğiyle , bu yüzden test davamı (OP'ye çok benzer) not etmekte sorun yok.

Klasörde bashbir test havuzu oluşturmak için yapıştırabileceğiniz bir komut dosyası /tmp:

set -x

rm -rf /tmp/myrepo*
cd /tmp

mkdir myrepo_git
cd myrepo_git
git init
git config user.name me
git config user.email me@myself.com

mkdir folder
echo aaaa >> folder/file.txt
git add folder/file.txt
git commit -m "1st git commit"

echo bbbb >> folder/file.txt
git add folder/file.txt
git commit -m "2nd git commit"

echo cccc >> folder/file.txt
git add folder/file.txt
git commit -m "3rd git commit"

echo dddd >> folder/file.txt
git add folder/file.txt
git commit -m "4th git commit"

echo eeee >> folder/file.txt
git add folder/file.txt
git commit -m "5th git commit"

Bu noktada, file.txtşu içeriğe sahip bir a var :

aaaa
bbbb
cccc
dddd
eeee

Bu noktada, HEAD 5. taahhütte, HEAD ~ 1 4. olur ve HEAD ~ 4 1. taahhüt olur (yani HEAD ~ 5 mevcut olmaz). Diyelim ki 3. taahhüdü kaldırmak istiyoruz - myrepo_gitdizinde bu komutu verebiliriz :

git rebase -i HEAD~4

( "Ölümcül: Tek bir düzeltme gerekiyor; geçersiz akış yukarı HEAD ~ 5" ile sonuçlandığını unutmayın git rebase -i HEAD~5. ) Bir metin düzenleyici ( @Dennis'in cevabındaki ekran görüntüsüne bakın ) şu içeriklerle açılacaktır:

pick 5978582 2nd git commit
pick 448c212 3rd git commit
pick b50213c 4th git commit
pick a9c8fa1 5th git commit

# Rebase b916e7f..a9c8fa1 onto b916e7f
# ...

Bu yüzden talep edilen KAFA ~ 4'ten beri (ancak dahil değil ) tüm taahhütleri alıyoruz. Satırı silin pick 448c212 3rd git commitve dosyayı kaydedin; bu yanıtı alacaksınız git rebase:

error: could not apply b50213c... 4th git commit

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".
Could not apply b50213c... 4th git commit

Bu noktada myrepo_git / dosyasını folder/file.txtbir metin düzenleyicide açın; değiştirildiğini göreceksiniz:

aaaa
bbbb
<<<<<<< HEAD
=======
cccc
dddd
>>>>>>> b50213c... 4th git commit

Temel olarak, gitHEAD 2. taahhüdüne geldiğinde, aaaa+ içeriğinin olduğunu görür bbbb; ve ardından mevcut içeriğe nasıl ekleneceğini bilmediği bir cccc+ eki eki vardır dddd.

Yani burada gitsizin için karar veremezsiniz - bir karar vermek zorunda olan sizsiniz : 3. taahhüdü kaldırarak ya onun getirdiği değişiklikleri (burada, çizgi cccc) tutarsınız - ya da yapmazsınız. Dahil - Eğer yoksa, sadece ekstra satırları kaldırmak cccciçinde - folder/file.txt: Bu gibi görünüyor, bu yüzden bir metin düzenleyicisi kullanarak

aaaa
bbbb
dddd

... ve sonra kaydet folder/file.txt. Şimdi myrepo_gitdizinde aşağıdaki komutları verebilirsiniz :

$ nano folder/file.txt  # text editor - edit, save
$ git rebase --continue
folder/file.txt: needs merge
You must edit all merge conflicts and then
mark them as resolved using git add

Ah - bu yüzden çatışma çözdük bu işareti amacıyla, biz gerekir , önce göreceğiniz :git addfolder/file.txtgit rebase --continue

$ git add folder/file.txt
$ git rebase --continue

Burada bir metin editörü tekrar açılır ve satırı gösterir 4th git commit- burada taahhüt mesajını değiştirme şansımız var (bu durumda anlamlı bir şekilde değiştirilebilir 4th (and removed 3rd) commitveya benzer olabilir). Diyelim ki istemiyorsunuz - bu yüzden kaydetmeden metin düzenleyicisinden çıkın; bunu yaptıktan sonra şunları elde edersiniz:

$ git rebase --continue
[detached HEAD b8275fc] 4th git commit
 1 file changed, 1 insertion(+)
Successfully rebased and updated refs/heads/master.

Bu noktada, şimdi (örneğin , orijinal taahhütlerin değişmemiş zaman damgalarıyla gitk .) içeriğinin ( örneğin, sözde veya diğer araçlarla da inceleyebilirsiniz) böyle bir geçmişiniz var folder/file.txt:

1st git commit  |  +aaaa
----------------------------------------------
2nd git commit  |   aaaa
                |  +bbbb
----------------------------------------------
4th git commit  |   aaaa
                |   bbbb
                |  +dddd
----------------------------------------------
5th git commit  |   aaaa
                |   bbbb
                |   dddd
                |  +eeee

Ve daha önce, çizgiyi tutmaya karar verdiysek cccc(kaldırdığımız 3. git taahhüdünün içeriği):

1st git commit  |  +aaaa
----------------------------------------------
2nd git commit  |   aaaa
                |  +bbbb
----------------------------------------------
4th git commit  |   aaaa
                |   bbbb
                |  +cccc
                |  +dddd
----------------------------------------------
5th git commit  |   aaaa
                |   bbbb
                |   cccc
                |   dddd
                |  +eeee

Bu, bulabileceğimi umduğum türden bir okuma, git rebasetaahhütleri / revizyonları silme açısından nasıl çalıştığını başlatmak içindi ; umarım başkalarına da yardımcı olabilir ...


Ne paha biçilemez bir gözden geçirme - uğraştığım kesin kullanım örneği, bu bana çok yardımcı oldu.
pfabri

2

Bu yüzden, kötü taahhüt bir noktada birleştirme taahhüdüne dahil edilmiş gibi görünüyor. Birleştirme taahhüdünüz henüz çekilmedi mi? Evet ise, kullanmak isteyeceksiniz git revert; dişlerini gıcırdatmalı ve çatışmalar boyunca çalışmalısın. Cevabınız hayır ise, akla yatkın bir şekilde yeniden temellendirebilir veya geri alabilirsiniz, ancak bunu yapabilirsiniz birleştirme işleminden önce , ardından birleştirmeyi yeniden yapabilirsiniz.

Size ilk dava için verebileceğimiz pek fazla yardım yok. Geri döndürmeyi denedikten ve otomatik olanın başarısız olduğunu bulduktan sonra, çatışmaları incelemeniz ve uygun şekilde düzeltmeniz gerekir. Bu, birleştirme çakışmalarını düzeltmekle tamamen aynı işlemdir; Kullanabileceğiniz git statusçatışmalar nerede, bunları çözmek için nasıl saptamayla çatışmalı hunks bulmak, görmek için düzenlemek birleştirilmemiş dosyaları çatışmalı dosyaları eklemek ve son olarak taahhüt. git commitKendi başınıza kullanırsanız (hayır -m <message>), düzenleyicinizde açılan mesaj tarafından oluşturulan şablon mesajı olmalıdır git revert; çakışmaları nasıl düzelttiğinize dair bir not ekleyebilir, ardından kaydedebilir ve işlemeyi sonlandırabilirsiniz.

İkinci durumda, birleştirme işleminden önce sorunu çözdüğünüzde, birleştirme işleminden bu yana daha fazla iş yapıp yapmadığınıza bağlı olarak iki alt kasa vardır. Eğer git reset --hard HEAD^yapmadıysanız , sadece birleştirme işlemini devredebilir, geri dönüşü yapabilir, ardından birleştirmeyi yeniden yapabilirsiniz. Ama sanırım var. Böylece, böyle bir şey yapacaksınız:

  • birleşmeden hemen önce geçici bir dal oluşturun ve bir bakın
  • geri git rebase -i <something before the bad commit> <temporary branch>dön (ya da kötü taahhüdü kaldırmak için kullan )
  • birleştirmeyi yeniden yap
  • müteakip çalışmanızı geri alın: git rebase --onto <temporary branch> <old merge commit> <real branch>
  • geçici şubeyi kaldır

1

Böylece bir iş yaptınız ve ittiniz, A ve B taahhütlerini diyelim. İş arkadaşınız da bazı işler yaptı, C ve D taahhüt eder. (F taahhüdü) ve iş arkadaşınızın olmaması gereken bazı şeyleri değiştirdiğini keşfetti.

Dolayısıyla, taahhüt geçmişiniz şöyle görünür:

A -- B -- C -- D -- D' -- E -- F

Gerçekten C, D ve D'den kurtulmak istiyorsun. İş arkadaşlarınızın sizin çalışmanızı birleştirdiğinizi söylediğinizden, bu taahhütler zaten "dışarıda" olduğundan, örneğin git rebase kullanarak işlemlerin kaldırılması bir hayır. İnan bana, denedim.

Şimdi iki çıkış yolu görüyorum:

  • E ve F'yi henüz iş arkadaşınıza veya başka birine (genellikle "başlangıç" sunucunuz) aktarmadıysanız, bunları şimdilik geçmişten kaldırabilirsiniz. Bu, kaydetmek istediğiniz çalışmanızdır. Bu bir

    git reset D'
    

    (D 'yerine bir git log

    Bu noktada, E ve F taahhütleri kaybolur ve değişiklikler tekrar yerel çalışma alanınızdaki taahhüt edilmemiş değişikliklerdir. Bu noktada onları bir şubeye taşıyacak veya bir yamaya dönüştürüp daha sonra kullanmak için saklayacağım. Şimdi, iş arkadaşınızın çalışmasını otomatik olarak bir git revertveya manuel olarak geri alın . Bunu yaptığınızda, çalışmanızı bunun üzerine tekrar oynatın. Sen birleştirme çatışmaları olabilir, ama en azından onlar kodunda olacağım sen yerine iş arkadaşınızın kod yazdı.

  • İş arkadaşınızın taahhütlerinden sonra yaptığınız işi daha önce ittiyseniz, yine de elle veya kullanarak bir "ters yama" elde etmeye git revertçalışabilirsiniz, ancak işiniz "yolunda" olduğundan, muhtemelen daha fazla birleşme çatışması ve daha karmaşık olanlar. Görünüşe bakılırsa ...


0

git revert --strategy birleştirme birleştirme ise çözümleme : git revert --strategy -m 1'i kullan

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.