13 Soru: En son taahhütleri Git ile yeni bir şubeye taşıyın

tarafından oluşturulan soru Thu, Dec 21, 2017 12:00 AM

Yeni bir dalda uzman olmak için taahhüt ettiğim son birkaç komisyonu taşımak ve bu komisyonlar yapılmadan önce master'ı geri almak istiyorum. Maalesef Git-fu'm henüz yeterince güçlü değil, herhangi bir yardıma mı ihtiyacınız var?

yani. Bundan nasıl gidebilirim

 
master A - B - C - D - E

buna?

 
newbranch     C - D - E
             /
master A - B 
    
4339
  1. Not: Karşıdaki soruyu burada
    2010-12-16 08: 56: 06Z
  2. eddmann.com/posts/… bu işe yarıyor
    2017-04-25 06: 35: 42Z
  3. Buradaki yorumlar temizlendi mi? Soruyorum, çünkü bu soruyu iki ayda bir ziyaretim sırasında her zaman bu yorumu gözden geçiriyorum.
    2018-03-19 14: 02: 40Z
13 Yanıtlar                              13                         

Yeni bir şubeye taşınmak

UYARI: Bu yöntem çalışır, çünkü ilk komutla yeni bir şube oluşturuyorsunuz: git branch newbranch. Taahhütleri bir mevcut şubeye taşımak istiyorsanız , git reset --hard HEAD~3’u uygulamadan önce değişikliklerinizi mevcut şubeyle birleştirmeniz gerekir (bkz. Mevcut bir şubeye taşınması aşağıda). Önce değişikliklerinizi birleştirmezseniz, kaybedileceklerdir.

İlgili diğer koşullar olmadıkça, bu dallanma ve geri dönme yoluyla kolayca yapılabilir.

 
# Note: Any changes not committed will be lost.
git branch newbranch      # Create a new branch, saving the desired commits
git reset --hard HEAD~3   # Move master back by 3 commits (Make sure you know how many commits you need to go back)
git checkout newbranch    # Go to the new branch that still has the desired commits

Ama kaç tanesinin geri döneceğini taahhüt et. Alternatif olarak, HEAD~3 yerine, yalnızca usta 'da "geri dönmek" istediğiniz işlemin (veya orijin /usta gibi) özniteliğini belirtebilirsiniz. /Geçerli) Şubesi, örneğin:

 
git reset --hard a1b2c3d4

* 1 Ana daldaki taahhütleri "yalnızca kaybedeceksiniz" olacak, ancak endişelenmeyin, bu taahhütleri newbranch'ta olacaksınız!

UYARI: Git sürüm 2.0 ve sonraki sürümlerinde, daha sonra orijinal (git rebase) dalına yeni dalın masterunu yaparsanız, yeniden yapılanma sırasında taşınmamayı kaybetmemek için açık bir --no-fork-point seçeneğine ihtiyacınız olabilir. fazla taahhüt eder. branch.autosetuprebase always sete sahip olmak bunu daha olası kılıyor. Ayrıntılar için John Mellor’un cevabı bölümüne bakın.

Mevcut bir şubeye taşınmak

Taahhütlerinizi mevcut bir şubeye taşımak istiyorsanız, şöyle görünecektir:

 
git checkout existingbranch
git merge master
git checkout master
git reset --hard HEAD~3 # Go back 3 commits. You *will* lose uncommitted work.
git checkout existingbranch
    
