'git pull'과 'git fetch'의 차이점은 무엇입니까?


11912

의 차이점은 무엇입니까 git pull와는 git fetch?


364
나는 자식에 대한이 잘 쓰여지는 기사가 가져오고 발견 자식 풀 그것의 가치가 읽기 : longair.net/blog/2009/04/16/git-fetch-and-merge
마르코스 올리베이라

51
우리의 대체 접근법은 git fetch; git reset --hard origin/master워크 플로우의 일부 가되었습니다 . 로컬 변경 사항을 없애고 마스터 BUT으로 최신 상태를 유지하지만 현재 변경 사항에 대한 새로운 변경 사항을 가져 와서 혼란스럽게 만들지 않습니다. 우리는 한동안 사용해 왔으며 기본적으로 실제로 훨씬 안전하다고 느낍니다. 진행중인 작업을 먼저 추가 / 커밋 / 보관하십시오!
Michael Durrant

26
git stash를 올바르게 사용하는 방법을 알고 있어야합니다. 'pull'과 'fetch'에 대해 묻는다면 아마도 'stash'도 설명이 필요할 것입니다.
Henry Heleine

36
Mercurial에서 온 많은 사람들은 "git pull"을 계속 사용하며 "hg pull"과 동일하다고 생각합니다. 아니에요 Git의 "hg pull"은 "git fetch"입니다.
Shultz Serge 2016 년

8
git fetch 명령 분기를 사용하여 업데이트 된 코드를 가져오고 로컬에서 새로 추가 된 분기를 가져옵니다. git pull 명령은 현재 분기의 업데이트 된 코드 만 가져옵니다
Kartik Patel

답변:


9915

가장 간단한 용어로 git pulla git fetch뒤에을 붙 git merge입니다.

git fetch언제든지 아래에서 원격 추적 분기를 업데이트 할 수 있습니다 refs/remotes/<remote>/.

이 작업은 아래의 자체 로컬 지점 refs/heads을 변경하지 않으며 작업 사본을 변경하지 않고 안전하게 수행 할 수 있습니다. 나는 사람들 git fetch이 백그라운드에서 cron 작업을 정기적으로 실행하는 것을 들었습니다 (이 작업을 권장하지는 않지만).

A git pull는 원격 버전으로 로컬 지점을 최신 상태로 유지하고 다른 원격 추적 지점도 업데이트하는 방법입니다.

Git 문서 – git pull :

기본 모드에서는 git pull약어가 git fetch뒤에옵니다 git merge FETCH_HEAD.


326
""git pull "은 리포지토리를 최신 상태로 유지하기 위해 수행하는 작업입니다"<-페치로 리포지토리 업데이트가 이미 수행되지 않았습니까? 이것이 원격 지사와 함께 로컬 지사를 최신 상태로 유지한다는 것을 의미하지 않습니까? 병합 : 원격 분기를 해당 분기의 로컬 사본과 병합합니까, 아니면 정확히 무엇을 병합합니까?
Albert

194
@Albert : 응, 이상하게 말이야. git pull항상 현재 분기 로 병합됩니다 . 그래서 당신은 당신이 끌어하고자하는 지점 선택 에서 , 그리고 현재 브랜치로 가져옵니다. 에서 분기 로컬 또는 원격 일 수있다; 등록되지 않은 원격 브랜치 일 수도 있습니다 git remote(즉, git pull명령 줄 에서 URL을 전달 함 ).
직관

129
@espertus : 아니요. 푸시는 자동으로 병합을 수행하지 않습니다. 사용자는 로컬, 어떤 병합 충돌을 해결, 풀에 예상되는 다음 원격으로 다시 밀어 넣습니다.
Greg Hewgill

33
내가 /home/alice/하고 할 git fetch /home/bob경우 후속 매개 변수로 전달해야 할 매개 변수는 무엇 git merge입니까?
ripper234

106
힘내를 배우는 사람들에게 참고 : pull실제로 에뮬레이션 할 수 없습니다 fetch플러스 merge. 방금 원격 분기 포인터 만 변경되는 변경 사항을 가져 와서 merge아무것도하지 않았습니다. pull반면에 내 추적 지점을 빨리 감습니다.
Roman Starkov

2170
  • pullGit 을 사용 하면 Git은 자동으로 작업을 수행합니다. 컨텍스트에 민감 하므로 Git은 가져온 커밋을 현재 작업중인 브랜치에 pull 병합합니다. 커밋을 먼저 검토하지 않고 커밋을 자동으로 병합합니다 . 지점을 면밀히 관리하지 않으면 빈번한 충돌이 발생할 수 있습니다.

  • 당신이 때 fetch, 힘내 현재 지점과에 존재하지 않는 대상 지점에서 어떤 커밋 수집 로컬 저장소에 저장합니다 . 그러나 현재 분기와 병합하지 않습니다 . 리포지토리를 최신 상태로 유지해야하지만 파일을 업데이트하면 손상 될 수있는 작업을 수행하는 경우 특히 유용합니다. 커밋을 마스터 브랜치에 통합하려면을 사용 merge합니다.


34
동의, 큰 의견. 내가 git pull을 싫어하는 이유입니다. 개정 도구가 코드를 편집하도록하는 것이 언제 합리적입니까? 그리고 두 파일을 병합하는 것이 아닌가? 이 두 편집 내용이 파일에서 물리적으로 분리되었지만 논리적으로 우연히 발생하면 어떻게됩니까?
Lee Dixon

126
@elexhobby 짧은 입력 git fetch.git/디렉토리 (AKA : 로컬 저장소) 만 업데이트 하고 외부 .git/(AKA : 작업 트리)는 업데이트 하지 않습니다 . 로컬 브랜치는 변경하지 않으며 만지지 master않습니다. 그래도 터치합니다 remotes/origin/master(참조 git branch -avv). 리모컨이 더 있으면를 사용해보십시오 git remote update. 이것은이다 git fetch하나의 명령에있는 모든 리모트합니다.
티노

24
@Tino 당신의 것이 가장 중요한 포인트입니다. 사람들은 "원격"브랜치가 실제로 여러 해시로 저장된다는 것을 알지 못할 수 있습니다 .git/refs/remotes/origin/.
Chris

13
가져올 때 Git은 현재 브랜치에 존재하지 않는 대상 브랜치에서 커밋을 수집하여 로컬 리포지토리에 저장합니다 .
아렉 쿠스

13
@ 티노 내가 아직도 이해하지 못하는 것은 ... 요점이 뭐야? 업데이트 만하는 경우 인출을 사용하는 이유는 무엇 .git입니까? 의도 된 이점은 무엇이며 그 이후에해야 할 일은 무엇입니까?
BadHorsie

1210

git의 디자인 철학과 SVN과 같은 전통적인 소스 제어 툴의 철학을 대조하는 것이 중요합니다.

