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

가장 간단한 용어로 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

git fetch
git diff ...origin

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

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

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

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

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

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

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

간단히

git fetch비슷 pull하지만 병합되지 않습니다. 즉, 원격 업데이트를 가져옵니다 (refs 및 objects)를 오지만 로컬은 동일하게 유지됩니다 (즉, 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 clone 및git 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/

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

자식 풀 ...
기술

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

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

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

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

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

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

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

짧고 쉬운 대답은 해당이됩니다 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)을주의 깊게 읽지 않으면이 옵션을 사용하지 마십시오.

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 fetch과 git pull함께 작업을 ...

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

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

보너스:

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

git pull --rebase

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

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

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

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

                                         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로 업데이트 할 수 있습니다).

나는 이것으로도 어려움을 겪었다. 사실 나는 정확히 같은 질문에 대한 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+               -
---------------------     -----------------------     -----------------------

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

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

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

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

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

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

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

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

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

우리는 단순히 말합니다 :

git pull == git fetch + git merge

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

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

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

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

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

힘내 가져 오기

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

힘내 병합

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

힘내 당겨

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

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

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

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

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

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

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

이 멋진 Atlassian 튜토리얼에서 :

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

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

원격 저장소에서 콘텐츠를 다운로드, 때 git pull와 git 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

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

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 fetch와git merge

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병합하기 전에 변경 사항을 확인하고 병합할지 여부를 결정할 수 있기 때문에 더 안전 할 수 있습니다.

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

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

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

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

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

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

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

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

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

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

여기,

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

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

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

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

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