5518
2019-06-26 12: 09: 49Z
  1. Ve özellikle, yapma , en son başka bir depoya gönderdiğiniz noktadan daha ileri gitmeye çalışın çekti.
    2009-10-27 03: 23: 50Z
  2. NEDEN işe yarayıp yaramadığını merak ediyorum. Bana göre, yeni bir şube oluşturuyorsunuz, halen devam etmekte olduğunuz eski şubenizdeki 3 komisyonu kaldırıyor ve ardından yaptığınız şubeyi inceliyorsunuz. Peki, sihirli bir şekilde kaldırdığın taahhütler yeni şubede nasıl ortaya çıkıyor?
    2010-08-03 18: 28: 13Z
  3. @ Jonathan Dumaine: Çünkü yeni şubeyi eski şubeden kaldırmadan önce oluşturdum. Hala yeni şubede varlar.
    2010-08-04 08: 28: 04Z
  4. git'teki şubeler, yalnızca tarihte taahhütte bulunan işaretçilerdir, klonlanan, oluşturulan veya silinen hiçbir şey yoktur (işaretçiler hariç)
    2010-08-16 11: 32: 12Z
  5. Ayrıca not: Bunu çalışma kopyanızdaki onaylanmamış değişikliklerle yapmayın! Bu sadece beni ısırdı! :(
    2011-10-25 03: 59: 38Z

Neden çalıştığını merak edenler için (ilk başta olduğum gibi):

C'ye geri dönmek ve D ve E'yi yeni şubeye taşımak istiyorsunuz. İşte ilk bakışta göründüğü gibi:

 
A-B-C-D-E (HEAD)
        ↑
      master

git branch newBranch’dan sonra:

 
    newBranch
        ↓
A-B-C-D-E (HEAD)
        ↑
      master

git reset --hard HEAD~2’dan sonra:

 
    newBranch
        ↓
A-B-C-D-E (HEAD)
    ↑
  master

Bir dal sadece bir işaretçi olduğundan, usta son taahhüdüne işaret etti. newBranch 'ı yaptığınızda, son işlemi yapmak için yeni bir işaretçi yaptınız. Ardından git reset'u kullanarak master işaretçisini iki işlem geri getirdiniz. Ancak, newBranch öğesini hareket ettirmediğinizden, hala orijinal olarak yaptığı taahhüdü işaret ediyor.

    
935
2015-12-31 00: 29: 20Z
  1. Değişikliğin ana depoda gösterilmesi için git push origin master --force da yapmam gerekiyordu.
    2014-11-26 19: 20: 10Z
  2. Bu cevap, taahhütlerin kaybedilmesine neden olur: Bir dahaki sefer git rebase’da, 3 taahhüt newbranch’dan sessizce atılır. Ayrıntılar ve daha güvenli alternatifler için cevabım bölümüne bakın.
    2016-04-06 22: 47: 36Z
  3. @ John, bu saçmalık. Ne yaptığınızı bilmeden yeniden doğmak, taahhütlerin kaybolmasına neden olur. Eğer taahhütlerini kaybettiyseniz, sizin için üzgünüm, fakat bu cevap taahhütlerinizi kaybetmedi. origin/master'un yukarıdaki diyagramda görünmediğine dikkat edin. origin/master'a kadar ittiyseniz ve yukarıdaki değişiklikleri yaptıysanız, elbette, işler komikleşirdi. Ama bu bir "Doktor, bunu yaptığım zaman acıtıyor" gibi bir problem. Ve asıl sorunun sorduğu şeyin kapsamı dışında. Bu konuyu kaçırmak yerine senaryoyu keşfetmek için kendi sorunuzu yazmanızı öneririz.
    2016-04-07 03: 20: 31Z
  4. @ John, cevabınızda "Bunu yapma! git branch -t newbranch" dedin. Geri dön ve cevapları tekrar oku. Kimse bunu yapmayı önermedi.
    2016-04-07 15: 02: 55Z
  5. @ Kyralessa, elbette, ancak sorudaki şemaya bakarsanız, newbranch’un mevcut yerel master şubesini temel almasını istedikleri açıktır. Kabul edilen cevabı yaptıktan sonra, kullanıcı git rebase'da newbranch'u çalıştırmaya başladığında, git onlara yukarı akış dalını ayarlamayı unuttuklarını hatırlatır, böylece git branch --set-upstream-to=master'u ve git rebase'u çalıştırırlar ve aynı problemi yaşarlar. İlk etapta git branch -t newbranch'u da kullanabilirler.
    2016-04-07 15: 32: 55Z

Genel Olarak ...

Bu durumda sykora tarafından maruz bırakılan yöntem en iyi seçenektir. Ancak bazen en kolay değildir ve genel bir yöntem değildir. Genel bir yöntem için git cherry-pick kullanın:

OP'nin istediğini elde etmek için, 2 aşamalı bir süreç:

Adım 1 - newbranch'da istediğiniz master'den hangisinin geldiğini not edin

Yürütme

 
git checkout master
git log

newbranch'da istediğinizi (3. Burada kullanacağım:
C taahhüt: 9aa1233
D taahhüt: 453ac3d
E taahhüt: 612ecb3

  

Not: İlk yedi karakteri kullanabilirsiniz veya   tüm taahhüt karma

Adım 2 - Onları newbranch'a yerleştirin

 
git checkout newbranch
git cherry-pick 612ecb3
git cherry-pick 453ac3d
git cherry-pick 9aa1233

VEYA (Git 1.7.2+ sürümünde, aralıkları kullanın)

 
git checkout newbranch
git cherry-pick 612ecb3~1..9aa1233

git cherry-pick bu üç görevi newbranch'a uygular.

    
392
2018-02-28 18: 13: 52Z
  1. OP, usta 'den newbranch’e taşınmaya çalışmadı mı? Eğer usta iken kiraz toplarsanız, ana şubeye ekliyor olursunuz -Aslında zaten vardı. Ve her iki dal başını da B'ye geri götürmez ya da alamadığım ince ve havalı bir şey var mı?
    2012-07-06 02: 48: 27Z
  2. Bu, yanlışlıkla yeni bir özellik dalı oluşturmanız gerektiğinde, ana ana olmayan dalı yanlış bir şekilde işlediğinizde çok işe yarar.
    2014-02-27 16: 47: 42Z
  3. Bazı durumlarda yararlı bir yaklaşım için
    + 1. Bu, yalnızca kendi taahhütlerinizi (diğerleri ile serpiştirilmiş olan) yeni bir şubeye çekmek istiyorsanız iyidir.
    2014-10-01 17: 11: 06Z
  4. Daha iyi bir cevap. Bu şekilde, taahhütleri herhangi bir şubeye taşıyabilirsiniz.
    2014-11-05 08: 32: 09Z
  5. Vişne toplamanın sırası önemli mi?
    2015-04-23 22: 04: 40Z

Bunu yapmanın başka bir yolu, sadece 2 komut kullanarak. Ayrıca mevcut çalışma ağacınızı sağlam tutar.

 
git checkout -b newbranch # switch to a new branch
git branch -f master HEAD~3 # make master point to some older commit

Eski sürüm - yaklaşık git branch -f öğrenmeden önce

 
git checkout -b newbranch # switch to a new branch
git push . +HEAD~3:master # make master point to some older commit 

push - . arası numaraya sahip olmak bilmek güzel bir numaradır.     

288
2018-06-21 14: 17: 32Z
  1. Geçerli dizin. Sanırım bu sadece bir üst dizinde olmanız durumunda işe yarar.
    2014-03-28 05: 35: 03Z
  2. Yerel itme sırıtış yaratıyor, ancak yansıma üzerine, burada git branch -f'dan farklı olan nedir?
    2014-08-05 00: 15: 40Z
  3. @ GerardSexton . şu anki yönetmenidir. git, UZAKTAN veya GİT URL’lerine basabilir. path to local directory Git URL'lerin sözdizimini desteklemektedir. git help clone'daki GIT URLS bölümüne bakın.
    2014-11-25 10: 24: 20Z
  4. Bunun neden daha yüksek derecelendirilmediğini bilmiyorum. Ölü basit, ve küçük ama potansiyel git sıfırlanma tehlikesi olmadan - sert.
    2015-02-06 14: 56: 24Z
  5. @ Godsmith Benim tahminim, insanlar iki basit komut için iki basit komutu tercih ediyorlar. Ayrıca, en çok oy alan cevaplar, ilk önce gösterilme niteliğine göre daha fazla puan alır.
    2015-10-22 15: 43: 45Z

Önceki cevapların çoğu tehlikeli bir şekilde yanlıştır!

Bunu yapma:

 
git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch

Bir dahaki sefere git rebase (veya git pull --rebase) çalıştırdığınızda, bu 3 komisyon sessizce newbranch'dan atılacak! (aşağıdaki açıklamaya bakın)

Bunun yerine:

 
git reset --keep HEAD~3
git checkout -t -b newbranch
git cherry-pick ..HEAD@{2}
  • İlk önce en son 3 taahhüdü atar (--keep, --hard gibidir, ancak taahhüt edilmemiş değişiklikleri atmak yerine başarısız olur).
  • Sonra newbranch'a izin verir.
  • Sonra bu 3 kişiyi newbranch'a iade eder. Artık bir dal tarafından başvuruda bulunmadıkları için git'in reflog : HEAD@{2}, HEAD’un 2 işlemden önce atıfta bulunduğunu, yani biz newbranch’u, 2’yi de teslim etmeden önce, git reset’u 3 komisyonu atmak için kullandığını taahhüt eder.

Uyarı: reflog varsayılan olarak etkindir, ancak manuel olarak devre dışı bıraktıysanız (örn. "çıplak" bir git deposu kullanarak), git reset --keep HEAD~3'u çalıştırdıktan sonra 3 komisyonu geri alamazsınız. .

Reflog'a dayanmayan bir alternatif:

 
# newbranch will omit the 3 most recent commits.
git checkout -b newbranch HEAD~3
git branch --set-upstream-to=oldbranch
# Cherry-picks the extra commits from oldbranch.
git cherry-pick ..oldbranch
# Discards the 3 most recent commits from oldbranch.
git branch --force oldbranch oldbranch~3

(eğer tercih ederseniz @{-1} yerine oldbranch yazabilirsiniz - git rebase yazabilirsiniz)


Teknik açıklama

Neden git rebase, ilk örnekten sonra gelen 3 sözleşmeyi atıyor? benÇünkü, argümanları olmayan --fork-point, varsayılan olarak

M1--M2--M3  <-- origin/master
         \
          T1--T2--T3  <-- topic
seçeneğini etkinleştirir; bu, yerel reflog'u zorlanan yukarı akış dalına karşı sağlam olmaya çalışmak için kullanır.

M1, M2, M3 görevlerini üstlendiğinde kökeni /ana bilgiyi dalladığınızı ve ardından üç görev üstlendiğinizi varsayalım:

 
M1--M3'  <-- origin/master
 \
  M2--M3--T1--T2--T3  <-- topic

ancak daha sonra birisi, M2'yi kaldırmak için kökeni /yönetici zorla iterek geçmişi yeniden yazar:

 git rebase

Yerel reflogunuzu kullanarak,

M1--M3'  <-- origin/master
     \
      T1'--T2'--T3'  <-- topic (rebased)
, menşe /ana dalın daha önceki bir enkarnasyonundan ayrıldığınızı görebilir ve bu nedenle M2 ve M3'ün taahhüt ettiği konunun gerçekten bir parçası olmadığını görür. Bu nedenle, M2'nin yukarı akış dalından kaldırılmasından bu yana, konu dalının yeniden doğuşundan sonra artık konu dalınızda olmasını istemediğinizi varsayalım:  
git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch

Bu davranış mantıklıdır ve genellikle yeniden yapılanma sırasında yapılacak en doğru şeydir.

Bu nedenle aşağıdaki komutların başarısız olmasının nedeni:

 newbranch

, reflog'u yanlış durumda bıraktıkları için. Git, reset --hard'u, 3 komisyonu içeren bir revizyonda yukarı akış dalından çatallanmış olarak görüyor, sonra git rebase, yukarı yönde hareketin taahhütleri kaldırmak için tarihçesini yeniden yazıyor ve bir dahaki sefer --fork-point'u çalıştırdığınızda, onlardan kaldırılan diğer tüm taahhütler gibi onları atıyor. giriş yönü.

Ancak bu özel durumda, bu 3 taahhüdün konu dalının bir parçası olarak değerlendirilmesini istiyoruz. Bunu başarabilmek için, 3 taahhüdü içermeyen önceki revizyonda yukarı havayı doldurmamız gerekiyor. Bu benim önerdiğim çözümlerin yaptığı şey, bu yüzden ikisi de reflog'u doğru durumda bırakıyor.

Daha fazla ayrıntı için git rebase ve git birleştirme tabanı dokümanları.

    
265
2016-09-16 01: 34: 57Z
  1. Bu cevap "Bunu yapma!" kimsenin yapmayı önermediği bir şeyin üstünde.
    2016-04-16 21: 41: 32Z
  2. Çoğu insan, özellikle -t'da yayınlanan geçmişi yeniden yazmaz. Yani hayır, tehlikeli bir şekilde yanlış değiller.
    2016-09-14 06: 59: 48Z
  3. @ Kyralessa, git branch’da atıfta bulunduğunuz git config --global branch.autosetuprebase always, master’unuz varsa, dolaylı olarak gerçekleşir. Yapmasanız bile, ben zaten açıkladı , bu komutları uyguladıktan sonra izlemeyi ayarlarsanız, OP'nin muhtemelen sorduğu gibi yapmayı planladığı gibi, size aynı sorunun ortaya çıktığını söyledi.
    2016-09-16 02: 36: 03Z
  4. @ RockLee, evet, genel olarak, bu gibi durumları düzeltmenin yolu, güvenli bir başlangıç ​​noktasından yeni bir dal (newbranch2) oluşturmak ve ardından tüm siparişleri kirazdan almaktır. (badnewbranch'ten newbranch2'ye kadar) saklamak istiyorum. Cherry-picking, komisyonlara yeni hasheler verecek, böylece newbranch2'yi (ve şimdi badnewbranch'i silebilirsiniz) güvenle yeniden kurabilirsiniz.
    2016-09-16 02: 36: 53Z
  5. @ Walf, yanlış anladınız: git rebase , tarihlerini yeniden yazılan yukarı akışlara karşı sağlam olacak şekilde tasarlanmıştır. Ne yazık ki, bu sağlamlığın yan etkileri, ne onlar ne de yukarı akımları tarihlerini yeniden yazsalar bile, herkesi etkiliyor.
    2016-09-16 02: 37: 33Z

