40 Soru: 'Git pull' ve 'git fetch' arasındaki fark nedir?

tarafından oluşturulan soru Sat, Nov 3, 2018 12:00 AM
  

Moderatör Not: Bu sorunun zaten altmış yedi yanıtı gönderildiği için (bazıları silinmiş), siz olup olmadığınızı düşünün bir tane daha göndermeden önce yeni bir şeye katkıda bulunun .

git pull ve git fetch arasındaki farklar nelerdir?

    
11047
  1. Git getirme ve gitme hakkında bu iyi yazılmış makaleyi okumaya değer buldum: longair.net/blog/2009/04/16/git-fetch-and-merge
    2010-09-16 06: 57: 47Z
  2. Alternatif yaklaşımımız iş akışımızın bir parçası olarak git fetch; git reset --hard origin/master oldu. Yerel değişiklikleri havaya uçurur, sizi usta BUT ile güncel tutar, ancak mevcut değişikliklerde sadece yeni değişiklikler yapmamanızı ve karışıklık çıkarmanızı sağlar. Bir süredir kullandık ve pratikte daha emniyetli hissediyor. İlk önce devam etmekte olan herhangi bir çalışmayı eklediğiniz /taahhüt ettiğiniz /sakladığınızdan emin olun!
    2014-05-04 14: 32: 18Z
  3. Git stash'ın nasıl doğru kullanılacağını bildiğinizden emin olun. 'Çek' ve 'getir' hakkında sorularınız varsa belki 'stash' da açıklamaya ihtiyaç duyacak ...
    2014-12-09 20: 09: 04Z
  4. Mercurial'dan gelen birçok insan "hg pull" için eşdeğer olduğunu düşünerek "git pull" kullanmaya devam ediyor. Hangisi değil. Git'in "hg pull" eşdeğeri "git fetch" dir.
    2015-06-29 10: 15: 53Z
  5. git fetch komutu dalda güncellenmiş kodu alıyor ve ayrıca yerel olarak yeni eklenen dallar alacak, git pull komutu sadece güncel şubenin güncellenmiş kodunu getir
    2017-07-27 11: 43: 31Z
30 Yanıtlar                              30                         

En basit ifadeyle, git pull, git fetch’u ardından git merge’u yapar.

Uzaktan izleme şubelerinizi git fetch'un altında güncellemek için istediğiniz zaman refs/remotes/<remote>/ yapabilirsiniz.

Bu işlem hiçbir zaman refs/heads’un altındaki hiçbir yerel şubenizi değiştirmez ve çalışma kopyanızı değiştirmeden yapmak güvenlidir. Arka planda bir cron işinde periyodik olarak git fetch çalışan insanların bile duydum (bunu yapmamı önermememe rağmen).

git pull, uzaktaki bir sürümüyle yerel bir şubeyi güncellemek ve aynı zamanda diğer uzaktan takip eden şubelerinizi güncellemek için ne yaparsınız?

Git belgeleri - git çekme :

  

Varsayılan modunda, git pull, git fetch ve ardından git merge FETCH_HEAD için kısa yoldur.

    
9187
2019-05-02 18: 52: 15Z
  1. "A" git pull ", havuzunuzu güncel hale getirmek için ne yapacağınızdır" < - depo güncellemesi zaten getirme tarafından yapılmadı mı? Uzaktaki şubelerle yerel şubelerinizi güncel hale getirdiğini mi demek istemiyorsunuz? Birleşmek için: Uzaktaki şubeleri bu şubelerin yerel kopyalarınızla birleştiriyor mu, yoksa tam olarak burada ne birleştiriyor?
    2009-11-10 12: 13: 21Z
  2. @ Albert: Evet, garip bir şekilde ifade edildi. git pull her zaman geçerli şubeyle birleştirilir. Böylece, hangi şubeyi 'den çekmek istediğinizi seçersiniz ve onu geçerli şubeye çeker. from dalı yerel veya uzak olabilir; kayıtlı bir git remote olmayan uzak bir şube bile olabilir (yani, git pull komut satırında bir URL iletirsiniz).
    2010-06-06 10: 10: 08Z
  3. @ espertus: Hayır. Basmak hiçbir zaman otomatik olarak birleşmez. Kullanıcının yerel olarak birleştirme çakışmalarını çözmesi, sonra uzaktan kumandayı geri çekmesi bekleniyor.
    2011-03-17 00: 41: 04Z
  4. /home/alice/'daysam ve git fetch /home/bob'u yaparsam, sonraki git merge'a hangi parametreleri geçmeliyim?
    2011-05-27 19: 38: 02Z
  5. Git: pull'u öğrenen kişilere not aslında fetch artı merge tarafından öykünemez. Sadece uzak bir dal göstericinin değiştiği bir değişiklik getirdim ve merge bir şey yapmayı reddediyor. Öte yandan, pull, izleme şubemi hızlı ileri sardı.
    2012-09-28 16: 23: 00Z
  • pull kullandığınızda, Git işinizi otomatik olarak sizin için yapmaya çalışır. İçeriğe duyarlı olduğundan, Git, çalışmakta olduğunuz şubedeki tüm taahhütleri birleştirir. pull İlk önce onları incelemenize izin vermeden taahhütleri otomatik olarak birleştirir . Şubelerinizi yakından yönetemiyorsanız, sık sık çatışmalarla karşılaşabilirsiniz.

  • Siz fetch’da, Git, geçerli şubenizde bulunmayan hedef şubeden taahhütleri toplar ve bunları yerel havuzunuzda saklar . Ancak, bunları geçerli şubenizle birleştirmez . Bu, özellikle havuzunuzu güncel tutmanız gerekiyorsa, ancak dosyalarınızı güncellerseniz kırılabilecek bir şey üzerinde çalışıyorsanız kullanışlıdır. Taahhütleri ana şubenize entegre etmek için merge'u kullanın.

2022
2015-04-18 18: 47: 14Z
  1. Kabul edildi, harika yorum. Bu yüzden gitmekten nefret ediyorum. Bir revizyon aracının sizin için kod düzenlemeleri yapmasına ne zaman izin verdiniz? Ve bu iki dosyayı birleştirmenin yaptığı şey değil mi? Ya bu iki düzenleme dosyada fiziksel olarak ayrı, ancak LOGICALLY olasılıkla ayrılırsa?
    2013-05-13 18: 44: 23Z
  2. @ elexhobby short put, git fetch yalnızca .git/ dizininizi (AKA: yerel depo) ve .git/ (AKA: çalışan ağaç) dışındaki hiçbir şeyi güncellemez. Yerel şubelerinizi değiştirmez ve master'a da dokunmaz. Yine de remotes/origin/master'a dokunuyor (bkz. git branch -avv). Daha fazla uzaktan kumanda varsa, git remote update'u deneyin. Bu, tek bir komuttaki tüm uzaktan kumandalar için git fetch'dur.
    2013-07-17 06: 48: 09Z
  3. @ Tino sizinki gerçekten en önemli nokta. İnsanlar "uzak" dalların .git/refs/remotes/origin/'da bir demet karma olarak saklandığını bilmiyor olabilir.
    2013-09-12 21: 49: 41Z
  4. Getirdiğinizde Git, geçerli şubenizde bulunmayan hedef şubeden herhangi bir taahhüt toplar ve bunları yerel deponuza depolar - Uzaktan kumandadan ne getirildiğini nasıl görebilirim ve yerel şubelerime nasıl eklerim?
    2014-06-13 01: 40: 52Z
  5. @ Tino Hala anlamadığım şey şu ki ... nokta nedir? Neden yalnızca .git'u güncelleştiriyorsa getirme özelliğini kullanın? Amaçlanan fayda nedir ve bundan sonra ne yapmam gerekiyor?
    2016-03-23 ​​12: 19: 54Z

