ana dal ve 'köken / usta' birbirinden ayrıldı, 'dallar' nasıl kesilir?

Bir şekilde efendim ve kökenim / efendi şubem birbirinden ayrıldı.
Aslında ayrılmalarını istemiyorum.

Bu farklılıkları nasıl görebilir ve 'birleştirebilirim'?

Farklılıkları aşağıdakilerle inceleyebilirsiniz :

git log HEAD..origin/master

önce çekerek (+ birleştirme getirme) (ayrıca bkz "her zaman belirli bir şubesinden çekmeye sen budala nasıl alabilirim?" )

Şöyle bir mesajınız olduğunda:

"Şubeniz ve 'başlangıç ​​noktanız / ustanız' birbirinden ayrıldı, # ve her biri sırasıyla 1 ve 1 farklı taahhüde sahip."

, güncellemenizorigin gerekip gerekmediğini kontrol edin . Eğer originup-to-date, sonra bazı kaydedilmesini itilmiş originyerel olarak kendi kaydedilmesini yapılmış ise başka repo.

... o ---- o ---- A ---- B  origin/master (upstream work)
                   \
                    C  master (your work)

C taahhüdünü A taahhüdüne dayandırdınız, çünkü o zamanlar yukarı akımdan aldığınız en son işti.

Bununla birlikte, kökene geri dönmeye çalışmadan önce, bir başkası B'yi zorladı.
Geliştirme tarihi ayrı yollara ayrıldı.

Daha sonra birleştirebilir veya yeniden pazarlayabilirsiniz. Ayrıntılar için Pro Git: Git Branching - Rebasing konusuna bakın .

Birleştirmek

Git merge komutunu kullanın:

$ git merge origin/master

Bu Git'e değişiklikleri origin/masterçalışmalarınıza entegre etmesini ve bir birleştirme taahhüdü oluşturmasını söyler .
Tarihin grafiği şimdi şöyle:

... o ---- o ---- A ---- B  origin/master (upstream work)
                   \      \
                    C ---- M  master (your work)

Yeni birleştirme olan M taahhüdü, her biri bu taahhütte depolanan içeriğe götüren bir geliştirme yolunu temsil eden iki ebeveyne sahiptir.

M'nin arkasındaki geçmişin artık doğrusal olmadığını unutmayın.

rebase

Git rebase komutunu kullanın:

$ git rebase origin/master

Bu, Git'e C komutunu (işinizi) A yerine B yerine
koyduğunuzu söyler. CVS ve Subversion kullanıcıları, taahhüt etmeden önce güncellendiklerinde, yukarı akıştaki işlerin üstünde yerel değişikliklerini rutin olarak yeniden oluştururlar.
Git, kesinleştirme ve yeniden pazarlama adımları arasında açık bir ayrım ekler.

Tarihin grafiği şimdi şöyle:

... o ---- o ---- A ---- B  origin/master (upstream work)
                          \
                           C'  master (your work)

C Komutu, git rebase komutu tarafından oluşturulan yeni bir komuttur.
C'den iki şekilde farklıdır:

1. Farklı bir tarihi var: A yerine B.
2. İçeriği hem B hem de C'deki değişiklikleri açıklar; birleştirme örneğindeki M ile aynıdır.

C 'nin arkasındaki tarihin hala doğrusal olduğunu unutmayın.
Şimdilik sadece doğrusal geçmişe izin vermeyi (şimdilik) seçtik cmake.org/cmake.git.
Bu yaklaşım, daha önce kullanılan CVS tabanlı iş akışını korur ve geçişi kolaylaştırabilir.
C 'yi depomuza itme girişimi işe yarayacaktır (izinleriniz olduğunu ve yeniden basarken hiç kimsenin itmediğini varsayarak).

Git pull komutu, başlangıç ​​noktasından getirme ve üzerinde yerel çalışmayı yeniden oluşturma için kısa bir yol sağlar:

$ git pull --rebase

Bu, yukarıdaki getirme ve yeniden oluşturma adımlarını tek bir komutta birleştirir.

Bunu aldım ve yukarıdaki yanıtları okuduktan sonra bile buna neyin sebep olduğu konusunda gizem duydum. Benim çözümüm

git reset --hard origin/master

Daha sonra bu sadece (yerel) master kopyamı (berbat olduğunu varsayıyorum) (uzak) orijin / master ile gösterildiği gibi doğru noktaya sıfırlar.

UYARI : Henüz zorlanmayan tüm değişiklikleri kaybedeceksiniz origin/master.

git pull --rebase origin/master 

size çoğu zaman yardımcı olabilecek tek bir komuttur.

Düzenleme: Taahhütleri başlangıç ​​/ ana konumdan alır ve değişikliklerinizi yeni çekilen dal geçmişine uygular.

Ben çalıştığında bu durumun içinde buldum rebase uzak dalı takip ettiğini bir şube ve ben efendi üzerine rebase çalışıyordu. Eğer rebase çalışırsanız bu senaryoda, büyük olasılıkla şube bulacaksınız ayrıldığı ve git nubees için değil bir karmaşa yaratabilir!

Diyelim ki ustadan dallanmış olan my_remote_tracking_branch şubesindesiniz

$ git status

# Dalda my_remote_tracking_branch

taahhüt edilecek hiçbir şey yok (çalışma dizini temiz)

Ve şimdi efendiden şu şekilde geri çekmeye çalışıyorsunuz:

git rebase ustası

ŞİMDİ DUR ve kendinize biraz sorundan kurtulun! Bunun yerine, birleştirmeyi şu şekilde kullanın:

git merge master

Evet, şubenizde ekstra taahhütlerle sonuçlanacaksınız. Ancak "ayrışmasız" dallara katılmıyorsanız, bu yeniden temellendirmekten çok daha akıcı bir iş akışı olacaktır. Çok daha ayrıntılı bir açıklama için bu bloga bakın .