Subversion은 클라이언트 / 서버 모델로 설계 및 제작되었습니다. 서버 인 단일 리포지토리가 있으며 여러 클라이언트가 서버에서 코드를 가져 와서 작업 한 다음 서버로 다시 커밋 할 수 있습니다. 클라이언트는 작업을 수행해야 할 때 항상 서버에 연결할 수 있다고 가정합니다.

Git은 중앙 저장소가 없어도보다 분산 된 모델을 지원하도록 설계되었습니다 (원하는 경우 확실히 사용할 수 있음). 또한 git은 클라이언트와 "서버"가 동시에 온라인 일 필요가 없도록 설계되었습니다. Git은 신뢰할 수없는 링크에있는 사람들이 이메일을 통해 코드를 교환 할 수 있도록 설계되었습니다. 완전히 분리 된 상태로 작업하고 CD를 구워서 git을 통해 코드를 교환 할 수 있습니다.

이 모델을 지원하기 위해 git은 코드와 함께 로컬 리포지토리와 원격 리포지토리의 상태를 미러링하는 추가 로컬 리포지토리를 유지 관리합니다. 원격 저장소의 사본을 로컬로 유지함으로써 git은 원격 저장소에 도달 할 수없는 경우에도 필요한 변경 사항을 파악할 수 있습니다. 나중에 변경 사항을 다른 사람에게 보내야 할 때 git은 변경 사항을 원격 저장소에 알려진 특정 시점에서 변경 세트로 전송할 수 있습니다.

  • git fetch "원격 저장소의 로컬 사본을 최신으로 가져 오십시오"라는 명령입니다.

  • git pull "원격 저장소에서 변경 한 내용을 자신의 코드를 유지하는 위치로 가져옵니다."

일반적으로 git pulla git fetch를 수행 하여 원격 저장소의 로컬 사본을 최신 상태로 만든 다음 변경 사항을 자체 코드 저장소 및 작업 사본에 병합합니다.

테이크 아웃은 워크 스테이션에 프로젝트 사본3 개 이상 있다는 것을 명심해야 합니다. 하나의 사본은 자체 커밋 히스토리가있는 자체 저장소입니다. 두 번째 사본은 편집 및 작성중인 작업 사본입니다. 세 번째 사본은 원격 저장소의 로컬 "캐시 된"사본입니다.


75
기술적으로 로컬 및 원격 저장소는 실제로 하나이며 동일합니다. Git에서 저장소는 부모를 가리키는 커밋 의 DAG 입니다. 브랜치는 기술적으로 의미있는 커밋 이름에 지나지 않습니다. 로컬 브랜치와 원격 브랜치의 유일한 차이점은 원격 브랜치에 remoteName/ Git 이 접두사로 붙어 있다는 것 입니다. 일단 Git의 작동 방식을 이해하면 아름답고 간단 합니다. 모든 것이 의미가 있습니다.
Emil Lundberg

13
설명 주셔서 감사합니다. 나는 지금까지 Git이 중앙 저장소를 가질 필요가 없도록 설계되었다는 것을 이해하지 못했습니다. Git을 설명 할 때는 누구나 항상 "DVCS"라고 말하지만, 비교적 새로운 프로그래머라면 그것은 아무 의미가 없습니다. 나는 CVCS를 적이 없으며 다른 사람들과 공동 작업 할 때 Cental 원격 저장소 (예 : Github)와 함께 일한 적이 없으므로 지금까지 Git을 특별하게 만든 이유를 아직까지 이해하지 못했습니다.
Brian Peterson

7
따라서 이것을 바탕으로 왜 크론 작업으로 git-fetch하는 것이 좋은 생각이 아닙니까? 로컬 컴퓨터에서 작업중인 리모컨의 사본을 항상 보관하는 것이 좋습니다. 사실, 지난 24 시간 동안 리모컨을 업데이트했는지 확인하고 인터넷 연결을위한 udev 후크와 연결하는 스크립트를 작성하고 싶습니다.
Brian Peterson

24
cron 작업을하는 것이 좋은 생각이 아닌 한 가지 이유는 종종 새로운 티켓이나 지점 업데이트 작업을 할 때 변경 사항을 가져 오는 것을 좋아합니다. 가져 오는 동안 변경 사항이 적용되지 않으면 동료 프로그래머에게 '이봐 야 했니?' 또한 마지막으로 가져온 이후 리포지토리에서 '떨어짐'이 어느 정도인지 알 수 있습니다. 또한이 저장소에서 현재 변경되는 양과 속도를 이해하는 데 도움이됩니다.
Michael Durrant

5
@Nabheet 것은 Git이 콘텐츠 지향적이라는 것입니다. 데이터를 한 번만 저장하고 여러 번 가리 킵니다. 그렇기 때문에 Git에서 원본의 여러 커밋조차도 대부분의 객체가 동일하기 때문에 리포지토리의 크기에 큰 영향을 미치지 않습니다.
cst1992

888

다음은 모두가 모두 함께 맞는 방법 올리버 스틸의 이미지 :

여기에 이미지 설명을 입력하십시오

관심이 충분하다면 추가 할 이미지를 업데이트 git clone하고 git merge...


156
와 업데이트 된 이미지 git clone와는 git merge매우 도움이 될 것입니다!
MEMark

20
예, 추가하십시오 git merge- merge별도의 호출 은 원격에서만 병합 pull하기 때문에 호출과 동일하지 않다는 것을 분명히 보여 주어야합니다 pull. 원격 지점에서 가져 오는 원격 지점을 추적하는 로컬 커밋은 무시합니다.
JustAMartin

12
그림은 천 단어의 가치가 있습니다! 복제 및 병합 데이터 흐름이있는 업데이트 된 이미지가 어딘가에 준비되어 있습니까? 이미 다이어그램에있는 것 외에 다른 데이터 흐름이 있습니까?
shikhanshu

10
@Contango 복제 및 병합을 추가하십시오. 나와 같은 초보자에게 도움이 될 것입니다.
임대

11
th3sly와 darkpassenger의 다른 답변 (아래)에 복제 및 병합을 보여주는 두 가지 다이어그램이 있습니다.
intotecho

488

하나의 사용 사례 git fetch 는 다음이 마지막 풀 이후 원격 브랜치의 변경 사항을 알려줄 것입니다 ... 그래서 실제 풀을 수행하기 전에 확인할 수 있습니다. 현재 브랜치 및 작업 사본의 파일을 변경할 수 있습니다.

git fetch
git diff ...origin

diff 명령의 더블 및 트리플 도트 구문에 대해서는 https://git-scm.com/docs/git-diff 를 참조하십시오.


9
왜 안돼 git diff ..origin?
Erik Kaplun 2012

3
git diff origin과 git diff ..origin은 효과가있는 것 같지만이 이상하지는 않습니다 ...
Marc

