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

• pull öğesini kullandığınızda, Git işinizi otomatik olarak sizin için yapmaya çalışır. Bağlama duyarlı, bu nedenle Git, çalışmakta olduğunuz şubeye girilen tüm taahhütleri birleştirir. pull/, ö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.

• fetch olduğunda, Git, hedef şubenizde mevcut şubenizde bulunmayan tüm taahhütleri toplar ve bunları yerel havuzunuzda saklar. Ancak, onları 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 öğesini kullanın.

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

Subversion, bir müşteri/sunucu modeliyle tasarlandı ve üretildi. Sunucu olan tek bir depo vardır ve birkaç istemci sunucudan kod alabilir, üzerinde çalışabilir ve ardından sunucuya geri yükleyebilir. Varsayım, istemcinin bir işlemi gerçekleştirmesi gerektiğinde her zaman sunucuya başvurabileceğidir.

Git, merkezi bir depoya ihtiyaç duymadan daha dağıtılmış bir modeli desteklemek için tasarlandı (yine de isterseniz kesinlikle kullanabilirsiniz). Ayrıca git, müşteri 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 üzerinden kod değişimi yapmak için bir CD yazmak mümkündür.

Bu modeli desteklemek için git, kodunuzla yerel bir depoya ve ayrıca uzak havuzun durumunu yansıtan ek bir yerel depoya sahiptir. 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 havuzun yerel kopyasını bugüne kadar getir" diyen komuttur. 

• git pullder ki "uzak havuzdaki değişiklikleri kendi kodumu tuttuğum yere getir."

Normaldegit pull/ bunu uzak deponun yerel kopyasını güncel hale getirmek için agit fetchkullanarak ve ardından değişiklikleri kendi kod deponuza ve muhtemelen çalışan kopyanıza birleştirerek yapar.

El koyma, iş istasyonunuzda bir projenin sık sık en az üç kopyasının olduğunu unutmayın. 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.

İşte Oliver Steele'in hepsinin nasıl bir araya geldiğine dair görüntüsü :

Yeterli ilgi alanı varsa, sanırım git clone ve git merge... eklemek için resmi güncelleyebilirim. 

git fetch 'nin bir kullanım durumu, aşağıdakilerin size en son çekilişinizden bu yana uzaktaki dalıma yapacağınız değişiklikleri söylemesidir ... böylece gerçek bir çekmeden önce kontrol edebilirsiniz; bu, geçerli dalınızdaki ve çalışan kopyanızdaki dosyaları değiştirebilir.

git fetch
git diff ...Origin

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

Bir havuzu klonladığınızda, tüm havuzu yerel Ana Bilgisayarınıza getirirsiniz. Bu, o sırada HEAD için bir Origin/master işaretçisine ve aynı HEAD'ye işaret eden master'e sahip olduğunuz anlamına gelir.

çalışmaya başladığınızda ve taahhütler verdiğinizde, ana işaretçiyi HEAD + adreslerinize ilerletirsiniz. Ancak Origin/master işaretçisi hala klonladığınızda ne olduğuna işaret ediyor.

Yani fark olacaktır:

• Bir git fetch yaparsanız, uzak depodaki ( GitHub ) tüm değişiklikleri alır ve Origin/master işaretçisini HEAD öğesine taşır. Bu arada, yerel şube yöneticiniz bulunduğu yeri göstermeye devam edecektir.
• Bir git pull yaparsanız, temelde getirecek (daha önce açıklandığı gibi) ve ana dalınızdaki yeni değişiklikleri birleştirecek ve işaretçiyi HEAD öğesine getirecektir.

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

Kısaca

git fetch, pull öğesine benzer, ancak birleşmez. yani, uzaktan güncellemeler alır (refs ve objects) ancak yereliniz aynı kalır (i.e Origin/master güncellenir ancak master aynı kalır).

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

Daha

git clone bir repoyu klonlar.

git rebase, geçerli dalınızdaki akış yukarı dalda olmayan şeyleri geçici bir alana kaydeder. Şubeniz şimdi değişikliklerinizi başlatmadan önceki ile aynı. Bu nedenle, git pull -rebase uzak değişiklikleri aşağı çeker, yerel şubenizi geri alır, değişikliklerinizi güncel olana kadar geçerli şubenizin üstünde birer birer tekrarlar.