git stash kullanarak çok daha basit bir çözüm

Öyleyse, aşağıdakiler çok daha basittir (üç hatalı taahhütte bulunan

git reset HEAD~3
git stash
git checkout newbranch
git stash pop
şubesinden başlayarak):  master

Bunu ne zaman kullanmalı?

  • Öncelikli amacınız master'u geri almaksa
  • Dosya değişikliklerini saklamak istiyorsunuz
  • Yanlış taahhütlerdeki mesajları umursamıyorsun
  • Henüz itmedin
  • Bunun ezberlemesinin kolay olmasını istiyorsun
  • Geçici /yeni dallar, taahhüt karmaları ve diğer baş ağrıları bulmak ve kopyalamak gibi komplikasyonlar istemiyorsunuz

Bu, satır numarasına göre ne yapar?

  1. Son üç taahhüdü geri alır (ve mesajlarını)master’a kadar tüm çalışma dosyalarını sağlam bırakır
  2. newbranch çalışma ağacının tam olarak HEAD ~ 3 durumuna eşit olmasını sağlayarak, tüm çalışma dosyalarındaki değişiklikleri saklar.
  3. Mevcut bir şubeye geçer git add
  4. Statshed değişiklikleri çalışma dizininize uygular ve boşluğu temizler

Artık normalde yaptığınız gibi git commit ve newbranch'u kullanabilirsiniz. Tüm yeni taahhütler master'a eklenecek.