Git'in tasarım felsefesini, SVN gibi daha geleneksel bir kaynak kontrol aracının felsefesiyle karşılaştırmak önemlidir.

Subversion, bir istemci /sunucu modeliyle tasarlanmış ve oluşturulmuştur. Sunucu olan tek bir depo var ve birkaç istemci sunucudan kod alabilir., üzerinde çalışın, ardından sunucuya geri verin. Varsayım, istemcinin bir işlem gerçekleştirmesi gerektiğinde her zaman sunucuya başvurabileceğidir.

Git, merkezi bir depoya ihtiyaç duymadan daha da dağıtılmış bir modeli desteklemek için tasarlanmıştır (ancak isterseniz kesinlikle kullanabilirsiniz). Ayrıca git, müşterinin ve "sunucu" nun aynı anda çevrimiçi olması gerekmeyecek şekilde tasarlandı. Git, güvenilmez bir bağlantıdaki kişilerin bile e-posta yoluyla kod alışverişi yapabilmesi için tasarlanmıştır. Tamamen bağlantısı kesilmiş olarak çalışmak ve git yoluyla kod değişimi yapmak için bir CD yazmak mümkündür.

Bu modeli desteklemek için git, kodunuzla yerel bir depo ve uzak havuzun durumunu yansıtan ek bir yerel depo tutar. Uzak deponun bir kopyasını yerel olarak tutarak, uzak deponun erişilebilir olmadığı durumlarda bile gereken değişiklikleri çözebilirsiniz. Daha sonra değişiklikleri bir başkasına göndermeniz gerektiğinde, git, bunları uzak havuzda bilinen bir noktadan itibaren bir dizi değişiklik olarak aktarabilir.

  • git fetch , "uzak havuzdaki yerel kopyamı en güncel duruma getir" diyen komuttur.

  • git pull , "uzak havuzdaki değişiklikleri kendi kodumu tuttuğum yere getir" diyor.

Normalde git pull bunu, uzak havuzun yerel kopyasını güncel hale getirmek için git fetch 'u uygulayarak ve ardından değişiklikleri kendi kod deponuzda ve muhtemelen çalışma kopyanız.

Paket teslim alma işlemi, iş istasyonunuzdaki bir projenin genellikle en az üç ​​kopyası olduğunu akılda tutmaktır. Bir kopya, kendi taahhüt geçmişinizle kendi deponuzdur. İkinci kopya, düzenlediğiniz ve oluşturduğunuz çalışma kopyanızdır. Üçüncü kopya, uzak bir deponun yerel "önbelleğe alınmış" kopyasıdır.

    
1125
2018-08-24 20: 01: 19Z
  1. Teknik olarak, yerel ve uzak havuzlar gerçekten aynı ve aynı. Git'te bir depo, ebeveynlerine işaret eden taahhütlülerin DAG 'ıdır. Dallar, teknik olarak, anlamlı taahhüt adlarından başka bir şey değildir. Yerel ve uzak dallar arasındaki tek fark, uzak olanlara remoteName/ Sıfırdan git çok iyi bir okumadır. Git'in nasıl çalıştığını anlayınca - ve güzel bir şekilde basit , gerçekten - her şey sadece mantıklı olur.
    2013-08-14 09: 51: 05Z
  2. Açıklama için teşekkürler. Git'in tasarlandığını gerçekten anlamadım, bu yüzden merkezi bir havuza sahip olmanıza gerek yoktu. Herkes, Git'i tarif ederken "DVCS" der, ancak göreceli olarak yeni bir programcı olarak, bu benim için hiçbir şey ifade etmez. Bir CVCS'yi hiç görmedim ve başkalarıyla (örn. Github) birlikte çalışırken hiçbir zaman gizli bir uzaktan depo ile çalışmadım, bu yüzden şimdiye kadar Git'i neyin özel kıldığını anladım. .
    2013-08-15 02: 17: 04Z
  3. Öyleyse, buna dayanarak, neden bir cron işi ile gidip gelmek iyi bir fikir değil? Çalıştığınız uzaktan kumandanın bir kopyasını her zaman yerel makinenizde bulundurmak iyi bir fikir gibi görünür. Aslında, son 24 saat içinde uzaktan kumandayı güncelleyip güncellemediğimi kontrol eden bir komut dosyası yazmak ve bunu internet bağlantısı için bir udev kancasıyla bağlamak gibi hissediyorum.
    2013-08-15 02: 23: 38Z
  4. Bir cron işine sahip olmanın iyi bir fikir olmamasının bir nedeni: genellikle yeni bir bilet veya bir şubeye yapılan güncellemeler üzerinde çalışırken, isterim getirilen değişiklikleri görün. Değişiklikler bir alım sırasında gelmezse, programcı arkadaşıma 'hey sen zorladın mı?' Diye sorduğumda kendime güveniyorum. Ayrıca, en son getirdiğimden beri depoda ne kadar 'karmaşa' olduğunun farkındayım. Bu, şu anda bu depoda yapılan değişikliklerin miktarını ve hızını anlamama da yardımcı oluyor.
    2014-07-23 11: 47: 01Z
  5. @ Nabheet Şey, Git'in içerik odaklı olmasıdır. Verileri yalnızca bir kez saklar ve poiona birden çok kez nts. Bu nedenle Git'te, bir orijinalin üzerindeki birden fazla taahhüt bile olsa, nesnelerin çoğu aynı olduğundan, reponun boyutunu çok fazla etkilemez.
    2016-11-05 09: 43: 18Z

İşte Her şeyin nasıl bir araya geldiğiyle ilgili imajı :

resim tanımını buraya girin

