git master'dan geliştirme dalına çekin

495

Dmgr2 (geliştirme) adında bir şubem var ve ana daldan (canlı site) çekmek ve tüm değişiklikleri geliştirme şubemize dahil etmek istiyorum. Bunu yapmanın daha iyi bir yolu var mı? İşte değişiklikler yaptıktan sonra yapmayı planladığım şey:

git checkout dmgr2
git pull origin master

bu, canlı değişiklikleri geliştirme şubeme çekmeli mi yoksa bu yanlış mı var?

git branch pull

— Matthew Colley
kaynak

1

önce dmgr2 şubesindeki tüm değişikliklerinizi yapın. ve sonra master 1.git ödeme ustası üzerine gelin ve en son değişikliği alın 2.git çekme 3.git birleştirme dmgr2 4.git push -u orijin ustası Ve sonra dmgr2'ye dön 5.git checkout dmgr2

— mat_vee

Ben zaten dmgr2 şubesine tüm değişiklikleri taahhüt ettik, özür dilerim eklemeyi unuttum

— Matthew Colley

1

4. adımı gerçekleştirirsem, geliştirme değişikliklerimi ustaya itmeyecek mi? bunu yapmak istemiyorum

— Matthew Colley

Peki söylediğiniz şey, ana dalınızdaki değişiklikleri geliştirici dalınıza getirmek mi istiyorsunuz?

— JcKelley

9

İle devşubeye geçin git checkout dev. Sonra git pull --rebase origin master. Eğer şanslıysanız, çatışma olmayacak ve geliştiricinin en son değişiklikleri ustadan alacaktır.

— jww

724

Listelediğiniz adımlar işe yarar, ancak size daha fazla seçenek sunmanın daha uzun bir yolu vardır:

git checkout dmgr2      # gets you "on branch dmgr2"
git fetch origin        # gets you up to date with origin
git merge origin/master

fetchÖnce komut herhangi bir noktada yapılabilir merge, yani sen sırasını takas edebilir alıp nedeniyle çıkış, fetchsadece uzaktan adlandırılmış (gitse origin) ve ona der ki: "çak bir şeyi sen bende olmayan şey var ", yani, tüm dallarda taahhüt eder. Deponuza kopyalanırlar, ancak uzaktan kumandadaki origin/branchherhangi bir dal için adlandırılırlar branch.

Bu noktada git log, gitk"sahip olduklarını" görmek için herhangi bir görüntüleyiciyi ( , vb.) Kullanabilirsiniz . Bazen bu sadece Sıcak Bulanık Duygular için yararlıdır ("ah, evet, aslında istediğim budur") ve bazen stratejileri tamamen değiştirmek için yararlıdır ("whoa, henüz bu şeyleri istemiyorum").

Son olarak, mergekomut, adlandırabileceğiniz verilen taahhüdü origin/masteralır ve o taahhüdü ve atalarını getirmek için ne gerekiyorsa yaparsanız, çalıştırdığınızda hangi dalda olursanız olun merge. Bir hızlı ileri sarmayı ekleyebilir --no-ffveya --ff-onlyönlemek için veya isterseniz sonuç hızlı ileri sarılmışsa birleştirebilirsiniz.

Diziyi kullandığınızda:

git checkout dmgr2
git pull origin master

pullKomut talimatını çalıştırmak git'e git fetchve daha sonra ahlaki eşdeğer git merge origin/master. Dolayısıyla bu, iki adımı elle yapmakla neredeyse aynıdır, ancak muhtemelen sizinle ilgili olmayan bazı ince farklılıklar vardır. (Özellikle fetchadım koşmak pullgetiriyor sadece origin/master ve senin repo ref güncelleme değildir: ¹ herhangi bir yeni onaylatabilirsiniz rüzgarlar sevk-sadece özel tarafından FETCH_HEAD. Referansı)

Daha açık git fetch origin(daha sonra isteğe bağlı olarak etrafa bakın) ve ardından git merge origin/mastersıra kullanırsanız, masteruzaktan kumandayla kendi yerel fetchağınızı da güncelleyebilirsiniz ve ağda yalnızca bir tane çalışır:

git fetch origin
git checkout master
git merge --ff-only origin/master
git checkout dmgr2
git merge --no-ff origin/master

Örneğin.