Bunun ne işe yaramadığını

  • Rastgele geçici dalları ağacınızı yığma olarak bırakmaz
  • Hatalı taahhütleri ve taahhüt mesajlarını korumaz, bu nedenle bu yeni işleme, yeni bir taahhüt mesajı eklemeniz gerekir

Hedefler

OP, hedefin değişiklikleri kaybetmeden "bu taahhütler yapılmadan önce ustayı geri almak" olduğunu belirtti ve bu çözüm bunu yaptı.

Bunu en az haftada bir kez, develop yerine git reset HEAD^'a yanlışlıkla yeni taahhütler verdiğimde yapıyorum. Genellikle, yalnızca bir işleme geri dönme taahhüdüm vardır; bu durumda, 1. satırda

A--B--C  (branch-foo)
 \    ^-- I wanted them here!
  \
   D--E--F--G  (branch-bar)
      ^--^--^-- Opps wrong branch!

While on branch-bar:
$ git reset --hard D # remember the SHAs for E, F, G (or E and G for a range)

A--B--C  (branch-foo)
 \
  \
   D-(E--F--G) detached
   ^-- (branch-bar)

Switch to branch-foo
$ git cherry-pick E..G

A--B--C--E'--F'--G' (branch-foo)
 \   E--F--G detached (This can be ignored)
  \ /
   D--H--I (branch-bar)