Öte yandan, şubeniz sadece yerel bir şubeyse (yani henüz herhangi bir uzaktan kumandaya itilmemişse) kesinlikle bir rebase yapmalısınız (ve bu durumda şubeniz ayrılmayacaktır ).

Bu okuma Şimdi eğer zaten çünkü olan bir senaryo böyle rebase nedeniyle, geri son alabilirsiniz kullanarak (un-ayrıldığı halde yani) kökenden taahhüt "ayrıldığı" in:

git reset --hard origin / my_remote_tracking_branch

Benim durumumda, yönlendirilmiş mesaja neden olmak için yaptığım şey: Yaptımgit push ama sonra yaptımgit commit --amend taahhüt mesajına bir şey eklemek için . Sonra başka bir taahhütte bulundum.

Yani benim durumumda bu sadece orijin / üstatın güncel olmadığı anlamına geliyordu. Başka hiç kimsenin başlangıç ​​noktasına / efendisine dokunmadığını bildiğim için, düzeltme önemsizdi: git push -f ( -fkuvvet demek)

Benim durumumda değişiklikler yaptım origin/master ve sonra bunu yapmam gerektiğini fark etti :-( Bu, yerel değişikliklerin bir alt ağaçta olması nedeniyle karmaşıktı. değişiklikleri (SourceTree kullanarak) ve sonra "ıraksama mesajı" aldım.

Yerel olarak dağınıklığı düzelttikten sonra (ayrıntılar burada önemli değil) uzak origin/masterşubeye tekrar "geri gitmek" istedim, böylece yerel ile mastertekrar senkronize olacaktı . Benim durumumdaki çözüm:

git push origin master -f

Not -f(kuvvet) anahtarı. Bu origin/master, yanlışlıkla itilmiş olan "kötü değişiklikleri" sildi ve şimdi yerel ve uzak dallar senkronize durumda.

Bunun potansiyel olarak yıkıcı bir işlem olduğunu lütfen unutmayın, bu nedenle yalnızca uzak ana makinenin zamanında "geri taşındığından"% 100 emin olduğunuzda gerçekleştirin.

Burada çok sayıda cevap olduğunu biliyorum, ama bence git reset --soft HEAD~1bazı dikkatleri hak ediyor, çünkü ayrışmış durumu çözerken son yerel (itilmemiş) taahhütte değişiklikler yapmanıza izin veriyor . Bence bu, çekmekten daha çok yönlü bir çözüm rebase, çünkü yerel taahhüt gözden geçirilebilir ve hatta başka bir şubeye taşınabilir.

Anahtar --softsert yerine kullanmaktır --hard. 1'den fazla taahhüt varsa, bir varyasyon HEAD~xçalışmalıdır. İşte durumumu çözen tüm adımlar (uzaktan 1 tane yerel taahhüt ve 8 tane taahhütte bulundum):

1) git reset --soft HEAD~1 Yerel taahhüdü geri almak. Sonraki adımlar için SourceTree arabirimini kullandım, ancak aşağıdaki komutların da çalışması gerektiğini düşünüyorum:

2) git stash 1'den stash değişikliklerine). Artık tüm değişiklikler güvende ve artık bir farklılık yok.

3) git pull uzaktan değişiklikleri almak için.

4) git stash pop veya git stash applyistendiği takdirde yeni bir taahhüt takip eden son saklama değişikliklerini uygulamak. Bu adım, 2) ile birlikte yerel taahhütteki değişiklikleri çöpe atmak istediğinizde isteğe bağlıdır . Ayrıca, başka bir şubeye katılmak istediğinizde, bu adım istenen şubeye geçildikten sonra yapılmalıdır.

Farklılıkları görüntülemek için:

git difftool --dir-diff master origin/master

Bu, iki dal arasındaki değişiklikleri veya farklılıkları gösterecektir. Araxis'te (En sevdiğim) bir klasör farklı stilinde görüntüler. Değiştirilen dosyaların her biri gösteriliyor. Daha sonra dosyadaki değişikliklerin ayrıntılarını görmek için bir dosyaya tıklayabilirim.

Benim durumumda bu, çatışma çözümlememi yapmamamdan kaynaklandı.

Sorun, git pullkomutun çalıştırılması nedeniyle oluştu . Kökenimdeki değişiklikler, çözdüğüm yerel repo ile çatışmaya yol açtı. Ancak, onları taahhüt etmedim. Bu noktada çözüm, değişiklikleri uygulamaktır ( git commitçözülen dosya)

Çakışmayı git statusçözdüğünüzden beri bazı dosyaları değiştirdiyseniz, komut yerel değişiklikleri işaretsiz yerel değişiklikler olarak gösterir ve çözünürlüğü aşamalı yerel değişiklikler olarak gösterir. Bu, ilk önce birleştirme git commitişlemindeki değişiklikleri gerçekleştirerek, ardından normal olmayan değişiklikleri (örneğin git commit -a) ekleyerek ve gerçekleştirerek düzgün bir şekilde çözülebilir .

Zaten taahhüt itti, son taahhüt mesajı düzenlemeye çalışırken aynı mesajı vardı: git commit --amend -m "New message" kullanarak değişiklikleri itti zaman git push --force-with-lease repo_name branch_name hiçbir sorun yoktu.

A dalına dayalı bir dal oluşturduğumda bu sorunla karşılaştım.

git checkout -b a

ve sonra a dalının yukarı akışını B

git branch -u origin/B

Sonra yukarıdaki hata mesajını aldım.

Bu sorunu benim için çözmenin bir yolu,

• Şubeyi silme a
• Tarafından yeni bir şube oluşturun b

git checkout -b b origin/B