19
@Compustretch 공간이 없어야합니다. git diff ...origin상당하는 git diff $(git-merge-base HEAD origin) origin(투시 git diff [--options] <commit>...<commit> [--] [<path>…]kernel.org/pub/software/scm/git/docs/git-diff.html#_description 상이하다) git diff origin; git diff ...originorigin현재 분기에서 분기 된 이후 의 변경 사항을 개념적으로 origin나타내며, 현재 분기에서 분기 된 이후 git diff origin의 변경 사항을 역순으로 포함합니다 origin.
맥스 나나시

2
나 (Windows에서)하지만, 근무에 .. 명령 없음 git diff origin/master언급 한 바와 같이 아래 작품
브라이언 화상

OSX에서 git 2.0.0을 사용하는 것과 같습니다. 이 명령들 중 어느 것도 작동하지 않았습니다. 더 이상 사용되지 않습니까?
K.-Michael Aye

373

차이점이 무엇인지 이해하는 데 약간의 비용이 들었지만 이것은 간단한 설명입니다. master로컬 호스트에는 지점이 있습니다.

저장소를 복제하면 전체 저장소를 로컬 호스트로 가져옵니다. 이것은 그때 당신이 원점 / 마스터 포인터를 HEAD가리키고 마스터가 같은 것을 가리키는 것을 의미합니다 HEAD.

작업을 시작하고 커밋을 수행하면 커밋 HEAD+에 대한 마스터 포인터를 진행시킵니다 . 그러나 원점 / 마스터 포인터는 여전히 복제 할 때의 위치를 ​​가리 킵니다.

차이점은 다음과 같습니다.

  • 그렇게 git fetch하면 원격 저장소 ( GitHub ) 의 모든 변경 사항을 가져 와서 원점 / 마스터 포인터를HEAD . 한편 현지 지사 마스터는 현재 위치를 계속 가리 킵니다.
  • 을 수행하면 git pull기본적으로 (앞서 설명한 바와 같이) 페치를 수행하고 새로운 변경 사항을 마스터 브랜치에 병합하고 포인터를로 이동합니다 HEAD.

14
원산지 / 마스터는 원산지 마스터의 사본 인 로컬 지점입니다. 가져 오면 local : / origin / master가 업데이트됩니다. 일단 git의 모든 것이 브랜치라는 것을 알게되면, 이것은 많은 의미가 있으며 다른 변경 세트를 유지하고, 빠른 로컬 브랜치를 만들고, 병합하고 rebase하고, 저렴한 브랜치에서 많은 가치를 얻는 매우 강력한 방법입니다 모델.
cam8001

3
여전히 혼란 스럽습니다. 나는 git fetch말 그대로 원격 저장소의 변경 사항을 로컬 저장소에 다운로드하지만 커밋하지 마십시오. 즉, 여전히 로컬 저장소에 추가 / 커밋해야합니다.
krb686

3
가져 오기는 원격 / 원점 (github)에서 로컬 원점으로 만 가져옵니다. 그러나 실제 작업 파일과 병합하지는 않습니다. 풀을하면 가져오고 현재 작업 파일로 병합됩니다
Gerardo

223

때때로 시각적 인 표현이 도움이됩니다.

여기에 이미지 설명을 입력하십시오


18
사진이 로컬 리포지토리에도 영향을 미친다는 것을 보여 주어야한다고 생각합니다. 즉, Git pull은 로컬 리포지토리 및 작업 복사본에 영향을 미치는 조합입니다. 지금은 작업 사본에만 영향을 미치는 것 같습니다.
nonopolarity

10
@太極者無極而生합의 - 그것이처럼 보이게하기 때문에이 이미지는 꽤, 오해의 소지가되고 git pull있다 건너 뛰는 물론 부정확 인의 인출.
forresthopkinsa

9
'로컬 리포지토리'와 '작업 복사본'의 차이점은 무엇입니까? 그들은 둘 다 컴퓨터에 로컬 아닌가요?
theITvideos

1
그렇다면 git fetch의 사용법은 무엇입니까? 로컬 리포지토리와 작업 복사본에 어떤 차이가 있는지 확인하는 방법은 무엇입니까?
Vikash

2
@theITvideos 아니오, 그렇지 않습니다. 로컬 저장소는 커밋 할 때 코드가 작동하는 곳입니다 (작업 저장소에서). (누르면 원격 저장소로 이동합니다).
Vikash

219

간단히

git fetch비슷 pull하지만 병합되지 않습니다. 즉, 원격 업데이트를 가져옵니다 (refsobjects)를 오지만 로컬은 동일하게 유지됩니다 (즉, origin/master업데이트되지만 master동일하게 유지됨).

git pull 리모컨에서 아래로 당겨 즉시 합쳐집니다.

git clone 레포를 복제합니다.

git rebase업스트림 브랜치에없는 현재 브랜치의 항목을 임시 영역으로 저장합니다. 이제 브랜치는 변경을 시작하기 전과 동일합니다. 그래서,git pull -rebase 원격 변경 사항을 풀고 로컬 지점을 되 감고 최신 지점이 될 때까지 현재 지점 상단에서 변경 사항을 하나씩 재생합니다.

또한, git branch -a 로컬 및 원격의 모든 브랜치에서 진행중인 작업을 정확하게 보여줍니다.

이 블로그 게시물은 유용했습니다.

git pull, git fetch 및 git clone (및 git rebase)의 차이점-Mike Pearce

및 커버 git pull, git fetch,git clonegit rebase .

====

최신 정보

실제로 이것을 실제로 어떻게 사용하는지 보여주기 위해 이것을 업데이트 할 것이라고 생각했습니다.

  1. 리모컨에서 로컬 저장소를 업데이트하십시오 (하지만 병합하지 마십시오).

    git fetch 
    
  2. 업데이트를 다운로드 한 후 차이점을 살펴 보겠습니다.

    git diff master origin/master 
    
  3. 해당 업데이트에 만족하면 다음을 병합하십시오.

    git pull
    

노트:

2 단계 : 로컬과 원격 간의 차이점에 대한 자세한 내용 은 로컬 git 브랜치를 원격 브랜치와 비교하는 방법을 참조하십시오.

3 단계 : 여기에서 수행하는 것이 더 정확할 것입니다 (예 : 빠르게 변화하는 저장소) git rebase origin. 다른 답변에서 @Justin Ohms 의견 을 참조하십시오 .

참조 : http://longair.net/blog/2009/04/16/git-fetch-and-merge/


1
누군가가 "팁"을 반영하기 위해 로컬 코드를 원한다면을 사용해야합니다 git clone. 마스터가 무엇이고 누군가가 ziphub.com에서 "zip으로 다운로드"를 의미한다고 가정하므로 팁을 따옴표로 묶었습니다.
Chris K

3
git fetch 후 변경 사항에 만족하지 않으면 어떻게됩니까? 다음에 할일?
Kugutsumen

rebase에 대한 당신의 단락은 내가 찾고 있었던 것입니다. 모든 것을 제로화하고 원격에서 업데이트 한 다음 작업 중에 발생한 이전 커밋 위에서 변경 사항재생 하는 것에 대한 전체 아이디어 . 맞다고 가정하는 완벽한 설명. ;)
coblr