Now you won't need to worry about the detached branch because it is basically
like they are in the trash can waiting for the day it gets garbage collected.
Eventually some time in the far future it will look like:

A--B--C--E'--F'--G'--L--M--N--... (branch-foo)
 \
  \
   D--H--I--J--K--.... (branch-bar)
kullanmak, yalnızca bir işlem geri alma işleminin daha basit bir yoludur.

Master'ın değişikliklerini yukarı doğru ittiyseniz, bunu yapma

Bu değişiklikleri başka biri yapmış olabilir. Yerel yöneticinizi yalnızca yeniden yazarsanız, yukarı doğru basıldığında etkisi olmaz, ancak yeniden yazılmış bir tarihi ortak çalışanlara zorlamak baş ağrısına neden olabilir.

    
65
2019-06-02 01: 19: 24Z
  1. Teşekkürler, buraya gelmek için çok /geçmişe okuduğuma sevindim, çünkü benim için de oldukça yaygın bir kullanım örneği. Çok atipik miyiz?
    2018-09-10 17: 58: 03Z
  2. Tamamen tipik olduğumuzu düşünüyorum ve "yanlışlıkla ustalıkla görevlendirdiğim görevliler" bir avuç veya daha az sayıda emir geri döndürme ihtiyacı için en yaygın kullanım durumudur. Ne yazık ki bu çözüm çok basit, şimdi ezberledim.
    2018-09-11 19: 58: 01Z
  3. Bu kabul edilen cevap olmalıdır. Anlaşılır, anlaşılması kolay ve hatırlanması kolay
    2018-11-28 00: 53: 58Z
  4. Bir çözüm olabilir, ancak son 3 görevi kaybettiği için tam olarak ne istendiğini yapmaz.
    2019-06-24 16: 17: 55Z

