git pull

이 다이어그램에서는 이제 다시 지정 풀(rebase pull)은 새 H 커밋을 만들지 않습니다. 대신, 다시 지정(rebase)은 원격 커밋 A--B--C를 복사하고 로컬 커밋 E--F--G가 로컬 오리진/메인 커밋 기록에서 A--B--C 뒤에 나타나도록 다시 작성합니다.

기본 호출과 비슷하게 원격 콘텐츠를 가져오지만 새 병합 커밋을 만들지는 않습니다.

이전 pull과 마찬가지로 git merge 명령을 사용하여 원격 브랜치를 로컬 브랜치와 통합하는 대신 git rebase를 사용합니다.

가져오는 동안 다운로드 중인 콘텐츠와 병합 세부 정보를 표시하는 자세한 출력을 제공합니다.

git pull은 Git에 svn update와 같은 명령이라고 생각할 수 있습니다. 로컬 리포지토리를 업스트림 변경 사항과 쉽게 동기화할 수 있습니다. 다음 다이어그램에서는 풀링 프로세스의 각 단계를 설명합니다.

리포지토리가 동기화되어 있다고 생각하고 시작하지만 git fetch는 마지막 확인 이후 오리진의 메인 버전에 진행된 사항이 있음을 보여줍니다. 그런 다음 git merge는 원격 메인을 로컬 메인에 즉시 통합합니다.

git pull은 원격 콘텐츠를 '동기화'하는 역할을 수행하는 명령 중 하나입니다. git remote 명령은 동기화 명령이 작동할 원격 엔드포인트를 지정하는 데 사용합니다. git push 명령은 콘텐츠를 원격 리포지토리에 업로드하는 데 사용합니다.

git fetch 명령은 git pull 명령과 혼동될 수 있습니다. 둘 다 원격 콘텐츠를 다운로드하는 데 사용합니다. git pull 및 git fetch 사이에는 중요한 안전 구분이 있습니다. git fetch 명령은 "안전한" 옵션으로 여겨지는 반면 git pull 명령은 안전하지 않은 옵션으로 여겨질 수 있습니다. git fetch 명령은 원격 콘텐츠를 다운로드하며 로컬 리포지토리의 상태를 변경하지 않습니다. 반면, git pull은 원격 콘텐츠를 다운로드하고 로컬 상태가 콘텐츠와 일치하도록 즉시 변경하려고 시도합니다. 따라서 의도치 않게 로컬 리포지토리 충돌 상태로 이어질 수 있습니다.

--rebase 옵션은 불필요한 병합 커밋을 방지하여 선형 기록을 보장하는 데 사용할 수 있습니다. "다른 모든 사용자가 완료한 항목에 내 변경 사항을 적용하고 싶다"고 말하는 것과 같기 때문에 많은 개발자가 병합(merging)보다 다시 지정(rebasing)를 선호합니다. 이런 의미에서 git pull 명령을 --rebase 플래그와 함께 사용하는 것은 일반 git pull보다는 svn update와 유사합니다.

실제로 --rebase를 사용하는 풀링(pulling)은 전용 구성 옵션이 있는 매우 일반적인 워크플로입니다.

이 명령을 실행하면 모든 git pull 명령이 git merge 대신 git rebase를 통해 통합됩니다.

다음 예제에서는 일반적인 시나리오에서 git pull을 사용하는 방법을 보여줍니다.

git pull의 기본 호출의 실행은 git fetch origin HEAD 및 git merge HEAD와 동일합니다. 여기서 HEAD는 현재 브랜치를 가리키는 참조입니다.

다음 예제에서는 다시 저정(rebase)을 사용하여 중앙 리포지토리의 기본 브랜치와 동기화하는 방법을 보여줍니다.

이렇게 하면 로컬 변경 사항을 다른 모든 사용자가 이미 기여한 사항의 상단으로 이동합니다.