Ayrıca, git branch -a yerel ve uzaktaki tüm şubelerinizde neler olup bittiğini tam olarak gösterecektir.

Bu blog yazısı faydalı oldu:

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

ve git pull, git fetch, git clone ve git rebase öğelerini kapsar.

====

GÜNCELLEŞTİRME

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 fetch 
   

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

   git diff master Origin/master 
   

3. Bu güncellemelerden memnunsanız, birleştirin:

   git pull
   

Notlar:

2. Adımda: yerel ve uzaktan kumandalar arasındaki farklar hakkında daha fazla bilgi için, bkz .: Yerel bir git dalı uzak dalıyla nasıl karşılaştırılır?

3. Adımda: Burada bir git rebase Origin yapmak muhtemelen daha doğrudur (örneğin hızlı değişen bir depoda). Başka bir cevapta @Justin Ohms yorumu bölümüne bakın.

Ayrıca bakınız: http://longair.net/blog/2009/04/16/git-fetch-and-merge/

 git-pull - Başka bir depodan veya yerel bir şubeden alın ve birleştirin 
 SYNOPSIS 

 git pull… 
 AÇIKLAMA 

 Verilen parametreleri kullanarak git-getirme işlemini yapar, ve 
 alınan kafa (lar) ı geçerli dalda birleştirmek için git-merge çağırır. --Rebase ile git-merge .
.__ yerine git-rebase 
 Çağırır. (geçerli dizin) <deposu> olarak yerel depodan 
 'a çekin - yerel şubeleri mevcut konumla birleştirirken yararlıdır. ve altında bulunan git-merge 
, git-fetch ..__ için verilen seçeneklerden önce verilmelidir.

Tarihlerin birleştirilmesini istersen çekeceksin, bazı insanlar buradaki bazı makaleleri etiketlerken, sadece 'cenneti istiyorsan' getirecektin.

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

Bu Origin adı verilen uzak bir depo ve master adı verilen bir dalın uzak dalı Origin/master izlemesi için bir örnektir:

git checkout master                                                  
git fetch                                        
git diff Origin/master
git rebase Origin master

Kısa ve kolay cevap, git pull 'un basitçe git fetch ve ardından git merge olduğu şeklindedir.

git pull 'nun beğenip beğenmemek de otomatik olarak birleştirilecek olacağını unutmamak çok önemlidir. Bu elbette birleştirme çatışmalarına neden olabilir. Diyelim ki uzaktan kumanda Origin ve şubeniz master. Çekmeden önce git diff Origin/master yaparsanız, olası birleştirme çatışmaları hakkında bir fikriniz olmalı ve yerel şubenizi buna göre hazırlayabilirsiniz. 

Çekme ve itme işlemine ek olarak, bazı iş akışları , bağlantılı makaleden parola çevirdiğim bunun gibi git rebase işlevini de içerir:

git pull Origin master
git checkout foo-branch
git rebase master
git Push Origin foo-branch

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

Bu potansiyel olarak tehlikeli bir çalışma şeklidir. Yeniden yazıyor tarihçeyi yayınladığınızda iyiye işaret etmiyor geçmişi. zaten. Git-rebase (1) .__ 'ı okumadığınız sürece bu seçeneği kullanmayın. dikkatlice.

OK, işte git pull ve git fetch hakkında bazı bilgiler var, bu yüzden gerçek farkları anlayabilirsiniz ... birkaç basit kelimeyle, fetch en son verileri alır, ancak kod değişmez ve devam etmez geçerli yerel şube kodunuzu bozmak için, ancak pull 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 refs ve objects öğelerini ve tüm yeni şubeleri kendi yerel deponuza indirir ...

Bir veya daha fazla .__ 'dan dallar ve/veya etiketler (toplu olarak "refs") getirin. diğer depoları, bunların tamamlanması için gerekli olan nesnelerle birlikte. geçmişleri. Uzaktan izleme dalları güncellenmektedir (bu davranışı kontrol etme yöntemleri için aşağıdaki açıklamaları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 dallara işaret etmeyen etiketleri alabilirsiniz içinde de.