Bu, teknik anlamda onları "hareket ettirmez" ancak aynı etkiye sahiptir:

 rebase     
29
2014-08-17 10: 23: 48Z
  1. rebase'u aynı şey için kullanamaz mısınız?
    2015-06-29 17: 37: 49Z
  2. Evet, yukarıdaki senaryoda müstakil şubede alternatif olarak
    git checkout master
    git revert <commitID(s)>
    git checkout -b new-branch
    git cherry-pick <commitID(s)>
    
    kullanabilirsiniz.
    2015-06-30 01: 32: 12Z

Bunu, geçmişi yeniden yazmadan yapmak için (yani, daha önce komisyonları ittiyseniz):

 
Branch one: A B C D E F     J   L M  
                       \ (Merge)
Branch two:             G I   K     N

Her iki dal da zorla itilebilir!

    
23
2016-01-21 16: 10: 36Z
  1. Ancak, durumunuza bağlı olarak daha zorlayıcı olan geri döndürme senaryosuyla ilgilenmelisiniz. Şube üzerindeki bir taahhüdünüzü geri alırsanız Git, bu taahhütleri gerçekleştiğini görmeye devam eder, bu nedenle geri almak için geri döndürmeniz gerekir. Bu, özellikle birkaç kişiyi yakıyor, özellikle bir birleşme dönemine dönüp şubeyi birleştirmeye çalıştıklarında, yalnızca Git'in zaten o şubeyle birleştiğine inandığını bulmak için (tamamen doğru).
    2016-04-07 16: 15: 37Z
  2. Bu yüzden komisyonları sonunda yeni bir şubeye ayıracağım. Bu şekilde git onları yeni bir taahhüt olarak görüyor ve bu da sorununuzu çözüyor.
    2016-04-07 17: 18: 57Z
  3. Bu, ilk bakışta göründüğünden daha tehlikelidir, çünkü bu durumun etkilerini anlamadan depo geçmişinin durumunu değiştiriyorsunuz.
    2016-04-07 19: 25: 22Z
  4. Argümanınıza uymuyorum - bu cevabın amacı, tarihi değiştirmemeniz, sadece yeni taahhütler eklemenizdir (bu, değişiklikleri etkili bir şekilde geri al) . Bu yeni taahhütler normal şekilde kullanılabilir ve birleştirilebilir.
    2016-04-08 10: 33: 01Z

