Yeniden temelden sonra Git dalı ayrıldı

112

Zaten itilmiş olan bir şubeyi yerel olarak yeniden destekledim.

Git, şubemle uzaktan kumandamın ayrıldığını ve şunu tavsiye ediyor:

"ve her biri sırasıyla 109 ve 73 farklı işleme sahip"

Şubemi zorlamak bunu çözecek mi - yani bir yeniden ödemeden sonra bu beklenen bir durum mu?

git

— Marty Wallace
kaynak

Bende de aynı sorun var. "Yapmanın doğru yolunun" yerel şubeyi yeniden temel almak ve ancak o zaman itmek olduğunu söyleyebilir miyiz?

— Mher Didaryan

154

Bir şubeyi yeniden kredilendirdiğinizde, üzerine yeniden kredi verdiğiniz şubedeki taahhütlerin üzerinde olan herhangi bir taahhüt için taahhütleri yeniden yazmanız gerekir. Bunun nedeni, bir commit'in özelliklerinden birinin ebeveyni (veya ebeveynleri) olmasıdır. Yeniden ödeme yaptığınızda, şubenizdeki en eski yerel taahhüdün üstünü değiştirirsiniz - ve böylece, bu değişiklik taahhütlerde geçişli olarak ortaya çıktığı için tüm yerel taahhütlerinizin taahhüt karmalarını değiştirirsiniz.

Şubeyi zaten ittiğiniz için, ona karşı yeniden sıralamak yerine kaynak şubede birleşmiş olmalısınız. Yeni şubenizi "zorla itmek" mümkündür ( -fbayrak kullanarak ), ancak normal bir itme çalışmayacaktır çünkü dalların geçmişinin bütünlüğü bozulacaktır. Bu branşta başkalarıyla işbirliği yapıyorsanız, zorla itmek kötü bir fikirdir, çünkü diğer işbirlikçilerinin geçmişi aniden eşleşmediğinde kafalarının çok karışmasına neden olur.

TL; DR - İşbirliği yapmıyorsanız, dalı -f kullanarak itin. Eğer öyleyseniz, şubeyi önceki durumuna sıfırlayın ve bunun yerine kaynak dalda birleştirin.

— Jason LeBrun
kaynak

1

"Şubeyi zaten ittiğinize göre, kaynak dalda birleşmiş olmalısınız" - bu neden?

— hammett

1

@HamiltonVerissimo Jason'ın ilk cümlesi: "Bir şubeyi yeniden borç verdiğinizde, yeniden ödeme yaptığınız şubedeki taahhütlerin üzerinde olan herhangi bir taahhüt için taahhütleri yeniden yazmanız gerekir." "Yukarıdaki" işlemlerde yakalanan değişiklikler aynı mantıksal içeriğe sahip olsalar da, farklı bir tabana uygulanmaktadırlar ve bu nedenle farklı karmalarla farklı işlemlerdir. Eğer diğer geliştiriciler önceden yeniden oluşturulmuş şubeden çalışıyorsa, git push-f yapmak iş akışları için son derece rahatsız edici olacaktır. Dolayısıyla, bu şube kamuya açık bir kaynağa itildiği için birleşmiş olmalıydı.

— awolf

4

başka birinin zaten bir şeyi ittiğinden emin değilseniz, push --force-lease'i de kullanabilirsiniz.

— Konsol

1

@ jason-lebrun Uyarı yapmadan kendi çalışmanızın üzerine yazabileceğiniz yukarı akış değişikliklerini birleştirmenin dezavantajı değil mi? Birleştirme çakışmaları, yeniden oluşturmada olduğu gibi algılanıyor mu? Örneğin, artık gerekli olmadığı için şubemdeki bir dosyadan bir bölümü kaldırırsam, ancak başka biri yukarı akışta aynı bölümde biraz beyaz boşluk kaldırmak veya bazı genel bul / değiştir eylemi gibi önemsiz bir değişiklik yaptıysa, bunu şubemin üstüne birleştirmek, silme işlemimi önemsiz bir şekilde değiştirilmiş sürümüyle değiştirir mi?

— Chris Bloom

1

Diğer şubeyi sizinkiyle birleştirmek fena bir fikir değil mi? Örneğin, master'ı bir özellik dalında birleştirmek - bu, bunun için yeni bir taahhüt oluşturmaz mı? Daha sonra uzmanlaşmak üzere birleştirilirse, bu özellik dallandığında bu fazladan bir işlemeyle sonuçlanmaz mı?

— Ross

55

Tüm taahhütleriniz kimliklerini değiştirdi, bu nedenle yönlendirme gerçekten bir sapma değil .