git fetch, adlandırılmış tek bir havuzdan veya URL'den veya birkaç havuzdan bir kerede verilirse ve bir uzaktan kumanda. yapılandırma dosyasına giriş. (Bkz. Git-config 1 ).

Hiçbir uzaktan belirtilmediğinde, varsayılan olarak Origin uzaktan kumandası .__ olacaktır. Geçerli için yapılandırılmış bir yukarı akış şubesi olmadıkça kullanılır. dalı.

Alınan reflerin isimleri, nesne isimleri ile 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 çekme

Yerelde uzak ile geçerli dalı arasındaki değişiklikleri uygular ...

Uzak bir depodan mevcut şubedeki değişiklikleri içerir. Varsayılan modda, git çekme, git getirme için kısa yoldur, ardından git FETCH_HEAD birleştirme.

Daha doğrusu, git çekme verilen parametreleri ve .__ ile git fetch'i çalıştırır. Alınan dal başlarını akıntıya birleştirmek için git birleştirme çağırır. dalı. --Rebase ile, git birleştirme yerine git rebase'i çalıştırır.

uzak bir havuzun adı olmalıdır. git-getir 1 . isteğe bağlı bir uzaktan referans ref (örneğin, bir etiketin adı) veya hatta ilgili .__ ile ref'lerin bir koleksiyonunu adlandırabilir. uzaktan izleme dalları (örneğin, refs/heads/: refs/uzaktan/Origin /), ancak genellikle uzak havuzdaki bir şubenin adıdır.

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

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

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

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

Bonus:

Yukarıdaki cevaplardaki "çekme ve al" ifadesinde, ilginç bir numarayı 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 otomatik olarak senkronize edecek (getirme + birleştirme ile) ve taahhüdünüzü git günlüğünde en üste yerleştirecektir. Manuel çekme/birleştirme konusunda endişelenmenize gerek yok.

Ayrıntılara bakın: http://gitolite.com/git-pull--rebase

Bunları 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 tam olarak emin değilim, bu yüzden herhangi bir hata bulursanız lütfen yorum yapın.

                                         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.

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

• Performans (ağ üzerinden sıkıştırmaya çalışmadan tüm taahhütler ve mesajlar arasında gezin)
• Geri bildirim yerel deponuzun durumu hakkında (örneğin, Atlassian's SourceTree kullanıyorum; bu, bana Köken'le karşılaştırıldığında ileride mi yoksa arkada mı işlem yaptığımı gösteren bir ampul verir.) Bu bilgiler GIT FETCH ile güncellenebilir. ).

Bununla da mücadele ettim. Aslında ben de 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.

Bir getirme ile üç repo:

---------------------     -----------------------     -----------------------
- 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+               -
---------------------     -----------------------     -----------------------

Bir çekme ile üç depo

---------------------     -----------------------     -----------------------
- 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+               -
---------------------     -----------------------     -----------------------

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

