소개
이 랩에서는 로컬 저장소에 아직 없는 새로운 커밋이 Git 원격 저장소에 있는지 확인하는 방법을 배우게 됩니다. 이는 협업 개발에 필수적인 기술로, 다른 사용자가 변경한 사항을 최신 상태로 유지할 수 있도록 해줍니다.
먼저 원격 저장소를 시뮬레이션하고 이를 로컬 프로젝트에 추가하는 것으로 시작합니다. 그런 다음, git fetch 명령을 사용하여 병합하지 않고 원격의 브랜치 및 커밋에 대한 정보를 검색합니다. 마지막으로, 로컬 브랜치를 업스트림 (upstream) 에 해당하는 브랜치와 비교하여 원격에 있는 새로운 커밋을 식별하는 방법을 살펴봅니다.
git fetch 로 원격 가져오기
이 단계에서는 원격 저장소에서 변경 사항을 가져오는 방법을 배웁니다. 다른 사람들과 함께 프로젝트를 진행 중인데, 그들이 몇 가지 업데이트를 했다고 가정해 봅시다. 이러한 업데이트를 로컬 머신으로 가져와야 합니다. git fetch 명령이 바로 이 작업을 수행합니다. 이 명령은 원격 저장소에서 최신 변경 사항을 다운로드하지만 현재 브랜치에 병합하지는 않습니다.
먼저, 원격 저장소를 시뮬레이션해 보겠습니다. 베어 (bare) 저장소를 생성한 다음, 기존의 my-time-machine 저장소에 원격으로 추가합니다.
cd ~/project
mkdir remote-repo.git
cd remote-repo.git
git init --bare
이렇게 하면 베어 Git 저장소가 생성됩니다. 베어 Git 저장소는 일반적으로 개발자가 푸시 (push) 하고 풀 (pull) 하는 중앙 저장소로 사용됩니다.
이제 my-time-machine 저장소로 돌아가 이 베어 저장소를 원격으로 추가해 보겠습니다.
cd ~/project/my-time-machine
git remote add origin ~/project/remote-repo.git
원격의 이름을 origin으로 지정했는데, 이는 일반적인 관례입니다. 이제 원격이 올바르게 추가되었는지 확인해 보겠습니다.
git remote -v
다음과 유사한 출력이 표시되어 origin 원격에 대한 fetch 및 push URL 을 보여줍니다.
origin /home/labex/project/remote-repo.git (fetch)
origin /home/labex/project/remote-repo.git (push)
이제 원격 저장소에서 변경 사항을 시뮬레이션해 보겠습니다. 베어 저장소이므로 직접 커밋을 할 수 없습니다. 대신, 베어 저장소 디렉토리에 새 파일을 생성하여 변경 사항을 시뮬레이션합니다.
cd ~/project/remote-repo.git
echo "This is a remote change" > remote_file.txt
이제 my-time-machine 저장소로 돌아갑니다.
cd ~/project/my-time-machine
이 시점에서 로컬 저장소는 시뮬레이션된 원격에 추가된 remote_file.txt에 대해 알지 못합니다. 이때 git fetch가 필요합니다.
git fetch 명령을 실행합니다.
git fetch origin
아무런 출력도 보이지 않거나, 새로운 객체가 수신되었다는 내용이 표시될 수 있습니다.
git fetch origin은 origin 원격에 연결하여 로컬 저장소에 없는 새로운 커밋과 객체를 다운로드했습니다. 그러나 이러한 변경 사항을 현재 브랜치 (master) 에 병합하지 않았습니다. 변경 사항은 이제 로컬 저장소에서 사용할 수 있지만, 일반적으로 origin/master라는 원격을 추적하는 특수한 브랜치에 저장됩니다.
이것이 git fetch와 git pull의 주요 차이점입니다. git pull은 본질적으로 git fetch 다음에 병합을 수행하는 것입니다. 먼저 git fetch를 사용하면 작업을 통합하기 전에 원격에서 사용할 수 있는 변경 사항을 확인할 수 있습니다. 이렇게 하면 더 많은 제어 권한을 얻고 예기치 않은 충돌을 방지하는 데 도움이 됩니다.
다음 단계에서는 다운로드된 변경 사항을 이해하기 위해 로컬 브랜치를 가져온 원격 브랜치와 비교하는 방법을 살펴보겠습니다.
git log HEAD..@{u} 실행
이전 단계에서는 git fetch를 사용하여 원격 저장소에서 변경 사항을 다운로드했습니다. 이제 원격에 있지만 아직 로컬 브랜치에 없는 커밋을 확인하는 방법을 살펴보겠습니다. 이 경우 git log HEAD..@{u} 명령이 매우 유용합니다.
아직 ~/project/my-time-machine 디렉토리에 있는지 확인합니다.
cd ~/project/my-time-machine
이제 다음 명령을 실행합니다.
git log HEAD..@{u}
다음과 유사한 출력이 표시될 수 있습니다.
commit abcdef1234567890abcdef1234567890abcdef (origin/master)
Author: Simulated User <simulated.user@example.com>
Date: Mon Aug 7 10:05:00 2023 +0000
Simulated remote commit
이 명령을 자세히 살펴보겠습니다.
git log: 커밋 기록을 보기 위한 명령입니다.HEAD: 현재 브랜치가 가리키는 커밋을 나타냅니다.@{u}: 업스트림 (upstream) 브랜치의 약어입니다. 이 경우,origin에서 가져왔고 로컬master브랜치가origin/master를 추적하므로,@{u}는origin/master를 나타냅니다.HEAD..@{u}: Git 의 범위 표기법입니다. 이는 "@{u}에서 도달할 수 있지만HEAD에서 도달할 수 없는 커밋을 표시"한다는 의미입니다. 더 간단히 말하면, 원격 추적 브랜치 (origin/master) 에 있지만 현재 로컬 브랜치 (master) 에는 없는 커밋을 표시합니다.
이 명령은 로컬 브랜치를 원격 추적 브랜치와 병합하거나 리베이스 (rebase) 할 경우 얻게 될 변경 사항을 확인하는 데 매우 유용합니다. 통합하기 전에 들어오는 변경 사항을 검토할 수 있으므로 안전하고 제어된 워크플로우의 중요한 부분입니다.
"Git 이 시뮬레이션된 원격 커밋에 대해 어떻게 알았을까?" 궁금할 수 있습니다. 이전 단계에서 git fetch origin을 실행했을 때 Git 은 origin 저장소의 커밋에 대한 정보, 즉 remote_file.txt를 도입한 커밋을 포함하여 정보를 다운로드했습니다. 이 정보는 로컬 저장소의 origin/master 추적 브랜치에 저장됩니다. 그런 다음 git log HEAD..@{u} 명령은 로컬 master 브랜치 (HEAD) 를 이 origin/master 추적 브랜치 (@{u}) 와 비교하여 차이점을 표시합니다.
전체 화면 모드인 경우 q를 눌러 로그 보기를 종료합니다.
로컬 브랜치와 원격 추적 브랜치의 차이점을 이해하는 것은 원격 저장소로 효과적으로 작업하는 데 필수적입니다. 이 명령은 이러한 차이점을 시각화하는 명확한 방법을 제공합니다.
동기화된 원격 저장소 테스트
이전 단계에서는 시뮬레이션된 원격 저장소에서 변경 사항을 가져왔고, git log HEAD..@{u}를 사용하여 원격에 있지만 로컬 브랜치에는 없는 커밋을 확인하는 방법을 배웠습니다. 이제 로컬 브랜치가 원격 추적 브랜치와 최신 상태일 때 어떤 일이 발생하는지 살펴보겠습니다.
먼저, 원격 변경 사항을 로컬 브랜치에 병합하는 것을 시뮬레이션해 보겠습니다. git fetch는 변경 사항만 다운로드하는 반면, git pull은 다운로드한 다음 병합합니다. 이 테스트를 위해, 로컬 브랜치를 원격 추적 브랜치와 일치하도록 수동으로 업데이트하여 풀 (pull) 후의 상태를 시뮬레이션합니다.
~/project/my-time-machine 디렉토리에 있는지 확인합니다.
cd ~/project/my-time-machine
이제 로컬 master 브랜치를 origin/master와 동일한 커밋으로 재설정하여 병합을 시뮬레이션해 보겠습니다. 참고: 실제 시나리오에서는 일반적으로 git merge origin/master 또는 git pull origin master를 사용하여 변경 사항을 통합합니다. 여기서는 테스트를 위해 로컬 브랜치를 원격 추적 브랜치와 빠르게 동기화하기 위해 시연 목적으로만 git reset --hard를 사용합니다.
git reset --hard origin/master
브랜치가 업데이트되었고 작업 트리가 깨끗하다는 내용의 출력이 표시되어야 합니다.
HEAD is now at abcdef1 Simulated remote commit
이제 로컬 master 브랜치가 origin/master와 동기화되었으므로, git log HEAD..@{u} 명령을 다시 실행해 보겠습니다.
git log HEAD..@{u}
이번에는 아무런 출력도 표시되지 않아야 합니다.
왜 출력이 없을까요? HEAD (로컬 master 브랜치) 와 @{u} ( origin/master 추적 브랜치) 가 이제 동일한 커밋을 가리키고 있기 때문입니다. 범위 HEAD..@{u}는 비어 있습니다. HEAD에서 도달할 수 없는 @{u}에서 도달할 수 있는 커밋이 없기 때문입니다.
이는 로컬 브랜치가 업스트림 (upstream) 원격 추적 브랜치와 완전히 동기화될 때 예상되는 동작입니다. git log HEAD..@{u} 명령은 아직 통합하지 않은 원격에서 들어오는 변경 사항이 있는지 확인하는 빠른 방법입니다. 명령이 아무런 출력을 표시하지 않으면 로컬 브랜치가 원격 추적 브랜치와 최신 상태임을 의미합니다.
들어오는 변경 사항을 확인하는 방법과 git log HEAD..@{u}의 출력을 해석하는 방법을 이해하는 것은 다른 사람들과 협업하고 로컬 저장소를 원격과 동기화 상태로 유지하는 데 필수적입니다.
요약
이 랩에서는 Git 원격에 새로운 커밋이 있는지 확인하는 방법을 배웠습니다. 먼저, 원격 저장소에서 변경 사항을 병합하지 않고 다운로드하는 git fetch의 목적을 이해했습니다. 베어 (bare) Git 저장소를 생성하고 이를 로컬 my-time-machine 저장소에 origin이라는 이름의 원격으로 추가하여 원격 저장소를 시뮬레이션했습니다. git remote -v를 사용하여 원격 설정을 확인했습니다.
다음으로, 베어 저장소의 디렉터리에 직접 파일을 생성하여 원격 저장소의 변경 사항을 시뮬레이션했습니다. 그런 다음 git fetch origin 명령을 사용하여 이러한 변경 사항을 로컬 저장소로 가져와 새로운 커밋을 확인할 준비를 했습니다.