Tam da bu durum vardı:

 
git branch newbranch 
git reset --hard HEAD~8 
git checkout newbranch

Ben yaptım:

 
git branch newbranch 
git reset --hard #########
git checkout newbranch

Bu taahhüdün HEAD olacağımı umuyordum, ancak L taahhüdü şimdi oldu ...

Tarihte doğru yere indiğinizden emin olmak için taahhüdün karmaşasıyla çalışmak daha kolaydır

 
git checkout -b new_branch
    
13
2013-09-20 10: 17: 35Z

1) Tüm değişikliklerinizi new_branch'e taşıyan yeni bir şube oluşturun.

 
git checkout master

2) Sonra eski şubeye dönün.

 
git rebase -i <short-hash-of-B-commit>

3) Git rebase yap

 
...
pick <C's hash> C
pick <D's hash> D
pick <E's hash> E
...

4) Ardından açılan düzenleyici son 3 taahhüt bilgisini içerir.

 pick

5) Tüm bu 3 sözleşmede drop ile

...
drop <C's hash> C
drop <D's hash> D
drop <E's hash> E
...
arasında bir değişiklik yapın. Sonra editörü kaydedin ve kapatın.  master

6) Şimdi son 3 taahhüt geçerli şubeden kaldırıldı (+). Şimdi şubeye zorla basın, şube adından önce

git push origin +master
işaretiyle.  
A - B - C - D - E 
                |
                master
    
2
2018-06-01 05: 40: 11Z

Bundan nasıl gidebilirim

 
A - B - C - D - E 
    |           |
    master      newbranch

buna?

 
A - B - C - D - E 
                |
                newbranch

İki komutla

  • git şube -m ana newbranch

veren

 
A - B - C - D - E
    |           |
    master      newbranch

ve

  • git şube yöneticisi B

veren

 git branch <branch name>     
1
2019-05-16 12: 00: 50Z
  1. Evet, bu işe yarar ve oldukça kolaydır. Sourcetree GUI, git kabuğunda yapılan değişikliklerle ilgili biraz karışıktır, ancak bir alımdan sonra yine tamamdır.
    2019-05-24 15: 05: 48Z

Bunu yapabilirim, kullandığım sadece 3 basit adım.

1) size en son güncellemeyi taahhüt etmek istediğiniz yerde yeni şube oluşturun.

git log

2) Yeni şubede taahhütte bulunmak için En Son Taahhüt Kimliğini bulun.

git cherry-pick d34bcef232f6c...

3) En son yapılanlar listesinin en üstte yer aldığını belirten kimlik notunu kopyala Böylece taahhüdünüzü bulabilirsiniz. Bunu ayrıca mesajla da bulabilirsiniz.

git cherry-pick d34bcef...86d2aec

ayrıca bir miktar taahhüt kimliği de sağlayabilirsiniz.

git push

Şimdi işiniz bitti. Doğru kimliği ve doğru dalı seçtiyseniz başarılı olursunuz. Yani bunu yapmadan önce dikkatli ol. başka bir sorun ortaya çıkabilir.

Artık kodunuzu girebilirsiniz

git branch new-branch-name

    
0
2018-05-25 14: 14: 27Z

Yalnızca gönderilmemiş taahhütlerinizin bir yeni şubeye taşınması gerekiyorsa, o zaman sadece,

  1. yeni bir şube oluşturun bir geçerli olandan: git push origin new-branch-name

  2. yeni şubenizi itin : git reset --hard origin/old-branch-name

  3. eski (geçerli) şubenizi sonlandırılmış /kararlı duruma getirin : upstreams

Bazı insanların origin yerine upstream’u vardır. uygun kullanmalılar

    
0
2019-06-17 07: 38: 10Z
kaynak yerleştirildi İşte