¹ Bu ikinci bölüm değiştirildi - "sabit" diyorum - git 1.8.4'te artık "uzak dal" referanslarını fırsatçı olarak güncelliyor. (Sürüm notlarında belirtildiği gibi, güncellemeyi atlamak için kasıtlı bir tasarım kararıydı, ancak daha fazla kişinin git güncellemesini tercih ettiği ortaya çıktı. Eski uzak dal SHA-1'i istiyorsanız, varsayılan olarak kaydediliyor ve bu da geri dönüşlüdür, bu da yukarı akış referanslarını bulmak için yeni bir git 1.9 / 2.0 özelliği sağlar.)

— torek
kaynak

28

Ben sadece bir, ah, arkadaş - ben burada (kod / getir / birleştirme) sahip ilk kod bloğunu geri almak hakkında gitmek istiyorum?

— Zengin Bradshaw

10

@RichBradshaw: git checkoutnormalde tahribatsızdır ve normalde a'yı geri git fetchalmanın bir nedeni yoktur , bu yüzden birleştirme taahhüdünü nasıl geri çevireceğinizi soruyorsunuz. Cevap diğer taahhütlerle aynıdır: ya git resetya git revert. İçin yayınlanmamış değişiklikler git resetgenellikle en iyi yöntemdir; başkalarının zaten sahip olduğu değişiklikler git revertiçin daha iyi olabilir, ancak Linus

— Torvald'un

2

@WeDoTDD: Soruyu anlamıyorum. Orada izlemek için komutların bir sayı (grafik işlemek vardır gitk, git log --grapholan veya olmayan --oneline, vs.) ve mümkün git showveya git show -mbir birleştirme işlemek veya kullanım git diff. Tüm bu durumlarda, komutu komut satırına girerken programı belirtirsiniz.

— torek

1

@torek: yolunu denedi: git çıkış şubesi ve sonra git çekme kökeni yöneticisi, ancak tüm ana değişiklikleri, taahhüt geçmişleri ve mesajları ile çekmek yerine, tekrar yerel olarak yapılması gereken tek bir değişiklik olarak çekti. master ve şubeye geçiş, "git rebase master" çözmek için tüm çatışmalar ile işi yapar, ve sonra ben "git pull --rebase" eklemek ve tekrar tüm çakışmaları ele, ve sonra git hizalanmış şube tüm hizalanmış almak için itmek. Sanırım bunun için daha iyi bir yol olmalı - haklı mıyım?

— user10556443

1

@torek: Elde ettiğim sonucun beni tekrar tekrar rebase & merge & ... ile başa çıkmaya zorlayan yorucu bir süreç olduğuna katılıyorum ... ... her ustadan bir güncelleme almak istediğimde ... Ama itiraf ettiğim önerilen yol çok daha kolay, ana taahhüt emri / tarih tutmadan yerel şubede tüm değişiklikleri tek bir taahhüt altında değiştirdi. Ben "çekme" kullanmak için daha iyi öneri öğrenmek ve "çekme" vb kullanmak gerek kalmadan ustası takip etmek için

— mutluluk duyacağım

14

Durum : Yerel şubemde çalışıyorum, ancak adlı geliştirme dalında güncellemeleri takip etmeyi çok seviyorum dev.

Çözüm : Genellikle şunu yapmayı tercih ederim:

git fetch
git rebase origin/dev

— greenridinghood
kaynak

15

Her zamanki feragatname ile, rebase sadece yerel şube sadece yerel ise, yani tarihi yeniden yazdığı için herhangi bir yere itilmemişse yapılmalıdır.

— Locus

8

Bu benim için çalıştı. Master'dan şubeme en son kodu almak için

git rebase origin/master

— Pratik Gaurav
kaynak

git fetch originÖnce unutma .

— lenooh

3

Senaryo :

Ana güncelleme ve şube güncellemem var, şubemin yeniden basma ile ustayı takip etmesini istiyorum, tüm geçmişi düzgün bir şekilde takip etmek için şubeme Mybranch diyelim

Çözüm :

git checkout master    
git pull --rebase    
git checkout Mybranch    
git rebase master
git push -f origin Mybranch

Git mergetool &, git rebase --continue, git rebase --skip, git add -u, durum ve git ipuçlarına göre tüm sorunları çözülene kadar çözmeniz gerekir

("-f" kullanarak Tzachi Cohen'in izniyle son aşamaya düzeltme sunucudaki "güncelleme geçmişine" gitmeye zorlar)

şimdi şube master ile hizalanmış ve uzaktan da güncellenmiş, aynı zamanda git günlüğünde hiçbir "arkasında" veya "önde", sadece klasör "temiz" tutmak için tüm yerel çatışma * .orig dosyaları kaldırmak gerekir

— user10556443
kaynak