Yeterli ilgi varsa, resmi git clone ve git merge eklemek için güncelleyebilirim ...

    
775
2018-03-19 19: 21: 23Z
  1. git clone ve git merge ile güncellenmiş bir resim çok yardımcı olacaktır!
    2015-09-08 14: 23: 51Z
  2. Evet, lütfen git merge'u ekleyin - merge'un ayrı ayrı çağrılan pull'un pull'u aramakla aynı olmadığını açıkça göstermelidir, çünkü git fetch yalnızca uzaktan kumandadan birleşiyor ve yerel işyerinizi yok sayıyor çekilmekte olan uzak şubeyi izleyen yerel şube.
    2015-10-21 19: 57: 33Z
  3. Bir resim bin kelimeye bedeldir! Klonlama ve birleştirme veri akışına sahip güncellenmiş resim bir yere hazır mı? Diyagramda olanlar dışında başka herhangi bir veri akışı var mı?
    2015-11-25 00: 27: 05Z
  4. @ Contango, lütfen klon ekleyin ve birleştirin. Benim gibi yeni başlayanlar için yardımcı olur.
    2016-01-15 16: 02: 32Z
  5. Diğer cevaplarda klonlama ve birleştirme (aşağıda) th3sly ve thedarkpassenger tarafından gösterilen iki diyagram vardır.
    2016-08-12 00: 42: 46Z