GIT Fetch ve GIT Pull arasındaki fark, şu senaryo ile açıklanabilir: (Resimlerin kelimelerden daha yüksek sesle konuşmasını unutmayın !, resimsel sunum sağladı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 modülleri değiştirmek/eklemek için bu yerel şube üzerinde çalışmalı ve daha sonra ana şubeye geri dönmelidir.

Bu nedenle, yerel deponuzda ana projeye yer verdiğinizde iki Şubenin İlk Durumu böyle olacaktır - (A, B ve C projenin tamamlanmış halidir)

Şimdi, yeni modül üzerinde çalışmaya başladınız (varsayalım ki D) ve D modülünü tamamladığınızda, ana şubeye itmek istiyorsunuz, Fakat bu arada, ekip arkadaşlarınızdan birinin yeni bir modül geliştirdiği E, F ve değiştirilmiş C.
Bu yüzden, şimdi olan şey, yerel deponuzun projenin orijinal ilerlemesinin gerisinde kalmaması ve bu nedenle ana dalda yaptığınız değişikliklerin çakışmasına neden olabilir ve Modül D'nin arızalanmasına neden olabilir.

Bu tür sorunlardan kaçınmak ve projenin orijinal ilerleyişine paralel olarak çalışmak, onların iki yolu:

1. Git Fetch- Bu, yerel şubenizde bulunmayan Menşe/ana şube projesinde yapılan tüm değişiklikleri indirecektir. Ve Git Merge komutunun, havuzunuza veya şubenize getirilen değişiklikleri uygulamasını bekleyecektir.

Şimdi dosyaları, havuzunuza eklemeden önce dikkatlice izleyebilirsiniz. Ayrıca, gerekirse D nedeniyle gerekirse C öğesini de değiştirebilirsiniz.

2. Git Pull- Bu yerel şubenizi Origin/ana şubeyle güncelleyecektir, yani aslında ne yapar? Git Fetch ve Git'in birbiri ardına birleşmesidir .Ancak bu, Uyuşmazlıklara Sebep Olabilir) bu yüzden Git Pull'ı temiz bir kopya ile kullanmanız önerilir.

Biz sadece diyoruz:

git pull == git fetch + git merge

git pull kullanıyorsanız, verileri yerel olarak birleştirmenize gerek yoktur. git fetch kullanıyorsanız, yerel makinenize en son kodu almak için git merge komutunu çalıştırmanız gerekir. Aksi takdirde, yerel makine kodu birleştirme olmadan değiştirilemez. 

Bu yüzden Git Gui'de, getirdiğiniz zaman, verileri birleştirmek zorundasınız. Getir kendini yerelde kod değişiklikleri yapmaz. Kodu güncellediğinizde getirerek kontrol edebilirsiniz. Bir kez alın ve görün; Kod değişmeyecek. Sonra birleşirsiniz ... Değiştirilen kodu göreceksiniz.

git fetch kodu uzak sunucudan yerel deponuzdaki izleme dallarına çeker. Eğer kumandanız Origin (varsayılan) olarak adlandırılmışsa, o zaman bu dallar Origin/ içinde olacaktır, örneğin Origin/master, Origin/mybranch-123, vs. bu şubelerin sunucudan yerel kopyalarıdır.

git pull, bir git fetch yapar, ancak sonra ayrıca, izleme dalındaki kodu o dalın geçerli yerel sürümüne birleştirir. Henüz bu değişikliklere hazır değilseniz, önce sadece git fetch.

git fetch uzaktaki dalları alır, böylece geçerli dalda git diff veya git merge yapabilirsiniz. git pull, geçerli dal tarafından izlenen uzak öbek üzerinde getirme işlemini çalıştırır ve sonucu birleştirir. Uzak şubede yerel şubenizle birleştirme yapmadan herhangi bir güncelleme olup olmadığını görmek için git fetch kullanabilirsiniz.

Git Al

Yerel şubenizdeki değişiklikleri Origin'den alım yoluyla indirin. Getirme işlemi, diğerlerinin yapmış olduğu tüm taahhütler için uzak repodan sorar, ancak yerel reponuzda yoktur. Getirme bu taahhütleri indirir ve yerel depoya ekler.

Git Birleştirme

Birleştirme komutunu kullanarak getirme 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 korur, böylece şubenizi Push ile paylaştığınızda Git, başkalarının değişikliklerinizi nasıl birleştirebileceğini bilir.

Git Çek

Birbirine getirme ve birleştirme, her ikisini bir araya getiren bir komutun yaratılması için yeterince sık çalışır. Çekme bir indirme işlemi yapar ve indirilen taahhütleri yerel şubenize eklemek için birleştirme yapar.

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

git pull uzak bir daldan çeker ve birleştirir.

git fetch yalnızca uzaktaki şubeden alır, ancak birleşmez

yani, git pull = git + git git birleştirme ...

Git, yeni taahhütlerin ardından kronolojik olarak daha eski taahhütlerin uygulanmasına izin verir .. __ Bu nedenle, depolar arasında taahhütlerin devredilmesi iki aşamaya ayrılır:

1. Yeni şubenin uzak şubeden kopyalanması, yerel uzak deponun içindeki bu uzak şubenin kopyasına. 

   (repo işlemi için repo) [email protected] >> remote/Origin/[email protected]

2. Yeni taahhütleri yerel şubeye entegre etmek

   (repo içi işlem) remote/Origin/[email protected] >> [email protected]

2. adımı yapmanın iki yolu vardır.

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ştirip çatalı kapatın. 
2. Son ortak atadan sonra yeni komisyonlar ekleyin ve yeniden yerel depoya özgü taahhütler uygulayın.

git terminolojisinde, adım 1 git fetch, adım 2 ise git merge veya git rebase'dur.

git pull, git fetch ve git merge şeklindedir.

git pull ve git fetch arasındaki fark nedir?

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

git fetch, uzak havuzdaki yerel kopyanızı güncel tutar. Örneğin, uzak havuzunuz GitHub ise - uzak havuzda yapılan değişiklikleri yerel havuzunuza uzak havuza getirmek isteyebilirsiniz. Bu, karşılaştırma veya birleştirme gibi işlemleri gerçekleştirmenize olanak sağlar.

Öte yandan git pull, uzak havuzdaki değişiklikleri kendi kodunuzu tuttuğunuz yere indirecektir. Tipik olarak, git pull önce uzak havuzun yerel kopyasını güncellemek için bir git fetch yapar ve ardından değişiklikleri kendi kod havuzunuzda ve muhtemelen çalışan kopyanızda birleştirir. 

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, fakat otomatik olarak birleşmeyecek . git fetch Origin mastergit log -p master..Origin/mastergit merge Origin/master

    Yukarıdaki komutlar, ana şubenin en son sürümünü Origin'den uzaktan kumandadan Origin ana şubesine indirme anlamına gelir. Ve sonra yerel ana dal ile Origin ana dalını karşılaştırır. Sonunda birleş. 

2. git pull: Git uzaktan kumandadan en son sürümü alacak ve yerel ile birleşecek.

    git pull Origin master

    Yukarıdaki komut git fetch ve git merge ile aynıdır. Uygulamada, git fetch belki daha güvenlidir çünkü birleşmeden önce değişiklikleri görebilir ve birleştirip birleştirmeyeceğimize karar verebiliriz.

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

git fetch yerel şubelerde değişiklik yapmaz.

İstenen proje için ayarlanmış bir uzaktan kumandanın bulunduğu yerel bir havuzunuz varsa, git getir'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 alma değişikliklerini dahil etmek için uzak bir dalı eşleştirilmiş bir yerel dalla birleştirmeniz gerekir. github'dan

Aslında Git, kendi kodunuzun ve Uzak deponun bir kopyasını saklar.

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

git pull komutu uzak havuzdaki değişiklikleri kendi kodunuzu tuttuğunuz yere getirir. Normalde, git pull bunu, önce uzak havuzun yerel kopyasını güncellemek için bir 'git getirme' yaparak yapar ve ardından değişiklikleri kendi kod havuzunuzda ve muhtemelen çalışan kopyanızda birleştirir.

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

git pull komutu aslında git fetch için bir shortcut __, ardından yapılandırmanıza bağlı olarak git birleştirme veya git rebase komutunu izler. Git deponuzu yapılandırabilirsiniz, böylece git pull , rebase tarafından takip edilen bir alma işlemidir.

Yeni başlayanlar için basit bir Grafik Gösterimi,

i̇şte,

git pull  

kodu depodan alacak ve yerel ile yeniden rebase ... git git yeni yaratma olasılığı vardır.

ama içinde 

git getir 

kodu depodan alır ve git rebase kullanarak tekrar el ile yeniden yapılandırmamız gerekir

örneğin: Sunucu ana sisteminden alıp yerel ana sistemime yeniden yükleyeceğim.

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

git pull Origin master

here Origin uzaktaki deponuz master şubeniz

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

git fetch Origin master

origin'den sunucu değişiklikleri alacak. ve siz kendi başınıza yeniden başlatana kadar yerelinizde olacak. kodları kontrol ederek çatışmaları elle düzeltmemiz gerekir.

git rebase Origin/master

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

git pull = git fetch + git merge 

From Pro Git § 2.5 Git Temelleri - Uzaktan Kumandalarla Çalışma: Uzaktan Kumandalardan Alma ve Çekme :

fetch komutunun verileri yerel deponuza çektiğini unutmamak önemlidir - öyle değildir. çalışmalarınızdan biriyle otomatik olarak birleştirin veya ne olduğunuzu değiştirin. şu anda üzerinde çalışıyor. El ile işinizde birleştirmek zorundasınız hazır olduğunuzda.

Uzak bir şubeyi izlemek üzere ayarlanmış bir şubeniz varsa, Bir uzaktan otomatik olarak almak ve sonra birleştirmek için git pull komutu. şubenize geçerli şubenize Bu daha kolay veya daha fazla olabilir. Sizin için konforlu iş akışı; ve varsayılan olarak, git clone komutu uzaktan kumandayı izlemek için yerel ana şubenizi otomatik olarak ayarlar. Klonladığınız sunucudaki ana dalın (kumandanın bir.. ana dalına sahip olduğunu varsayarsak). git pull komutunu çalıştırmak genellikle 'Dan veri alır. ilk klonladığınız ve otomatik olarak birleştirmeye çalıştığınız sunucu. üzerinde çalışmakta olduğunuz koda.

git çekme 

Tek bir komut kullanarak iki işlevi yerine getirir.

Uzak şubeye yapılan tüm değişiklikleri getirir ve ardından bu değişiklikleri yerel şubenizde birleştirir. Ayrıca --rebase'i geçerek çekme davranışını da değiştirebilirsiniz. Birleştirme ve rebase arasındaki fark okunabilir burada

git getir

Git getir git git çalışmasının sadece yarısını yapar. Uzaktan değişiklikleri yerel deponuza getirir, ancak bunları şubelerinize uygulamaz. Bu değişiklikleri açıkça uygulamanız gerekir. Bu şöyle yapılabilir:

git fetch
git rebase Origin/master

Kişi git doğasının akılda tutulması gerekir. Uzaktan kumandalar ve yerel şubeleriniz var (mutlaka aynı değil). Diğer kaynak kontrol sistemlerine kıyasla bu biraz şaşırtıcı olabilir. 

Genellikle bir uzaktan kumandayı satın aldığınızda, uzaktan kumandayı izleyen yerel bir kopya oluşturulur. 

git fetch uzak şubeyle çalışacak ve bilgilerinizi güncelleyecektir. 

Aslında, diğer SWE'lerin aynı şubede çalışıyor olması ve nadiren küçük bir dev - bir şubede - bir proje senaryosunda olması durumudur.

Yerel şubedeki işiniz hala sağlam. Değişiklikleri yerel şubenize getirmek için, değişiklikleri uzak şubeden birleştirmek/yeniden düzenlemek zorundasınız.

git pull bu iki adımı aynen yapar (yani birleştirme yerine yeniden oluşturmak için rebreb)

Yerel geçmişiniz ve uzak geçmişiniz çakışıyorsa, git sırasında birleştirme işlemini yapmanız gerekecektir. Değişikliklerinizi yayınlamak için düğmesine basın.

Bu nedenle, gerçekten çalışma ortamınızın doğasına bağlıdır ve ne kullanılacağını tecrübe edin.

Git git kopya kağıdı : 

git fetch <remote> // Download all changes from <remote>, but don't integrate into HEAD
git pull <remote> <branch> // Download changes and directly merge/integrate into HEAD

Basitçe söylemek gerekirse, Internet bağlantısı olmayan bir uçağa atlamak üzereyseniz ... ayrılmadan önce sadece git fetch Origin <master> yapabilirsiniz. Tüm değişiklikleri bilgisayarınıza getirir, ancak yerel gelişim/çalışma alanınızdan ayrı tutar.

Uçakta, yerel çalışma alanınızda değişiklikler yapabilir ve ardından bunları Internet’e bağlanmadan, birleştirme çatışmalarını çözdüğünüzle birleştirip çözebilirsiniz. Ve birileri uzak havuzda yeni çelişkili değişiklikler yapmamışsa, o zaman hedefe vardığınızda bir kez git Push Origin <branch> yapar ve kahve alırsınız.

Bu müthiş Attlassian öğretici :

git fetch komutu, uzak bir depodan yerel depoya gönderdiğiniz dosyaları, dosyaları ve referansları indirir.

Getirmek, başkalarının başkalarının ne üzerinde çalıştığını görmek istediğinizde yaptığınız şeydir. Merkezi geçmişin nasıl ilerlediğini görmenize izin veren SVN güncellemesine benzer, ancak değişiklikleri havuzunuzda birleştirmeye zorlamaz. Git getirilen içeriği mevcut yerel içerikten olduğu gibi ayırır, yerel geliştirme çalışmanıza kesinlikle etkisi yoktur . Alınan içeriğin, git checkout komutu kullanılarak açıkça kontrol edilmesi gerekir. Bu, yerel depoya entegre etmeden önce komisyonları incelemenin güvenli bir yolunu getirir.

Uzak bir depodan içerik indirirken, görevi yerine getirmek için git pull ve git fetch komutları kullanılabilir. İki komutun git fetch 'güvenli' versiyonunu düşünebilirsiniz. Uzaktaki içeriği indirecek, ancak yerel çalışmanızın çalışma durumunu güncellemeyecek ve mevcut çalışmanızı sağlam tutacaktır. git pull daha agresif bir alternatiftir, aktif yerel şube için uzak içeriği indirir ve hemen yeni uzak içerik için bir birleştirme taahhüdü oluşturmak üzere derhal git merge işlemini gerçekleştirir. Eğer devam etmekte olan değişiklikleriniz varsa, bu çatışmalara yol açacak ve birleşme anlaşmazlığı çözüm akışını başlatacak.

git pull ile:

• Herhangi bir yalıtım alamadın.
• Yerel gelişiminize etki eder.
• Açıkça kontrol edilmesine gerek yok. Çünkü dolaylı olarak bir git merge yapar.
• Temelde güvenli değil. Agresif.
• git fetch öğesinin aksine yalnızca .git/refs/remotes öğenizi etkilediği yerde, git çekme işlemi hem .git/refs/remotes hem de .git/refs/heads/

Hmmm ... peki çalışma kopyasını git fetch ile güncellemiyorsam, o zaman nerede değişiklik yapıyorum? Git getirme yeni taahhütleri nerede saklar?

Harika soru Çalışma kopyanızdan izole edilmiş bir yere koyar. Ama yine nerede? Hadi bulalım.

Proje dizininizde (yani, git komutlarınızı nerede yaparsınız) yapın:

1. ls. Bu dosya ve dizinleri gösterecektir. Harika bir şey değil, biliyorum.

2. Şimdi ls -a yapın. Bu, dot files , yani, . ile başlayan dosyaları gösterecektir. Daha sonra: .git isimli bir dizin görebileceksiniz.

3. cd .git yapın. Bu açıkça dizini değiştirecek.
4. Şimdi eğlenceli kısım geliyor; ls yapın. Bir dizin listesi göreceksiniz. refs öğesini arıyoruz. cd refs yapın.
5. Tüm dizinlerin içinde ne olduğunu görmek ilginç, ama ikisine odaklanalım. heads ve remotes. İçlerinde de kontrol etmek için cd kullanın.
6. Yaptığınız HERHANGİ git fetch, /.git/refs/remotes dizinindeki öğeleri güncelleyecektir. /.git/refs/heads dizinindeki hiçbir şeyi güncellemez.
7. Herhangi bir git pull, önce git fetch işlevini yapar, /.git/refs/remotes dizinindeki öğeleri güncelleştirir, sonra yerel konumunuzla birleşir ve sonra içindeki başlığı değiştirir /.git/refs/heads dizini.

Çok iyi ilgili bir cevap da 'Git getirme' kendini nerede yapar?) 'Da bulunabilir..