178
git-pull-다른 저장소 또는 로컬 브랜치에서 페치 및 병합
개요

자식 풀 ...
기술

주어진 매개 변수로 git-fetch를 실행하고 git-merge를 호출하여 
현재 분기로 헤드를 검색했습니다. --rebase를 사용하면 git-rebase를 호출합니다.
git-merge 대신에.

를 사용할 수 있습니다. (현재 디렉토리)를 가져올 <repository>로
로컬 리포지토리에서-로컬 브랜치를 병합 할 때 유용합니다 
현재 지점으로.

또한 git-pull 자체 및 기본 git-merge에 대한 옵션을 참고하십시오. 
git-fetch에 대한 옵션보다 먼저 제공되어야합니다.

히스토리를 병합하려면 당기고, 누군가가 여기 기사에 태그를 달았으므로 '코즈를 원한다'면 가져옵니다.


5
매우 흥미롭지 만 "코드 만"원하는 유스 케이스를 볼 수는 없습니다. 가져올 때 코드는 어떻게됩니까? 지워졌습니까? 원격 변경은 어떻게됩니까? 병합하지 않으면 코드를 지우지 않고 리포지토리로 어떻게 이동합니까?
e-satis

11
@ e-satis : 원격 지점도 컴퓨터에 로컬로 저장됩니다. 따라서 그렇게하면 git fetch저장소에서 변경 사항을 가져 와서 로컬 원격 지점을 업데이트합니다. 로컬 원격 분기를 추적하는 로컬 분기에는 영향을 미치지 않으므로 작업 복사본에는 영향을 미치지 않습니다. 이제 할 때 merge가져온 변경 사항을 로컬 지점과 병합합니다.
jeffreyveon

fetch 명령의 간단한 사용 사례 : 이전에 fetch를 사용하여 다운로드 했으므로 네트워크 연결 요구 사항없이 최신 로컬 리포지토리에만 액세스하는 병합 또는 코드 검토와 같은 다른 사람의 최근 커밋과 관련된 시간이 오래 걸리는 작업 수행 필요한 모든 것 (예 : 다른 개발자를 방문하고 다른 리포지토리의 네트워크에 연결된 경우) pull 명령은 동일한 커밋을 다운로드하지만 수행하는 병합은 바람직하지 않습니다.
로렌조 가티

163

원격 저장소에서 가져 와서 차이점을 확인한 후 가져 오거나 병합 할 수 있습니다.

이것은 원격 저장소 origin및 지점이라는 예제입니다.master 원격 분기 추적 분기의 예입니다 origin/master.

git checkout master                                                  
git fetch                                        
git diff origin/master
git rebase origin master

35
변경 사항을 이미 가져 왔으므로 풀을 건너 뛰고 마지막 단계로 "git rebase origin"을 수행하고 싶을 것입니다. 그 이유는 가져 오기를 수행 한 이후 누군가가 시간에 변경 사항을 푸시했을 수 있고 diff 검토를 수행했을 때 가져 오지 않았기 때문입니다.
저스틴

158

짧고 쉬운 대답은 해당이됩니다 git pull단순히 git fetch다음git merge .

이 노트에 매우 중요 git pull합니다 자동 여부 좋든 싫든 병합 . 물론 이로 인해 병합 충돌이 발생할 수 있습니다. 리모컨이 origin있고 지사가 있다고 가정 해 봅시다 master. 이 경우 git diff origin/master이전에 당겨, 당신은 잠재적 인 병합 충돌의 몇 가지 아이디어가 있어야하고 그에 따라 해당 지역의 지점을 준비 할 수있다.

당기고 밀는 것 외에도 링크 된 기사에서 다음과 같이 일부 워크 플로우 와 관련 git rebase이 있습니다.

git pull origin master
git checkout foo-branch
git rebase master
git push origin foo-branch

그런 상황에 처하게되면 유혹을받을 수 있습니다 git pull --rebase. 당신이 정말로, 당신이 무엇을하고 있는지 정말로 알고 있지 않다면, 나는 그것에 반대 할 것을 권합니다. 이 경고는의 버전 man페이지 git-pull에서 발췌 한 것입니다 2.3.5.

이것은 잠재적으로 위험한 작동 모드입니다. 기록을 다시 작성하므로 기록을 이미 게시했을 때 제대로 표시되지 않습니다. git-rebase (1)을주의 깊게 읽지 않으면이 옵션을 사용하지 마십시오.


2
@JustinOhms git pull --rebase주어진 상황에서 옳지 않은 것이 있다면, 두 단계로 완료되면 맞습니까? 그것이 옳은 일이라면, 두 단계로 수행하는 것의 이점은 무엇입니까?
Kaz

@Kaz-리베이스가 자동이 아니기 때문에. 먼저 변경 사항을 가져 오면 판단을 할 수 있습니다. 이미 푸시 한 rebasing 기록의 문제는 해결되지 않습니다. 아직 푸시하지 않은 변경 사항을 리베이스하는 것이 안전한지 확인할 수 있습니다.
Justin Ohms

2
@JustinOhms 변경 사항을 리베이스하는 것이 안전한지 어떻게 결정 하시겠습니까? git rebase를 시도하고 엉망이되면 역 추적을 시도합니다.이 경우 git pull --rebase를 수행 할 수도 있습니다. 그러나 다른 방법이 있습니까?
Kaz

3
@KaZ gitk를 사용하면 분기 구조를 시각적으로 볼 수 있습니다. 가져온 헤드와 관련하여 로컬 헤드, 리모콘 및 브랜치 구조의 위치를 ​​보여줍니다. 이렇게하면 이미 리모콘에 푸시 한 항목 이전의 상위 항목을 기반으로 가져온 변경 사항을 리베이스하지 않도록 할 수 있습니다.
저스틴 옴스

rebase아직 푸시하지 않은 로컬 지점에서 작업 할 때 사용 합니다. 원격에있는 지점에서 작업하는 경우 rebase일부 불쾌한 문제가 발생할 수 있으므로 일반을 선호해야합니다 merge.
Justus Romijn

151

OK , 여기에 대한 정보는 git pull하고 git fetch, 당신은 몇 가지 간단한 단어의 실제 차이를 ... 이해할 수 있도록 패치 최신 데이터를 얻을 수 있지만 코드 변경하고 현재 지역의 지점 코드로 혼란에가는 아니지만, GET 코드가 변경되어 로컬 브랜치와 병합되면 다음에 대해 자세히 알아보십시오.