git fetch
git diff ...origin
'un bir kullanım örneği, aşağıdakiler size uzaktaki dalda yaptığınız son değişiklikten sonraki değişiklikleri size söyleyecektir ... böylece gerçek bir çekmeden önce mevcut dalınızdaki ve çalışan kopyanızdaki dosyaları değiştirebilecek olanları kontrol edebilirsiniz.  git diff ..origin     
455
2013-08-01 19: 38: 09Z
  1. Harika toplama! Kafam karıştı, değil mi: git diff origin
    2010-07-27 12: 15: 09Z
  2. neden git diff ...origin değil?
    2012-02-12 23: 47: 33Z
  3. git diff kökeni ve git diff ..origin işe yarıyor ama bu garip değil ... şeyler
    2013-01-08 19: 32: 06Z
  4. @ Compustretch Boşluk olması gerekmiyordu. git diff $(git-merge-base HEAD origin) origin, git diff [--options] <commit>...<commit> [--] [<path>…]’a eşdeğerdir (git diff origin bölümüne bakın. > git diff ...origin'dan farklı kernel.org/pub/software/scm/git/docs/git-diff.html#_description ); origin, origin'dan beri dallandığından git diff origin'da yapılan değişikliklerin kavramsal olarak gerçekleşmesini sağlarken, origin, git diff origin/master'dan bu yana master'dan sonra da geçerli şubede yapılan değişikliklerin tersini içerir.
    2013-08-01 19: 34: 28Z
  5. .. komutlarının hiçbiri benim için işe yaramadı (Windows'ta), ancak HEAD, aşağıda belirtildiği gibi çalışıyor
    2014-02-20 09: 07: 13Z

Aradaki farkın ne olduğunu anlamak bana biraz pahalıya mal oldu, ancak bu basit bir açıklama. Yerel ana makinenizdeki HEAD bir şubedir.

Bir havuzu klonladığınızda, tüm havuzu yerel ana makinenize getirirsiniz. Bu, o sırada HEAD’a bir başlangıç ​​/ana işaretçiye ve aynı git fetch’a işaret eden bir anaya sahip olduğunuz anlamına gelir.

çalışmaya başladığınızda ve taahhüt ettiğinizde, ana işaretçiyi HEAD + taahhütlerinize ilerletirsiniz. Ancak kaynak /ana işaretçi hala klonladığınızda ne olduğuna işaret ediyor.

Öyleyse fark şöyle olacak:

  • git pull yaparsanız, yalnızca uzak havuzdaki tüm değişiklikleri getirir ( GitHub ve menşe /master işaretçiyi HEAD'a getirin. Bu arada, yerel şube yöneticiniz bulunduğu yeri göstermeye devam edecektir.
  • Eğer bir git fetch yaparsanız, temelde getirecek (daha önce açıklandığı gibi) ve ana dalınızdaki tüm değişiklikleri birleştirecek ve işaretçiyi git pull'a getirecektir.
356
2016-01-02 04: 52: 49Z
  1. origin /master, menşei üzerine master COPY olan yerel bir şubedir. Aldığınızda, local: /origin /master komutunu güncellersiniz. Git'teki her şeyin bir dal olduğunu gerçekten anladıktan sonra, bu çok anlamlı ve farklı değişimleri sürdürmenin, hızlı yerel dallar oluşturmanın, birleştirmenin ve yeniden yapılandırmanın ve genellikle ucuz dallanmanın değerini çok değer kazanmanın çok güçlü bir yoludur. modeli.
    2013-05-28 16: 00: 14Z
  2. Hala kafa karıştırıcı. git fetch'un uzaktaki repodaki değişiklikleri tam anlamıyla yerel reponuza indirmek olduğunu düşündüm, ancak bunları DEĞİLDİR - yani, yine de yerel reponuza eklenmeleri /kaydedilmeleri gerekir.
    2015-02-26 14: 57: 50Z
  3. getirme yalnızca uzaktaki /kaynağından (github) yerel kaynağınıza çeker. Ancak, gerçek çalışan dosyalarınızla birleştirilmez. bir çekme işlemi yaparsanız getirecek ve geçerli çalışma dosyalarınızla birleştirilecektir
    2015-02-26 19: 45: 36Z

Bazen görsel bir temsil yardımcı olur.

 buraya resim açıklamasını girin

    
202
2016-01-25 17: 28: 50Z
  1. Resmin yerel repoyu da etkilediğini göstermesi gerektiğini düşünüyorum. Git çekme, yerel repoyu ve çalışan kopyayı etkilemenin bir birleşimidir. Şu anda sadece çalışan kopyayı etkiliyor gibi görünüyor.
    2016-02-14 18: 51: 46Z
  2. @ 太極 者 無極 而 re Kabul edildi - Bu resim oldukça yanıltıcı, çünkü pull atlıyor gibi görünüyor elbette yanlış.
    2016-08-20 15: 33: 23Z
  3. 'Yerel Depo' ile 'Çalışma Kopyası' arasındaki fark nedir? İkisi de bilgisayarda yerel değil mi?
    2017-11-16 03: 12: 58Z
  4. Git alımının kullanımı nedir? Yerel depoda ve çalışma kopyasında ne gibi bir fark olduğunu nasıl göreceksiniz?
    2019-03-13 06: 56: 33Z
  5. @ theITvideos Hayır, değil. Yerel bir depo, işlem yaptığınızda kodunuzun gittiği yerdir (çalışma havuzundan). (Bastığınızda uzaktaki depoya gider).
    2019-03-13 06: 59: 04Z

Kısaca

refs, objects’a benzer, ancak birleşmez. yani, uzaktan güncellemeleri alır (origin/master ve master), ancak yereliniz aynı kalır (yani git pull güncellenir, ancak git clone aynı kalır).

git rebase uzaktan kumandadan aşağı çeker ve anında birleşir.

Diğer

git pull -rebase bir repoyu klonlar.

git branch -a, geçerli dalınızdaki akış yukarı dalda olmayan şeyleri geçici bir alana kaydeder. Şubeniz şimdi değişikliklerinizi başlatmadan öncekiyle aynı. Böylece, git pull uzak değişiklikleri aşağı çekecek, yerel şubenizi geri saracak, değişikliklerinizi güncel olana kadar birer birer güncel olarak tekrarlayın.

Ayrıca, git fetch, tüm şubelerinizde neler olduğunu tam olarak gösterecektir - yerel veya uzak.

Bu blog yayını faydalı oldu:

Git çekme, git getirme ve git klonu (ve git rebase) - Mike Pearce arasındaki fark

ve git clone, git rebase,

git fetch 
ve
git diff master origin/master 
’u kapsar.

====

GÜNCELLEME

Bunu pratikte nasıl kullanacağınızı göstermek için bunu güncelleyeceğimi düşündüm.

  1. Yerel reponuzu uzaktan kumandadan güncelleyin (ancak birleştirme):

     
    git pull
    
  2. Güncellemeleri indirdikten sonra, farkları görelim:

     git rebase origin
  3. Bu güncellemelerden memnunsanız, birleştirme:

     git clone

Notlar:

2. adımda: Yerel ve uzaktan kumandalar arasındaki farklar hakkında daha fazla bilgi için bkz. Yerel bir git şubesini uzak şubeyle nasıl karşılaştırabiliriz?

3. adımda: Burada

git-pull - Fetch from and merge with another repository or a local branch
SYNOPSIS

git pull   …
DESCRIPTION

Runs git-fetch with the given parameters, and calls git-merge to merge the 
retrieved head(s) into the current branch. With --rebase, calls git-rebase 
instead of git-merge.

Note that you can use . (current directory) as the <repository> to pull 
from the local repository — this is useful when merging local branches 
into the current branch.

Also note that options meant for git-pull itself and underlying git-merge 
must be given before the options meant for git-fetch.
yapmak daha büyük olasılıkla daha doğrudur (örneğin hızlı değişen bir depoda). @Justin Ohs yorumuna bakın başka bir cevap.

Ayrıca bakınız: http://longair.net/blog /2009/04/16 /git-getir-birleştirme /

    
195
2018-11-28 20: 18: 32Z
  1. Bana birisi yerel kodu "ipucu" olarak yansıtmak istiyorsa, git fetch kullanmalı gibi geliyor. İpucunu tırnak işaretleri arasına koydum, sanırım usta ne olursa olsun ve birinin "zip olarak indir" anlamına geldiğini sanıyorum github.com
    2013-09-12 08: 27: 15Z
  2. Gitdikten sonra yapılan değişikliklerden memnun değilseniz ne olur? sonra ne yapmalı?
    2015-03-24 06: 06: 37Z
  3. Yeniden yapılanma ile ilgili paragrafınız tam aradığım şeydi. Her şeyi sıfırlamak, uzaktan güncellemek, sonra değişikliklerinizi önceki taahhütlerinize göre yeniden oynatmak hakkındaki düşünceleriniz. Doğru olduğunu varsayarak mükemmel bir açıklama. ;)
    2016-03-03 00: 01: 20Z
 merge

Tarihlerin birleştirilmesini istersen çekersin, bazı insanlar burada bazı makaleleri etiketlerken, sadece 'cenneti istiyorsan' getireceksin.

    
168
2008-11-15 09: 52: 50Z
  1. Çok ilginç, ancak "sadece kod" istediğiniz bir kullanım durumunu gerçekten göremiyorum. Getirdiğin zaman koduna ne oldu? Silindi mi? Uzaktan kumandada ne oldu? Birleştirmezseniz kodunuzu silmeden repounuza nasıl girer?
    2010-03-27 16: 21: 55Z
  2. @ e-satis: Uzak dal da makinenizde yerel olarak depolanır. Böylece, origin'u yaptığınızda depodan değişiklikler alır ve yerel uzak şubenizi günceller. Yerel kepekinizi etkilemezYerel uzak şubeyi izleyen ch, çalışan kopyanızı etkilemez. Şimdi, bir master yaptığınızda, getirilen değişiklikleri yerel şubenizle birleştirir.
    2011-10-31 04: 23: 36Z
  3. Getirme komutu için basit bir kullanım örneği: diğer kişilerin bir birleştirme veya kod incelemesi gibi son zamanlardaki taahhütlerini içeren ve yalnızca sizin adınıza en yakın adresinize erişen zaman alıcı işlemler gerçekleştirin ağ bağlantısı gereklilikleri olmadan yerel depoya tarih verin; çünkü daha önce ihtiyacınız olan her şeyi hızlıca indirmek için getirmeyi kullandınız (örneğin, başka bir geliştiriciyi ziyaret ederken ve başka bir veri havuzunun ağına bağlıyken). Pull komutu aynı taahhütleri indirir, ancak yaptığı birleştirme istenmeyen olabilir.
    2013-09-19 10: 25: 33Z

Uzak bir havuzdan getirebilir, farklılıkları görebilir ve ardından çekebilir veya birleştirebilirsiniz.

Bu, origin/master adlı bir uzak havuza ve

git checkout master                                                  
git fetch                                        
git diff origin/master
git rebase origin master
adlı uzak şubeyi git pull izleyen bir örneğe örnektir:  git fetch     
153
2015-03-15 22: 20: 04Z
  1. Muhtemelen çekimi atlamak ve değişiklikleri zaten uyguladığınızdan bu yana attığınız son adım olarak sadece "git rebase origin" yapmak istersiniz. Bunun nedeni, birisinin sizin aldığınızdan bu yana değişiklikleri değiştirmiş olabileceği ve bunlar üzerinde fark incelemesi yaptığınız şeyi almamış olmasıydı.
    2012-08-31 20: 02: 48Z

Kısa ve kolay cevap, git merge'un sadece git pull ve onu origin olmasıdır.

master'un beğenip beğenmediğinizi otomatik olarak birleştireceğine dikkat etmek çok önemlidir . Bu elbette birleştirme çatışmalarına neden olabilir. Diyelim ki kumandanız git diff origin/master ve şubeniz git rebase. Çekmeden önce

git pull origin master
git checkout foo-branch
git rebase master
git push origin foo-branch
'unuz varsa, olası birleştirme çatışmaları hakkında bir fikriniz olmalı ve yerel şubenizi buna göre hazırlayabilirsiniz.

Çekip itmenin yanı sıra bazı iş akışları , bu linkten git pull --rebase'u içerir, ki bunla bağlantılı makaleden de alıntı yapıyorum:

 man

Kendinizi böyle bir durumda bulursanız, git-pull'a cazip gelebilirsiniz. Gerçekten, gerçekten ne yaptığını bilmediğin sürece, buna karşı tavsiyede bulunabilirim. Bu uyarı 2.3.5, git pull --rebase sürüm rebase sayfasındandır:

  

Bu, potansiyel olarak tehlikeli bir çalışma şeklidir. Bu yeniden yazar   tarihçeyi yayınladığınızda iyiye işaret etmez.   zaten. Git-rebase'i okumadıysanız, bu seçeneği kullanmayın (1)   dikkatlice.

    
145
2018-09-24 15: 28: 49Z
  1. @ JustinOhms rebase verilen durumda doğru şey değilse, iki adımda yapılırsa doğru mu? Yapılması gereken doğru şeyse, iki adımda yapmanın faydası nedir?
    2013-05-23 21: 56: 38Z
  2. @ Kaz - çünkü rebase otomatik değildir. Değişiklikleri önce getirmek, karar vermenizi sağlar. Zaten bastığınız yeniden yapılanma geçmişiyle ilgili sorunu çözmedi. Henüz yapmadığınız değişiklikleri yeniden düzenlemenin güvenli olup olmadığını görmenize izin verir.
    2013-05-24 21: 11: 52Z
  3. @ JustinOhms Değişiklikleri yeniden düzenlemenin güvenli olup olmadığına nasıl karar verirsiniz? Sadece git rebase'i denerdim ve bir karmaşa çıkarsa geriye doğru giderdim, bu durumda git pull - rebase'i de yapabilirim. Fakat belki başka bir yolunuz vardır?
    2013-05-25 06: 14: 19Z
  4. @ KaZ gitk, şube yapısını görsel olarak görmenizi sağlar. Yerel kafanızın, uzaktan kumandalarınızın ve şube yapılarınızın ne getirdiğinize ilişkin konumunuzu gösterecektir. Bu şekilde, daha önce uzaktan kumandanıza yönlendirdiğinizden önceki bir ataya dayanan getirilen değişiklikleri yeniden düzenlemediğinizden emin olabilirsiniz.
    2013-05-28 19: 18: 02Z
  5. Henüz basılmamış bir yerel şube üzerinde çalışırken merge'u kullanın. Uzaktan kumandada bulunan bir şube üzerinde çalışıyorsanız, git pull bazı kötü sorunlara neden olabilir, bu nedenle normal bir git fetch'u tercih etmeniz gerekir.
    2014-12-01 08: 39: 57Z

Tamam , işte git fetch ve git pull hakkında bazı bilgiler, bu nedenle gerçek farkları anlayabilirsiniz ... birkaç basit kelimeyle, getirme en son verileri alır, ancak kod değişmiyorsa ve geçerli yerel şubenizin kodunu karıştırmayacaksa da, değişiklik yapın kod değişikliklerini alın ve yerel şubenizle birleştirin, her biri hakkında daha fazla bilgi edinmek için okumaya devam edin:

git getir

Tüm referanslar ve nesneler 'i ve tüm yeni şubeleri yerel Depounuza yükler ...

  

Bir veya daha fazla dal ve etiket al (topluca "refs")   diğer depoları tamamlamak için gerekli olan nesnelerle birlikte   geçmişleri. Uzaktan izleme dalları güncellendi (açıklamaya bakın)   Bu davranışı denetleme yolları için aşağıdakilerden birini kullanın.)

     

Varsayılan olarak, getirilmekte olan geçmişlere işaret eden herhangi bir etiket   ayrıca getirildi; Bunun etkisi, dallara işaret eden etiketleri almaktır.   Bu varsayılan davranış kullanılarak değiştirilebilir.   --tags veya --no-tags seçenekleri veya yapılandırarak   remote..tagOpt. Etiketleri açıkça alan bir refspec kullanarak,   ilgilendiğiniz dalları işaret etmeyen etiketleri alabilirsiniz   aynı zamanda.

     

git alma, tek bir adlandırılmış havuzdan veya URL'den alabilir veya   Bir seferde birkaç depodan verilir ve bir   uzaktan kumanda. yapılandırma dosyasına giriş. (Bkz. Git-config 1 ).

     

Hiçbir uzaktan belirtilmediğinde, varsayılan olarak başlangıç ​​noktası uzaktan   Geçerli için yapılandırılmış bir yukarı akış şubesi yoksa, kullanılmış   dalı.

     

Alınan reflerin adları, nesne adlarıyla birlikte   işaret eder, .git /FETCH_HEAD yazılır. Bu bilgi olabilir   komut dosyaları veya git-pull gibi diğer git komutları tarafından kullanılır.


git pull

uzak 'daki değişiklikleri yereldeki geçerli şubeye uygular ...

  

Uzak bir havuzdan mevcut şubeye değişiklikler dahil eder.   Varsayılan modda, git çekme git getirme için kısaca   git FETCH_HEAD birleştirme.

     

Daha doğrusu, git pull, belirtilen parametreleri kullanarak git fetch'i çalıştırır ve   Alınan dal başlarını akıntıya bağlamak için   dalı. --Rebase ile git birleştirme yerine git rebase'i çalıştırır.

     

, iletildiği gibi uzak bir havuzun adı olmalı   git-fetch 1 . isteğe bağlı bir uzaktan ref adı verebilir (örneğin,   Bir etiketin adı) ve hatta karşılık gelen ref ref koleksiyonu   uzaktan takip şubeleri (örneğin, refs /heads /: refs /remotes /kökenli /),   ancak genellikle uzak havuzdaki bir şubenin adıdır.

     

için varsayılan değerler ve   Geçerli dal için "uzak" ve "birleştirme" yapılandırması   git-branch --track.


Ayrıca git fetch ve git pull'un birlikte nasıl çalıştığını göstermek için aşağıdaki görsel 'i de oluşturuyorum ...

 git ve git getir

    
129
2018-09-28 10: 38: 33Z
  1. Görüntüyü seviyorsanız, git git sayfalarına bir göz atın, bu tüm git komutları için aynı şeydir ... ndpsoftware.com/git-cheatsheet.html
    2018-05-20 16: 42: 23Z
  2. Klonu yerel depoyu da etkilemez (tüm geçmişi uzaktan kumandadan kopyalamak)?
    2018-07-04 04: 38: 54Z

resim tanımını buraya girin

Bu etkileşimli grafik gösterimi, gitmeyi anlamada çok yararlıdır: http://ndpsoftware.com/git-cheatsheet.html

git pull, uzaktan kumandadan yerel deponuzdaki değişiklikleri yalnızca "indirir". git fetch, değişiklikleri indirir ve bunları geçerli dalınıza birleştirir. "Varsayılan modda git merge FETCH_HEAD, git pull --rebase ve ardından git pull için kısa yoldur."

    
123
2016-12-09 10: 02: 01Z
  1. İnsanlar, farklı sütunlarla etkileşime geçmek için bağlantıya tıklayın. Bu sayfa, her komut arasındaki farkları tam olarak anladığım en iyi kaynak.
    2016-10-04 00: 41: 48Z

Bonus:

Pull & Yukarıdaki cevapları alıp ilginç bir numara paylaşmak istiyorum.

git pull --rebase

Bu yukarıdaki komut, git hayatımda çok zaman kazandıran en kullanışlı komuttur.

Yeni taahhütlerinizi sunucuya göndermeden önce, bu komutu deneyin; en son sunucu değişikliklerini (bir getirme + birleştirme ile birlikte) otomatik olarak senkronize edecek ve taahhüdünüzü git günlüğünde en üste yerleştirecektir. Manuel çekme /birleştirme konusunda endişelenmenize gerek yok.

Ayrıntıları şu adreste bulabilirsiniz: http://gitolite.com/git-pull--rebase

    
119
2016-08-08 16: 56: 17Z
  1. Güzel ipucu, yeniden yapılanma değişikliklerinde yeniden yapılanma değişikliklerini yapan yeni git kullanıcılarından bahsetmeye değer olsa da (bu çöküşün şaşırtıcı olduğunu gördüm)
    2016-09-20 12: 57: 00Z
  2.                                          LOCAL SYSTEM
                      . =====================================================    
    ================= . =================  ===================  =============
    REMOTE REPOSITORY . REMOTE REPOSITORY  LOCAL REPOSITORY     WORKING COPY
    (ORIGIN)          . (CACHED)           
    for example,      . mirror of the      
    a github repo.    . remote repo
    Can also be       .
    multiple repo's   .
                      .
                      .
    FETCH  *------------------>*
    Your local cache of the remote is updated with the origin (or multiple
    external sources, that is git's distributed nature)
                      .
    PULL   *-------------------------------------------------------->*
    changes are merged directly into your local copy. when conflicts occur, 
    you are asked for decisions.
                      .
    COMMIT            .                             *<---------------*
    When coming from, for example, subversion, you might think that a commit
    will update the origin. In git, a commit is only done to your local repo.
                      .
    PUSH   *<---------------------------------------*
    Synchronizes your changes back into the origin.
    
    ve git pull arasındaki farkın ne olduğunu açıklayabilir misiniz?
    2018-01-17 07: 02: 10Z
  3. Yukarıdaki cevapta bu yöntemle ilgili başlangıç ​​uyarısına bakın: stackoverflow.com /a /6011169/241244
    2018-10-24 08: 00: 20Z

Bu şeyleri kavramak için durumun görsel olarak temsil edilmesini istiyorum. Belki başka geliştiriciler de görmek ister, işte benim ekim. Her şeyin doğru olduğundan tamamen emin değilim, bu nedenle lütfen herhangi bir hata bulursanız yorum yapın.

 
---------------------     -----------------------     -----------------------
- Remote Repo       -     - Remote Repo         -     - Remote Repo         -
-                   -     - gets pushed         -     -                     -
- @ R01             -     - @ R02               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Repo        -     - Local Repo          -     - Local Repo          -
- pull              -     -                     -     - fetch               -
- @ R01             -     - @ R01               -     - @ R02               -
---------------------     -----------------------     -----------------------

---------------------     -----------------------     -----------------------
- Local Sandbox     -     - Local Sandbox       -     - Local Sandbox       -
- Checkout          -     - new work done       -     -                     -
- @ R01             -     - @ R01+              -     - @R01+               -
---------------------     -----------------------     -----------------------

Uzaktan kumandayı almanın bazı önemli avantajları şunlardır:

  • Performans (ağ üzerinden sıkıştırmaya çalışmadan tüm taahhütleri ve mesajları gözden geçirin)
  • Yerel reponuzun durumu hakkında Geri bildirim (örneğin, Atlassian's SourceTree kullanıyorum; bu, kaynak veya menşe ile karşılaştırıldığında ileride veya arkada işlem yapıp yapmadığımı belirten bir ampul verir.) bir GIT FETCH).
111
2014-07-25 07: 01: 35Z
  1. ---------------------     -----------------------     -----------------------
    - Remote Repo       -     - Remote Repo         -     - Remote Repo         -
    -                   -     - gets pushed         -     -                     -
    - @ R01             -     - @ R02               -     - @ R02               -
    ---------------------     -----------------------     -----------------------
    
    ---------------------     -----------------------     -----------------------
    - Local Repo        -     - Local Repo          -     - Local Repo          -
    - pull              -     -                     -     - pull                -
    - @ R01             -     - @ R01               -     - @ R02               -
    ---------------------     -----------------------     -----------------------
    
    ---------------------     -----------------------     -----------------------
    - Local Sandbox     -     - Local Sandbox       -     - Local Sandbox       -
    - Checkout          -     - new work done       -     - merged with R02     -
    - @ R01             -     - @ R01+              -     - @R02+               -
    ---------------------     -----------------------     -----------------------
    
    da bir birleştirme gerçekleştirmiyor mu, yani çalışan kopyaya kadar gidiyor mu?
    2014-03-24 17: 28: 47Z
  2. İyi nokta, evet, çalışma kopyasındaki tüm değişiklikleri koyacaktır ve sonra kendiniz yerel repoda işleyebilirsiniz. Görselleri güncelleyeceğim.
    2014-03-25 07: 50: 20Z
  3. @ JustusRomijn Bir çekme yerel depoyu da güncellemiyor mu? Kaynak ve çalışma kopyası yıldızları arasında bir yıldız işareti olmamalıdır mı?
    2015-01-08 09: 34: 07Z
  4. @ user764754 Çektiğiniz zaman, çalışma kopyanız değişiklikleri alır (çözmeniz gerekebilecek bazı çakışmalar olabilir). Yine de yerel deponuza dahil etmeniz gerekiyor.
    2015-01-12 07: 17: 24Z
  5. @ JustusRomijn: Resim için teşekkürler. Şemayı, depodaki sıfırlama, kiraz toplama gibi işlemlerin etkilerini göstererek daha kapsamlı hale getirebilirsiniz. devletler.
    2015-01-17 12: 42: 39Z

Bununla da mücadele ettim. Aslında buraya tam olarak aynı sorunun google aramasıyla geldim. Tüm bu cevapların okunması nihayet kafamda bir tablo çizdi ve 2 deponun ve 1 kum havuzunun ve bu versiyonun versiyonunu izlerken zaman içinde yapılan eylemlerin durumuna bakmaya karar verdim. İşte burada ne buldum. Herhangi bir yere bulaştıysam lütfen beni düzeltin.

Getirilmiş üç depo:

 A

Çeken üç depo

 B

Bu, bir getirinin neden çok önemli olduğunu anlamama yardımcı oldu.

    
102
2017-05-31 19: 41: 16Z
  1. Okuması zor değil: kutular bir reponun durumunu gösterir, her satırda satır 2'de rapor edilen işlemden sonra soldan sağa değişir. kutu. R0n etiketleri git'teki etiketlerdir ve + işaretli bir etiket henüz yorumlanmamıştır. Sanbox, bağlı olduğunuz şeylerin depolandığı repo klasöründen farklı olan çalışma klasörünüz için kullanılır.
    2017-08-30 07: 57: 02Z

GIT Getirme ile GIT Çekme arasındaki fark aşağıdaki senaryoda açıklanabilir: (Resimlerin kelimelerden daha yüksek sesle konuştuğunu unutmayın !, resimsel sunum yaptım)

Ekip üyelerinizle bir proje üzerinde çalıştığınıza bir örnek verelim. Bu yüzden projenin bir ana Şubesi olacak ve tüm katılımcılar bunu kendi yerel havuzlarına yerleştirmeli ve daha sonra bu yerel şube üzerinde çalışıp modülleri değiştirmek /Eklemek ve ardından ana şubeye geri itmek zorundadır.

Yani, Yerel deponuzdaki ana projeyi terk ettiğinizde iki Şubenin Başlangıç ​​Durumu böyle olacaktır (C, D ve D, projenin tamamlanmış halidir)

 buraya resim açıklamasını girin

Şimdi, yeni modül üzerinde çalışmaya başladınız (varsayalım E) ve F modülünü tamamladığınızda ana şubeye itmek istiyorsunuz, Ancak bu arada, takım arkadaşlarınızdan birinin yeni Modül C geliştirdiği de olur. , D ve modifiye D.
Öyleyse şimdi olan şey, yerel deponuzun, projenin orijinal ilerlemesinin gerisinde kalmaması ve bu nedenle değişikliklerinizi ana şubeye itmeniz çatışmaya neden olabilir ve Modül C'un arızalanmasına neden olabilir.

 buraya resim açıklamasını girin

Bu gibi sorunlardan kaçınmak ve projenin orijinal ilerlemesine paralel çalışmak için bunların iki yolu vardır:

1 . Git Fetch- Bu, tüm indirmee Yerel şubenizde bulunmayan menşe /ana şube projesinde yapılan değişiklikler. Git Merge komutunun, havuzunuza veya şubenize getirilen değişiklikleri uygulamasını bekler.

 buraya resim açıklamasını girin

Öyleyse şimdi dosyaları, havuzunuza eklemeden önce dikkatlice izleyebilirsiniz. Ayrıca

git pull == git fetch + git merge
'u, Modified git pull nedeniyle gerekirse de değiştirebilirsiniz.

 buraya resim açıklamasını girin

2 . Git Pull- Bu, yerel şubenizi menşe /ana şubeyle güncelleyecektir, yani aslında ne yaparsa Git Fetch ve Git'in birbiri ardına birleşmesidir. Ancak bu, Anlaşmazlıkların ortaya çıkmasına neden olabilir, bu nedenle Git Pull'ı temiz bir kopya ile kullanmanız önerilir.

 buraya resim açıklamasını girin

    
91
2018-03-03 04: 13: 05Z
  1. 'Ana Şubeyi' 'Uzak Repo' olarak değiştirebilseydiniz çok iyi bir cevap olurdu.
    2018-06-04 00: 17: 05Z

Basitçe diyoruz:

 git fetch

git merge çalıştırıyorsanız, verileri yerel olarak birleştirmenize gerek yoktur. git pull == git fetch + git merge'u çalıştırırsanız, yerel makinenize en son kodu almak için git pull --rebase = git fetch + git rebase'u çalıştırmanız gerekir. Aksi takdirde, yerel makine kodu birleştirme olmadan değiştirilemez.

Yani Git Gui’de, getirdiğinizde, verileri birleştirmeniz gerekir. Getir kendini yerelde kod değişiklikleri yapmaz. Kodu güncellerken, ekrana getirerek kontrol edebilirsiniz. bir kez getir ve gör; Kod değişmeyecek. Sonra birleşiyorsun ... Değiştirilen kodu göreceksin.

    
82
2013-07-17 13: 35: 56Z
  1. git fetch :) demeyi tercih ederim
    2013-06-07 10: 38: 29Z
  2. Ancak origin
    2013-07-17 07: 06: 50Z

origin/ kodu uzak sunucudan yerel deponuzdaki izleme dallarına çeker. Uzaktan kumandanız origin/master (varsayılan) olarak adlandırılmışsa, bu dallar origin/mybranch-123, örneğin git pull, git fetch, vb. Olacaktır. Bunlar, geçerli şubeleriniz değildir, bunlar, sunucuların bu dallarının yerel kopyalarıdır. .

git fetch, git fetch’u yapar, ancak ayrıca kodu izleme şubesinden o şubenin geçerli yerel sürümüne birleştirir. Henüz bu değişikliklere hazır değilseniz, önce yalnızca git diff.

    
79
2016-06-01 00: 59: 49Z

git merge uzak şubeleri alır, böylece git pull veya git fetch'u geçerli şubeyle alabilirsiniz. git pull, geçerli dal tarafından izlenen uzak öbek üzerinde alım gerçekleştirir ve ardından sonucu birleştirir. Uzak şubede yerel şubenizle birleştirme yapmadan herhangi bir güncelleme yapılıp yapılmadığını görmek için git fetch'u kullanabilirsiniz.

    
75
2013-03-09 20: 31: 48Z

Git Alma

Yerel şubenize değişiklikleri menşei yoluyla getirerek yüklersiniz. Alma işlemi, başkalarının sahip olduğu tüm taahhütler için uzaktan repo soraryaptı ancak yerel reponuzda yok. Getirme bu taahhütleri indirir ve yerel depoya ekler.

Git Birleştirme

Birleştirme komutunu kullanarak indirme yoluyla indirilen değişiklikleri uygulayabilirsiniz. Birleştirme, getirilen taahhütleri alma işleminden alır ve yerel şubenize eklemeye çalışır. Birleştirme, yerel değişikliklerinizin taahhüt geçmişini koruyacak, böylece şubenizi itme ile paylaştığınızda Git, başkalarının değişikliklerinizi nasıl birleştirebileceğini bilecektir.

Git Çekme

Alma ve birleştirme, ikisini birleştiren bir komutun oluşturulmasını sağlayacak kadar sık ​​sık birlikte çalışır. Çekme bir indirme işlemi yapar ve indirilen taahhütleri yerel şubenize eklemek için bir birleştirme yapar.

    
69
2017-06-16 18: 15: 10Z

git pull ve git fetch arasındaki tek fark şudur:

rm -rf uzak bir daldan çeker ve birleştirir.

master@remote >> remote/origin/master@local yalnızca uzak şubeden alır, ancak birleşmez

yani. git çekme = git alma + git birleştirme ...

    
49
2013-06-05 15: 47: 06Z
  1. Ve eğer git gitmekte olduğunuza karar verdiğini düşünüyorsa ve "hızlı ileri" yapamazsanız, remote/origin/master@local >> master@local'u bitirdim ve baştan sona erdirdim. Aptal Git, lütfen güncel kalmama izin ver, böylece işe geri dönebilirim?
    2013-09-11 22: 01: 21Z

Git, kronolojik olarak daha eski taahhütlerin daha yeni taahhütlerden sonra uygulanmasına izin verir. Bu nedenle, depolar arasında taahhüt devretme eylemi iki aşamaya ayrılır:

  1. Bu uzak şubenin yerel repo içindeki kopyasına yeni şubenin uzak şubeden kopyalanması.

    (repo işlemi için repo) git

  2. Yeni taahhütleri yerel şubeye entegre etme

    (repo içi işlem) git fetch

2. adımı uygulamanın iki yolu vardır. Yapabilecekleriniz:

  1. Son ortak atadan sonra yerel şubeyi çatallayın ve yerel depoya özgü olan taahhütlere paralel yeni taahhütler ekleyin, taahhütleri birleştirerek kesinleştirin, çatalları kapatın.
  2. Son ortak atadan sonra yeni işler ekleyin ve yerel depoya özel olarak yeniden uygulayın.

git merge terminolojisinde, adım 1 git rebase, adım 2 ise git pull veya git fetch

git merge, git fetch origin master ve git log -p master..origin/master’dur

    
43
2013-11-28 17: 03: 45Z

Git, iki komutu kullanarak en son sürümün dalını uzaktan kumandadan yerel konumuna alır:

  1. git fetch: Git, uzaktaki bir yerden en son sürüme sahip olacak, ancak otomatik olarak birleştirilmeyecek.  git merge origin/master  git pull origin master  git fetch

    Yukarıdaki komutlar, ana şubenin son versiyonunun uzaktan kumandadan orijinal ana şubeye indirilmesi anlamına gelir. Ve sonra yerel ana dal ve orijin ana dalını karşılaştırır. Sonunda birleş.

  2. git pull: Git uzaktan kumandadan en son sürümü alacak ve yerelde birleşecektir.

     git merge

    Yukarıdaki komut git fetch ve git pull'a eşdeğerdir. Uygulamada, git fetch belki daha güvenlidir çünkü birleşmeden önce değişiklikleri görebilir ve birleşip birleştirmeyeceğimize karar verebiliriz.

35
2014-08-12 04: 00: 07Z
  

git fetch ve git pull arasındaki fark nedir?

Bunu anlamak için önce yerel gitinizin yalnızca yerel deponuzu değil, aynı zamanda uzak deponun yerel bir kopyasını da koruduğunu anlamanız gerekir.

git pull, uzak havuzdaki yerel kopyanızı güncel tutar. Örneğin, uzak havuzunuz GitHub ise - yayın yapmak isteyebilirsiniz.Uzak havuzda yapılan değişiklikleri yerel kopyanızda bulunan uzak havuza yerleştirin. Bu, karşılaştırma veya birleştirme gibi işlemleri gerçekleştirmenize olanak sağlar.

git fetch, uzak havuzdaki değişiklikleri kendi kodunuzu tuttuğunuz yere indirecektir. Tipik olarak, shortcut ilk önce uzak deponun yerel kopyasını güncellemek için git fetch yapar ve ardından değişiklikleri kendi kod deponuzda ve muhtemelen çalışan kopyanızda birleştirir.

    
35
2015-07-11 10: 22: 46Z

git pull == (git alma + git birleştirme)

git fetch yerel şubelere değişmiyor.

İstenilen proje için ayarlanmış bir uzaktan kumandayı zaten yerel bir havuzunuz varsa, git fetch'i kullanarak mevcut uzaktan kumandanın tüm dallarını ve etiketlerini kapabilirsiniz. ... Al, yerel dallarda herhangi bir değişiklik yapmaz, bu nedenle yeni bir alım değişikliklerini dahil etmek için uzak bir dalı eşleştirilmiş bir yerel dalla birleştirmeniz gerekir. github'dan

    
32
2013-09-19 22: 41: 11Z

Açık ve basit olmaya çalışıyorum.

git çekme komutu aslında git getirme için bir git pull, ardından git birleştirme veya git rebase yapılandırmanıza bağlı olarak komut. Git deponuzu yapılandırabilirsiniz; böylece git pull , bir yeniden düzenleme işleminden sonra bir getirme olur.

    
31
2015-07-29 18: 38: 48Z

Aslında Git, kendi kodunuzun bir kopyasını tutar ve uzak havuz.

git pull komutu, uzak havuzdan veri alarak yerel kopyanızı güncel tutar. Buna ihtiyacımızın nedeni, bir başkasının kodunda bazı değişiklikler yapmış olması ve kendinizi güncel tutmak istemeniz olabilir.

git pull = git fetch + git merge 
komutu uzak havuzdaki değişiklikleri kendi kodunuzu tuttuğunuz yere getirir. Normalde,
git pull  
bunu ilk önce uzak havuzun yerel kopyasını güncellemek için bir 'git fetch' yaparak yapar ve ardından değişiklikleri kendi kod deponuzda ve muhtemelen çalışan kopyanızda birleştirir.     
31
2017-08-17 20: 51: 46Z
 git rebase     
30
2015-07-12 03: 54: 52Z

Yeni Başlayanlar İçin Basit Bir Grafik Gösterimi,

 buraya resim açıklamasını girin

Burada,

 
git pull origin master

kodu depodan alacak ve yerel bölgenizle yeniden oluşturacak ... git gitmeden önce yeni komisyonların yaratılması olasılığı var.

ancak içeride

git getir

kodu depodan alır ve

git fetch origin master
kullanarak el ile yeniden düzenlememiz gerekir

örneğin: sunucu yöneticisinden alıp yerel yöneticime ekleyeceğim.

1) git çekme (rebase otomatik olarak yapılacak):

 
git rebase origin/master

buradaki menşei uzak reponunuz ana ise şubenizdir

2) git getir (el ile yeniden oluşturulması gerekiyor):

 

sunucu değişikliklerini orijinale getirecektir. ve kendi başınıza yeniden başlatana kadar yerelinizde olacak. kodları kontrol ederek çakışmaları elle düzeltmemiz gerekiyor.

 

bu, kodu yerel olarak yeniden oluşturur. bundan önce doğru şubede olduğunuzdan emin olun.

    
29
2017-07-12 06: 23: 41Z
  1. Güzel grafik, ancak grafik "birleştirme" dediğinde neden "rebase" kullandığınızı açıklamak isteyebilirsiniz.
    2018-10-10 09: 33: 37Z
  2. birleştirme, başka bir şube taahhüdünü temsil edecek ve referans olarak taahhüt içeren yeni bir taahhüt üretecektir. ancak rebase, başka bir şubeden taahhütleri çoğaltacaktır, çoğaltmak yerine yeni bir taahhüt oluşturmaz.
    2018-10-10 11: 00: 51Z
kaynak yerleştirildi İşte