Ayrıca Git şube adlandırma kuralları yazısından "Slash notation" ifadesini arayın. Git'in işleri farklı dizinlere nasıl yerleştirdiğini daha iyi anlamanıza yardımcı olur.

Anladığım kadarıyla 

Git pull - Belirtilen bir uzaktan kumandadan aşağı çeker (Kullanıcı tarafından belirtilen) ve onu anında üzerinde bulunduğumuz bir dalda birleştirir. Temel olarak, Al ve Birleştir komutlarının bir karışımıdır.

Git Fetch - Pull ile aynıdır, ancak herhangi bir birleşme yapmaz. Böylece, birleştirmeden önce dosyaları dikkatle izleyebilirsiniz. 

Bu url daha fazla anlama için yardımcı olmalıdır: Git çekme, git getir ve git klonu (ve git rebase) arasındaki fark.

Kısacası ve basit terimlerle:

git fetch: Yeni şeyler olup olmadığına bakın.

git pull: Yeni eşyaları al ve eşyalarının üzerine koy. 

Cevapların çoğunun farkı çok iyi cevapladığına inanıyorum. Bunun yerine ne zaman kullanılacağını vurgularım.

Getirmek, diğer geliştiricilerin güncellemelerini almanız gerektiğinde, ancak çalışmanızı engelsiz bir şekilde sürdürmek istediğinizde faydalı olabilir. Sık sık çevrimdışı olmak ve çalışmak isteyenler, çevrimiçi oluncaya kadar en son güncellemeyi almak için fetch öğesini kullanır. Daha sonra değişiklikler konusunda rahat olduğu zaman, şubeden gelenleri çalışma alanına dahil eder.