Sorununuzun çözülmesi için uzak şubenizin üzerine yazmanız gerekir:

git push -f origin experiment

http://git-scm.com/book/ch3-6.html

Açıklama:

Bu görüntüde, C3'ün yeniden temelden sonra C3 olarak değil, C3 'olarak nasıl koyulduğunu görün. Bunun nedeni, tam olarak C3 olmaması, ancak tüm kod değişikliklerine sahip olmasıdır.

rebase

Bu diğer görüntüde, bir uzaktan kumanda dahil olduğunda bir geri ödemenin nasıl görüldüğünü ve neden bir sapma olduğunu görüyorsunuz.

ayrılmak ve git itmek

Her durumda, zorunlu zorlamayı yaptıktan sonra, size bir (zorla güncelleme) yaptığını söyleyecektir, bu noktada iyi olmalısınız.

Üstteki bağlantıya göz atın ve "git push --force" ifadesini arayın. Daha detaylı bir açıklama göreceksiniz.

— mimoralea
kaynak

3

Evet. Sanırım bu sorunu çözüyor. Ancak, zorlamanız başkaları tarafından zorlanan herhangi bir son işin üzerine yazabileceğinden, bir takımda birlikte çalışırken çalışmayabilir. Haklı mıyım

— Hari Krishna Ganji

İstenilen etkilere sahip olmayabilir. Yeniden ödeme yapmadan önce değişikliklerinizi 'hızlı ileri sarma' ile birleştirdiğinizden emin olun.

— mimoralea

1

Aşağıdakileri yaparak bir itme için yeniden temelde sapma konusunda başarılı oldum:

git checkout mybranch
git pull
git push origin mybranch

Çekme sapmayı çözdü.

Çekmeden ÖNCE

Your branch and 'origin/mybranch' have diverged,
and have 2 and 1 different commit(s) each, respectively.

PULL çıkışı

Özyinelemeli tarafından yapılan birleştirme. mypath / myfile.py | 12 +++++++++++ - 1 dosya değiştirildi, 11 ekleme (+), 1 silme (-)

SONRA çek

Şubeniz 3 kayıt farkla 'menşe / şubemden' önde.

PUSH SONRASI

mybranch şubenin 3 ilerisindedir, işlem geçmişine eklenmiş bir açık çekme isteği birleştirme mesajı hala var Uzak şube mybranch şubesini mybranch ile birleştirin

Bunun muhtemelen kuvvet itişinin yaptığı şey olduğunu varsayıyorum ve henüz doğrulamadım.

Diğerlerinin de söylediği gibi, zaten açık bir çekme talebiniz varsa yeniden ödemeden kaçının. Bu örneği benim için işe yarayan bir şey olarak sunuyorum.

— zerocog
kaynak

1

Bu, hedef şubeyi mevcut yerel şubenize yeniden göndererek, hedef şubenize geçerek ve ardından yerel şubenizi hedefe yeniden göndererek zorlama olmadan düzeltilebilir. Eksik olabilecek kayıtlar eklendiği ve artık yaratılmaları gerekmediği için bu farklılaşmaz. Daha kolay açıklama için örnek:

ana dal gelişiyor
Yeni bir şube özelliğini kontrol edin / doing_stuff
Bir ekip üyesi, gelişmek için yeni bir taahhütte bulunur

Geliştirme şubenizi GÜNCELLEMEDİYSENİZ, satın alma işleminizden bu yana hiçbir kaydetme eklenmediği için bir "git checkout geliştir" && "git rebase özelliği / doing_stuff" düzgün çalışacaktır. Bununla birlikte, geliştirmeyi kontrol ettiyseniz ve yeni commit'i geri çektiyseniz, yeni bir commit görülmesi nedeniyle yeniden ödeme yapmaya çalışırsanız, bu ayrışmayı göreceksiniz. Zorlama olmadan kolay bir düzeltme (genellikle bir ekip ortamında iyi bir fikir değildir):

git checkout özelliği / doing_stuff
git rebase geliştir
git checkout geliştir
git rebase özelliği / doing_stuff

2. adımdaki geri ödeme, eksik commit'i feature / doing_stuff'a getirir, böylece 4. adım geldiğinde günceldir ve değişiklik için yeni bir commit oluşturması gerekmez.

Bu, işe yaradığını bildiğim bir çözüm çünkü bununla karşılaştım ve yukarıdaki adımları zorlamadan başarılı bir şekilde geliştirmek için yaptım. 50'den fazla geliştiriciden oluşan bir ekipte çalışıyorum, bu yüzden kendi test şubelerim dışında herhangi bir şeyi zorlamak yasak, bu yüzden bir çözüm bulmam gerekiyordu.

— Chris
kaynak