자식 가져 오기

그것은 모든 심판객체 및 새로운 지점을 로컬 리포지토리에 다운로드합니다 ...

히스토리를 완료하는 데 필요한 오브젝트와 함께 하나 이상의 다른 저장소에서 브랜치 및 / 또는 태그 (통칭하여 "참조")를 가져옵니다. 원격 추적 분기가 업데이트됩니다 (이 동작을 제어하는 ​​방법은 아래 설명 참조).

기본적으로 페치되는 히스토리를 가리키는 모든 태그도 페치됩니다. 효과는 원하는 분기를 가리키는 태그를 가져 오는 것입니다.이 기본 동작은 --tags 또는 --no-tags 옵션을 사용하거나 remote..tagOpt를 구성하여 변경할 수 있습니다. 태그를 명시 적으로 가져 오는 참조 스펙을 사용하면 관심있는 분기를 가리 키지 않는 태그를 가져올 수 있습니다.

git fetch는 이름이 지정된 단일 저장소 또는 URL 또는 원격 저장소가있는 경우 여러 저장소에서 한 번에 가져올 수 있습니다. 구성 파일의 항목. (git-config 1 참조 ).

원격이 지정되지 않은 경우 현재 분기에 대해 업스트림 분기가 구성되어 있지 않으면 기본적으로 오리진 원격이 사용됩니다.

페치 된 참조 이름은 이들이 가리키는 오브젝트 이름과 함께 .git / FETCH_HEAD에 기록됩니다. 이 정보는 스크립트 또는 git-pull과 같은 다른 git 명령에 의해 사용될 수 있습니다.


자식 풀

원격 에서 로컬 의 현재 분기 로 변경 사항을 적용합니다 ...

원격 저장소에서 현재 분기로 변경 사항을 통합합니다. 기본 모드에서 git pull은 git fetch의 약어이며 git merge FETCH_HEAD입니다.

보다 정확하게는 git pull은 주어진 매개 변수로 git fetch를 실행하고 git merge를 호출하여 검색 된 분기 헤드를 현재 분기로 병합합니다. --rebase를 사용하면 git merge 대신 git rebase를 실행합니다.

git-fetch 1에 전달 된 원격 저장소의 이름이어야합니다 . 임의의 원격 참조 (예 : 태그 이름) 또는 해당 원격 추적 분기 (예 : refs / heads / : refs / remotes / origin / )가 있는 참조 모음의 이름을 지정할 수 있지만 일반적으로 이름입니다. 원격 저장소의 분기

git-branch --track에 의해 설정된 현재 분기의 "원격"및 "병합"구성에 대한 기본값을 읽습니다.


나는 또한 만드는 시각적 방법을 보여 다음 git fetchgit pull함께 작업을 ...

git pull 및 git fetch


10
이미지가 마음에 들면 git cheat sheet를 살펴보십시오. git cheat sheet는 모든 git 명령과 같은 종류입니다 ... ndpsoftware.com/git-cheatsheet.html
Tom

3
복제도 로컬 리포지토리 (원격에서 모든 기록 복사)에 영향을 미치지 않습니까?
Tom Loredo

135

여기에 이미지 설명을 입력하십시오

이 대화식 그래픽 표현은 자식을 지체하는 데 매우 유용합니다 : http://ndpsoftware.com/git-cheatsheet.html

git fetch원격에서 로컬 리포지토리로 변경 사항을 "다운로드"하면됩니다. git pull변경 사항을 다운로드하여 현재 지점에 병합합니다. "기본 모드에서, git pull대한 속기 git fetch다음에 git merge FETCH_HEAD."


18
사람들은 링크를 클릭하여 다른 열과 상호 작용하십시오. 이 치트 시트는 각 명령의 차이점을 완전히 이해하는 데 가장 적합한 리소스입니다.
M. Luisa Carrión

이 답변은 상단으로 이동해야합니다
Tessaracter

126

보너스:

위의 답변에서 pull & fetch에 대해 흥미로운 트릭을 공유하고 싶습니다.

git pull --rebase

이 위의 명령은 내 자식 생활에서 가장 유용한 명령으로 많은 시간을 절약했습니다.

새 커밋을 서버로 푸시하기 전에이 명령을 시도하면 최신 서버 변경 사항 (페치 + 병합)을 자동으로 동기화하고 커밋을 git log의 맨 위에 놓습니다. 수동 풀 / 병합에 대해 걱정할 필요가 없습니다.

자세한 내용은 http://gitolite.com/git-pull--rebase를 참조하십시오.


4
좋은 팁이지만 rebase가 커밋 해시를 수정하는 새로운 git 사용자에게 언급 할 가치가 있습니다 (서브 버전에서 놀라운 결과를 얻었습니다).
AlexMA

1
당신이 사이에 차이가 무엇인지 설명 할 수 git pullgit pull --rebase?
shaijut

2
위의 답변 에서이 방법에 대한

118

이러한 상황을 파악하기 위해 상황을 시각적으로 표현하고 싶습니다. 다른 개발자들도보고 싶을 수도 있습니다. 나는 그것이 모두 올바른지 완전히 확신하지 못하므로 실수를 발견하면 의견을 말하십시오.

                                         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.

페치 된 미러 미러를 사용하면 다음과 같은 주요 이점이 있습니다.

  • 성능 (네트워크를 통해 압축하지 않고 모든 커밋 및 메시지를 스크롤)
  • 로컬 리포지토리의 상태에 대한 피드백 (예 : Atlassian의 SourceTree을 사용하여 출발지에 비해 앞뒤로 커밋하는지 여부를 나타내는 전구를 제공합니다.이 정보는 GIT FETCH로 업데이트 할 수 있습니다).

git pull병합을 수행 하지 않습니까 ( 예 : 작업중인 사본으로 계속 진행)?
Kamiel Wanrooij 2012 년

좋은 지적, 그렇습니다. 작업 사본에 모든 변경 사항을 넣은 다음 로컬 저장소에 직접 커밋 할 수 있습니다. 영상을 업데이트하겠습니다.
Justus Romijn

@JustusRomijn 풀이 로컬 리포지토리도 업데이트하지 않습니까? 원본과 작업 사본 별표 사이에 별표가 없어야합니까?
user764754

2
@ user764754 당기면 작업 사본에 변경 사항이 적용됩니다 (일부 해결해야 할 충돌이있을 수 있음). 여전히 로컬 저장소에 커밋해야합니다.
Justus Romijn

@JustusRomijn : 일러스트레이션에 감사합니다. 리포지토리 상태에서 reset, cherry pick과 같은 작업의 효과를 보여줌으로써 다이어그램을보다 포괄적으로 만들 수 있다면 좋을 것입니다.
jith912

106

