CLI를 통한 Pull & Fetch

Violet_Evgadn·2023년 9월 6일
0

Git

목록 보기
17/33
post-custom-banner

CLI 명령

Pull

git pull [Option] [원격 저장소 이름] <branch명>

이전에도 설명했지만 원격 저장소 이름은 대부분 origin이므로 사실상 git pull [Option] origin <branch명>이 규칙이라고 볼 수도 있다.

Pull 부가 설명

이전에 설명했듯 git pull은 원격 저장소의 코드를 로컬 저장소로 가지고 오는 명령어이다.
그리고 이를 Git 명령어를 통해 설명하자면 git pull = git fetch + git merge라고 할 수 있다.

  • git fetch : Git log 및 히스토리를 최신화
  • git merge : 커밋을 하나로 합치는 작업

git pull이 일어날 경우 git fetch는 자동으로 이루어진다는 것은 개념적으로 외워두고 git merge에 대해서는 조금 더 알아보자.

만약 다른 협업자들이 Pull 받을 브랜치에 대해 작업을 수행했다면 원격 브랜치의 최신 버전(커밋) 같은 경우 로컬 저장소의 최신 커밋에서 추가적인 작업 내용이 추가된 상태일 것이다.
이를 병합 상황으로 파악한다면 Fast-forward 병합 상태라는 것을 알 수 있다.
따라서, git pull을 받는다는 것은 곧 "로컬 저장소의 최종 커밋을 원격 저장소의 커밋으로 만들겠다"라는 의미라고 볼 수 있는 것이다.

git pull 같은 경우 동일한 브랜치에 대해 Pull 작업을 수행한다면 Fast-forward 병합 상황이므로 충돌이 발생할 가능성이 적지만 가끔 다른 브랜치에서 Pull을 수행할 때 버전 관리를 소홀히 했었다면 충돌이 발생할 가능성도 있다.
이 경우엔 git pull 대신 git merge 명령어를 통해 원격 저장소 커밋을 가져와 충돌을 해결해야 한다.

Option 및 사용법

설명에 앞서 개인적으로 git pull을 사용하며 Option을 사용했던 적은 거의 없는 것 같다.
Option을 외우기보단 이런 것이 있구나 정도만 생각하고 넘어가도 될 것 같다.

  • git pull --rebase origin <branch명> : History가 정리된 상태로 git pull을 수행
    • Rebase에 대해서는 나중에 자세히 배우겠지만 Git History를 변경시키는 명령어는 생각보다 매우 위험하다. 따라서 조심히 사용하도록 하자.
    • 개인적으로는 필요 없어 보이는 커밋도 모두 History이기 때문에 굳이 history를 정리할 필요가 있나 싶긴 하다.
  • git pull --ff-only origin <branch명> : Fast-forward 병합일 때만 git pull을 수행

Fetch

git fetch [Option] [원격 저장소 이름] <branch명>

Option 및 사용법

  • git fetch --all : 모든 Remote에서 Git History 및 Log를 가지고 옴

  • git fetch -t, git fetch --tags : 지정한 remote의 모든 Tag를 가지고 온다.

    • Git Tag에 대해선 나중에 자세히 설명하겠다.

부가 설명

왜 Pull과 Fetch는 설명했는데 Pull Request는 명령어로 설명하지 않냐는 의문이 들 수 있다.

풀 리퀘스트는 엄밀히 따지면 단순한 Merge에 불과하다.
단지 이 Merge가 원격 저장소에서 일어나기 때문에 다른 협업자들에게 병합 소식을 알리기 위해 새로 만들어진 단어에 불과하다.

즉, 풀 리퀘스트는 작업 그 자체보다는 "알림"의 목적이 더 크고 이 때문에 CLI로 굳이 알 필요도 없으며 CLI로 수행할 수 있다 하더라도 "알림"의 기능을 하지 못한다면 의미가 없으므로 공부할 필요가 없는 것이다.

profile
혹시 틀린 내용이 있다면 언제든 말씀해주세요!
post-custom-banner

0개의 댓글