Oysa çevrimiçi çalışan ve değişikliklerinden çok emin olan ve en son kodu ve merge kodunu hemen almak isteyen insanlar pull işlevini kullanıyor. En son güncellemeleri kontrol etmek için GitHub web sitesinden kontrol ediyorum ve her zaman çevrimdışı çalışıyorum çünkü nadiren fetch kullanıyorum. Bahsettiğim gibi yukarıdaki senaryoyu kullanmış olabilirsiniz.

Git Al

Bir git repository dosyasındaki en son güncellemeler hakkında bilgi sahibi olmanıza yardımcı olur. Diyelim ki GitFlow kullanarak bir takımda çalışıyorsunuz, burada birden fazla branches (özellik) üzerinde çalışan ekip. git fetch --allcommand ile branches içindeki tüm yeni repository öğelerini tanıyabilirsiniz.

Çoğunlukla git fetch, git reset ile birlikte kullanılır. Örneğin, tüm yerel değişikliklerinizi mevcut havuz durumuna geri almak istiyorsunuz.

git fetch --all // get known about latest updates
git reset --hard Origin/[branch] // revert to current branch state

Git çekme

Bu komut branch'nızı geçerli repositorybranch durumuyla günceller. GitFlow ile devam edelim. Birden fazla özellik branchesmerged dalına develop oldu ve proje için yeni özellikler geliştirmek istediğinizde branch geliştirmeye gitmelisiniz ve mevcut developbranch durumunu görmek için bir git pull yapmalısınız.

GitFlow Belgeleri https://Gist.github.com/peterdeweese/4251497

Git getir, uzak havuzun kataloğunu bulunduğunuz yerle senkronize eder. Dosyadan/kod değişikliklerinden uzaktaki yerel şubenize birleştirme yapmaz.

Git pull, geçerli yerel şubenizle ilgili değişiklikleri indirir ve sonra birleştirir.

En çok cevap verildiği gibi, hiç şüphesiz git-pull git-fetch artı birleştirmedir. Şunu belirtmek isterim:

birleştirme işleminden önce kontrol etmek istediğinizde --- kullanmalısınız git-fetch ve ardından git-pull.

cronjob öğesinde, aşağıdaki komut dosyasında gösterildiği gibi yapmak yararlıdır:

#!/bin/sh

git fetch upstream
if [ `git rev-list HEAD...upstream/master --count` -eq 0 ]
then
    echo "all the same, do nothing"
else
    echo "update exist, let's pull"
    git pull upstream master
    git Push Origin master
fi