나는 이것으로도 어려움을 겪었다. 사실 나는 정확히 같은 질문에 대한 Google 검색으로 여기에 도착했습니다. 이 모든 대답을 읽으면서 마침내 내 머리에 그림이 그려졌고 2 개의 저장소와 1 개의 샌드 박스 상태와 시간이 지남에 따라 수행되는 작업을보고 내려 놓으려고했습니다. 그래서 여기에 내가 생각해 낸 것이 있습니다. 내가 어딘가에 엉망이되면 나를 수정하십시오.

페치가있는 세 개의 repos :

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

잡아 당기는 3 개의 repos

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

이를 통해 가져 오기가 왜 중요한지 이해할 수있었습니다.


읽기 어려운 것은 아닙니다. 상자는 리포지토리의 상태를 나타내며, 각 행에서 상자의 2 행에서보고 된 작업 후 왼쪽에서 오른쪽으로 시간이 변경됩니다. 레이블 R0n은 git의 태그이며 +가있는 태그는 아직 커밋되지 않은 것입니다. Sanbox는 작업 폴더에 사용되며 커밋 된 항목이 저장되는 repo 폴더와 다릅니다.
user1708042

96

GIT FetchGIT Pull 의 차이점 은 다음 시나리오에서 설명 할 수 있습니다. (그림이 단어보다 크게 말하는 것을 명심하십시오! 그림을 제공했습니다)

팀원들과 함께 프로젝트를 진행하고 있음을 예로 들어 보겠습니다. 따라서 이들은 프로젝트의 하나의 주요 지점이 될 것이며 모든 기고자들은 그것을 자신의 로컬 저장소로 분기 한 다음이 로컬 지점에서 작업하여 모듈을 수정 / 추가 한 다음 다시 메인 지점으로 푸시해야합니다.

따라서, 초기 상태 두 가지의 당신은 this-처럼 될 것이다 로컬 저장소에 주요 프로젝트를 포크 할 때 ( A, BC모듈 이미 프로젝트의 완료)

여기에 이미지 설명을 입력하십시오

자, 당신이 새 모듈 (가정 작업을 시작했다 D) 당신은 완료되면 D메인 분기로 밀어 원하는 모듈을, 그러나 그 사이에 무슨 일하는 것은 당신의 동료 중 하나가 새로운 모듈을 개발했다고이며 E, F수정 C.
이제 로컬 저장소에 프로젝트의 원래 진행률이 부족하여 변경 사항을 기본 지점으로 푸시하면 충돌이 발생하여 모듈 D이 오작동 할 수 있습니다 .

여기에 이미지 설명을 입력하십시오

이러한 문제를 피하고 프로젝트의 원래 진행 상황과 병행하여 작업하는 방법은 두 가지입니다.

1. Git Fetch- 로컬 브랜치에없는 원산지 / 본점 프로젝트에 대한 모든 변경 사항을 다운로드합니다. 그리고 Git Merge 명령이 리포지토리 또는 브랜치에 가져온 변경 사항을 적용 할 때까지 기다립니다.

여기에 이미지 설명을 입력하십시오

이제 파일을 리포지토리에 병합하기 전에 파일을 신중하게 모니터링 할 수 있습니다. 그리고 DModified로 인해 필요한 경우 수정할 수도 있습니다 C.

여기에 이미지 설명을 입력하십시오

2. Git Pull- 로컬 브랜치를 원점 / 메인 브랜치로 업데이트합니다. 즉, 실제로 Git Fetch와 Git의 조합이 차례로 수행됩니다. 그러나 이로 인해 충돌이 발생할 수 있으므로 깨끗한 복사본으로 Git Pull을 사용하는 것이 좋습니다.

여기에 이미지 설명을 입력하십시오


1
'Main Branch'를 'Remote Repo'로 변경할 수 있다면 좋은 대답이 될 것입니다.
Qibiron 누가

87

우리는 단순히 말합니다 :

git pull == git fetch + git merge

을 실행 git pull하면 데이터를 로컬에 병합 할 필요가 없습니다. 를 실행 git fetch하면 git merge로컬 컴퓨터로 최신 코드를 가져 오기 위해 실행해야합니다 . 그렇지 않으면 로컬 머신 코드는 병합없이 변경되지 않습니다.

따라서 Git Gui에서는 가져 오기를 수행 할 때 데이터를 병합해야합니다. 가져 오기 자체는 로컬에서 코드를 변경하지 않습니다. 한 번 페치를 페치하여 코드를 업데이트 할 때이를 확인할 수 있습니다. 변경되지 않는 코드. 그런 다음 병합합니다 ... 변경된 코드가 표시됩니다.


3
차라리 말하고 싶습니다 git pull == git fetch + git merge:)
melvynkim

2
그러나git pull --rebase = git fetch + git rebase
티노

83

git fetch원격 서버에서 로컬 저장소의 추적 분기로 코드를 가져옵니다. 원격 이름이 지정되어있는 경우 origin(기본값) 다음이 지점 내 것 origin/, 예를 들어, origin/master, origin/mybranch-123, 등이 현재 지점 수없는, 그들은 지역 서버에서 그 지점의 사본.

git pull을 수행 git fetch하지만 또한 해당 분기의 현재 로컬 버전으로 추적 지점의 코드를 병합합니다. 아직 변경 사항이 없으면 git fetch먼저 시작하십시오.


78

git fetch원격 지점을 검색합니다 당신이 할 수 있도록 git diff하거나 git merge현재 브랜치로. git pull현재 브랜치에서 추적 한 원격 브 래치에서 페치를 실행 한 다음 결과를 병합합니다. git fetch로컬 지점과 병합하지 않고도 원격 지점에 대한 업데이트가 있는지 확인할 수 있습니다 .


73

힘내 가져 오기

출발지에서 가져 오기를 통해 로컬 지점에 대한 변경 사항을 다운로드합니다. Fetch는 원격 저장소에 다른 사람이 저지른 모든 커밋에 대해 요청하지만 로컬 리포지토리에는 없습니다. Fetch는 이러한 커밋을 다운로드하여 로컬 리포지토리에 추가합니다.

힘내 병합

merge 명령을 사용하여 가져 오기를 통해 다운로드 한 변경 사항을 적용 할 수 있습니다. 병합은 페치에서 검색된 커밋을 가져 와서 로컬 브랜치에 추가하려고 시도합니다. 병합은 로컬 변경 사항의 커밋 기록을 유지하므로 푸시와 지점을 공유 할 때 Git은 다른 사람이 변경 내용을 병합하는 방법을 알 수 있습니다.

힘내 당겨

페치 및 병합은 자주 결합되어 두 개의 풀을 결합하는 명령이 작성됩니다. Pull은 페치 한 다음 병합을 다운로드하여 커밋을 로컬 브랜치에 추가합니다.


52

와의 유일한 차이점은 다음 git pullgit fetch같습니다.

git pull 원격 브랜치에서 가져 와서 병합합니다.

git fetch 원격 브랜치에서만 가져 오지만 병합하지 않습니다.

즉 git pull = git fetch + git merge ...


1
그리고 git이 커밋에 의해 뒤처 졌다고 생각하고 "빨리 감기"할 수 있다면 도움이되지 않습니다. 결국 나는 rm -rf모든 것을 끝내고 다시 시작했습니다. 바보 같은 힘내, 내가 일을 다시 할 수 있도록 전류를 보내주십시오.
Chris K

46

간단히 말해, 인터넷에 연결되지 않은 채 비행기를 타려고한다면 출발하기 전에 할 수 있습니다 git fetch origin <master>. 모든 변경 사항을 컴퓨터로 가져 오지만 로컬 개발 / 작업 공간과 별도로 유지하십시오.

비행기에서 로컬 작업 공간을 변경 한 다음 가져온 작업 공간과 병합하고 인터넷에 연결하지 않고도 잠재적 인 병합 충돌을 해결할 수 있습니다. 그리고 누군가 원격 저장소에 새로 충돌하는 변경을 하지 않았다면 목적지에 도착하면 git push origin <branch>커피를 마시 게됩니다.


이 멋진 Atlassian 튜토리얼에서 :

git fetch명령은 커밋, 파일 및 참조를 원격 저장소에서 로컬 저장소로 다운로드합니다.

가져 오기는 다른 모든 사람 이 작업 한 내용을보고 싶을 때 수행 하는 작업입니다. 중앙 기록이 어떻게 진행되었는지 볼 수 있다는 점에서 SVN 업데이트와 비슷하지만 실제로 변경 사항을 저장소에 병합하지는 않습니다. 힘내 A는 로컬 콘텐츠를 기존의에서로 가져온 내용을 분리 , 그것은 절대적으로 없습니다 해당 지역의 개발 작업에 영향을 . 가져온 컨텐츠는 git checkout명령을 사용하여 명시 적으로 체크 아웃해야합니다 . 이를 통해 커밋을 커밋하여 로컬 리포지토리와 커밋하기 전에 커밋을 검토 할 수 있습니다.

원격 저장소에서 콘텐츠를 다운로드, 때 git pullgit fetch명령은 작업을 수행 할 수 있습니다. git fetch두 명령의 '안전한'버전을 고려할 수 있습니다 . 원격 컨텐츠를 다운로드하지만 로컬 저장소의 작업 상태를 업데이트하지 않고 현재 작업을 그대로 유지합니다. git pull보다 적극적인 대안으로 활성 로컬 분기에 대한 원격 컨텐츠를 다운로드하고 즉시 실행 git merge하여 새 원격 컨텐츠에 대한 병합 커밋을 작성합니다. 진행중인 변경 사항이 있으면 충돌이 발생하고 병합 충돌 해결 과정이 시작됩니다.


git pull:

  • 격리되지 않습니다.
  • 지역 개발에 영향을 미칩니다.
  • 명시 적으로 체크 아웃 할 필요는 없습니다. 암시 적으로을 수행하기 때문 git merge입니다.
  • 기본적으로 안전하지 않습니다. 공격적입니다.
  • git fetch그것이 오직 당신에게 영향을 미치는 곳 과 달리 .git/refs/remotes, git pull은 당신 .git/refs/remotes .git/refs/heads/

흠 ... 그래서 작업 사본을 업데이트하지 않으면 git fetch어디에서 변경합니까? Git 페치는 새로운 커밋을 어디에 저장합니까?

좋은 질문입니다. 작업 복사본과 분리되어 있습니다. 그러나 다시 어디? 알아 보자.

프로젝트 디렉토리에서 (즉, git명령 을 수행하는 위치) 다음을 수행하십시오 .

  1. ls. 파일 및 디렉토리가 표시됩니다. 시원하지 않습니다.

  2. 이제하세요 ls -a. 그러면 dot files 가 표시됩니다 . 즉, .You로 시작하는 파일 은 다음 디렉토리를 볼 수 있습니다 : .git.

  3. 마십시오 cd .git. 이것은 분명히 디렉토리를 변경합니다.
  4. 이제 재미있는 부분이 온다. 할 ls. 디렉토리 목록이 나타납니다. 찾고 있습니다 refs. 마십시오 cd refs.
  5. 모든 디렉토리 안에 무엇이 있는지 살펴 보는 것이 흥미롭지 만 두 디렉토리에 중점을 두자. heads그리고 remotes. 사용 cd도 그들 내부에서 확인 할 수 있습니다.
  6. 모든 git fetch 당신이 항목 업데이트합니다 할 것을 /.git/refs/remotes디렉토리를. /.git/refs/heads디렉토리 에서 아무것도 업데이트하지 않습니다 .
  7. 누구나 git pull 먼저 디렉토리 git fetch에서 항목을 업데이트 /.git/refs/remotes한 다음 로컬과 병합 한 다음 /.git/refs/heads디렉토리 내부의 헤드를 변경합니다 .

'git fetch'어디에 위치합니까? 에서 매우 좋은 관련 답변을 찾을 수 있습니다 . .

또한 Git 브랜치 명명 규칙 게시물 에서 "슬래시 표기법"을 찾으십시오 . Git이 다른 디렉토리에 물건을 배치하는 방법을 더 잘 이해하는 데 도움이됩니다.


실제 차이를 보려면

그냥 해:

git fetch origin master
git checkout master

원격 마스터가 업데이트 된 경우 다음과 같은 메시지가 나타납니다.

Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

당신이하지 않고 fetch방금 git checkout master했다면 로컬 자식은 2 개의 커밋이 추가되었음을 알지 못합니다. 그리고 그것은 단지 말할 것입니다 :

Already on 'master'
Your branch is up to date with 'origin/master'.

그러나 그것은 구식이며 잘못되었습니다. git이 알고있는 것에 기초하여 피드백을 제공하기 때문입니다. 아직 풀리지 않은 새로운 커밋은 분명하지 않습니다 ...


지점에서 로컬로 작업하는 동안 원격에서 새로 변경된 내용을 볼 수있는 방법이 있습니까?

일부 IDE (예 : Xcode)는 매우 현명하며 a의 결과를 사용하며 git fetch현재 작업중인 지점의 원격 지점에서 변경된 코드 줄에 주석을 달 수 있습니다. 해당 회선이 로컬 변경 사항과 원격 지점 모두에 의해 변경된 경우 해당 회선에 빨간색 주석이 표시됩니다. 이것은 병합 충돌이 아닙니다. 그것은 A의 잠재적 인 병합 충돌합니다. git pull원격 지점에서 수행하기 전에 향후 병합 충돌을 해결하는 데 사용할 수있는 헤드 업입니다 .

여기에 이미지 설명을 입력하십시오


재미있는 팁 :

원격 브랜치를 가져온 경우 예를 들어 다음과 같습니다.

git fetch origin feature/123

그런 다음 이것은 remotes 디렉토리로 이동합니다. 여전히 로컬 디렉토리에서 사용할 수 없습니다. 그러나 DWIM을 사용하여 해당 원격 지점에 대한 체크 아웃을 단순화합니다 (내가 의미하는 바를 수행).

git checkout feature/123

더 이상 할 필요가 없습니다.

git checkout -b feature/123 origin/feature/123

이에 대한 자세한 내용은 여기 를 참조 하십시오


1
나는이 답변을 좋아합니다
Kid_Learning_C

44

Git을 사용하면 새로운 커밋 후에 연대순으로 오래된 커밋을 적용 할 수 있습니다. 이 때문에 리포지토리간에 커밋을 전송하는 작업은 두 단계로 나뉩니다.

  1. 원격 지사에서 새 커밋을 복사하여 로컬 리포지토리 내의이 원격 지사를 복사합니다.

    (레포에서 리포 작업으로) master@remote >> remote/origin/master@local

  2. 로컬 커밋에 새로운 커밋 통합

    (리포터 내부 작업) remote/origin/master@local >> master@local

2 단계를 수행하는 두 가지 방법이 있습니다.

  1. 마지막 공통 조상 다음에 로컬 브랜치를 포크하고 로컬 저장소에 고유 한 커밋에 병렬로 새 커밋을 추가하고 커밋을 병합하여 포크를 닫습니다.
  2. 마지막 공통 조상 뒤에 새 커밋을 삽입하고 로컬 리포지토리에 고유 한 커밋을 다시 적용합니다.

에서 git용어, 스텝 1은 git fetch, 2 단계 인 git merge또는git rebase

git pull이다 git fetchgit merge


36

Git은 다음 두 명령을 사용하여 최신 버전의 분기를 원격에서 로컬로 가져옵니다.

  1. git fetch : Git은 최신 버전을 원격에서 로컬로 가져 오지만 자동으로 병합되지는 않습니다.      git fetch origin master git log -p master..origin/master git merge origin/master

         위의 명령은 원점에서 원점 마스터 지점으로 최신 버전의 기본 지점을 다운로드 함을 의미합니다. 그런 다음 로컬 마스터 분기와 원본 마스터 분기를 비교합니다. 마지막으로 병합하십시오.

  2. git pull : Git은 원격에서 최신 버전을 가져 와서 로컬로 병합합니다.

        git pull origin master

         위의 명령에 상당 git fetch하고 git merge. 실제로 git fetch병합하기 전에 변경 사항을 확인하고 병합할지 여부를 결정할 수 있기 때문에 더 안전 할 수 있습니다.


36

차이점은 무엇이며 git pull그리고 git fetch?

이를 이해하려면 먼저 로컬 자식이 로컬 저장소뿐만 아니라 원격 저장소의 로컬 사본도 유지 관리한다는 것을 이해해야합니다.

git fetch원격 저장소의 로컬 사본을 최신 상태로 만듭니다. 예를 들어, 원격 저장소가 GitHub 인 경우 원격 저장소에서 작성된 변경 사항을 원격 저장소의 로컬 사본으로 가져 오려고 할 수 있습니다. 그러면 비교 또는 병합과 같은 작업을 수행 할 수 있습니다.

git pull반면에 원격 저장소의 변경 사항을 자신의 코드를 유지하는 위치로 가져옵니다. 일반적으로, git pull할 것 git fetch최신 원격 저장소 최대의 로컬 복사본을 가지고 먼저 한 다음 자신의 코드 저장소 가능성이 당신의 작업 복사본에 변경 내용을 병합합니다.


34

자식 풀 == (자식 가져 오기 + 자식 병합)

git fetch는 로컬 브랜치로 변경되지 않습니다.

원하는 프로젝트에 대해 원격으로 설정된 로컬 저장소가 이미있는 경우 git fetch를 사용하여 기존 원격의 모든 분기 및 태그를 가져올 수 있습니다. ... Fetch는 로컬 브랜치를 변경하지 않으므로 새로 페치 된 변경 사항을 통합하려면 원격 브랜치를 페어링 된 로컬 브랜치와 병합해야합니다. github에서


33

명확하고 간단하려고합니다.

자식 풀 명령은 실제로 shortcut대한 자식이 인출 에 의해 다음에 자식 병합 또는 자식 REBASE의 구성에 따라 명령. git pull 이 페치에 이어 rebase가 되도록 Git 리포지토리를 구성 할 수 있습니다 .


33

초보자를위한 간단한 그래픽 표현,

여기에 이미지 설명을 입력하십시오

여기,

git pull  

저장소에서 코드를 가져 와서 로컬로 리베이스합니다 ... git pull에서 새로운 커밋이 생성 될 가능성이 있습니다.

그러나에서

자식 가져 오기

저장소에서 코드를 가져오고 다음을 사용하여 수동으로 코드를 리베이스해야합니다. git rebase

예 : 서버 마스터에서 가져 와서 로컬 마스터에서 리베이스 할 것입니다.

1) git pull (리베이스가 자동으로 수행됩니다) :

git pull origin master

여기 원산지 는 당신의 원격 repo 마스터 는 당신의 지점입니다

2) git fetch (수동으로 리베이스해야 함) :

git fetch origin master

서버 변경 사항을 원점에서 가져옵니다. 직접 리베이스 할 때까지 로컬에 있습니다. 코드를 확인하여 수동으로 충돌을 해결해야합니다.

git rebase origin/master

이것은 코드를 로컬로 리베이스합니다. 그 전에 올바른 지점에 있는지 확인하십시오.


멋진 그래프이지만 그래프에 "병합"이라고 표시 될 때 "리베이스"를 사용하는 이유를 설명 할 수 있습니다.
Guntram Blohm은 Monica를

1
병합은 다른 브랜치 커밋을 나타내며 커밋을 참조로 포함하는 새로운 커밋을 생성합니다. 하지만 REBASE는 그것이 복제보다는 커밋 새로운 만들 실 거예요 다른 지점에서 커밋을 복제합니다
모 히딘 빈 모하메드

33

실제로 Git은 자신의 코드 사본과 원격 저장소를 유지 관리합니다.

이 명령 git fetch은 원격 저장소에서 데이터를 가져 와서 로컬 사본을 최신 상태로 만듭니다. 우리가 필요한 이유는 다른 사람이 코드를 약간 변경했을 수도 있고 자신을 계속 업데이트하고 싶어하기 때문입니다.

이 명령 git pull은 원격 저장소의 변경 사항을 사용자 코드를 유지하는 위치로 가져옵니다. 일반적으로 git pull'git fetch'를 먼저 수행하여 원격 저장소의 로컬 사본을 최신 상태로 만든 다음 변경 사항을 사용자의 코드 저장소 및 작업 사본으로 병합합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.