1. merge vs rebase

 merge와 rebase는 모두 내용을 합치기 위한 방법이다. 그러나 합치는 과정에서의 차이점이 존재한다.

Merge

 변경사항을 하나의 브랜치에서 다른 브랜치로 합치는 것으로, 브랜치 별 히스토리가 남는다.

git merge [가져올 브랜치명]

 

Rebase

 변경사항을 하나의 브랜치에서 다른 브랜치로 옮겨 새로운 시작점(기반)으로 삼는 것으로, 히스토리를 깔끔하게 유지하고 싶은 경우에 사용한다.

 

 글로는 잘 이해가 되지 않으나, 그림을 보면 바로 이해가 될 것이다.

그 외 squashing과 pull request

  • Squashing: All commits are preserved in both cases (for example: "add feature", then "typo", then "oops typo > again"...). Commits can be combined into a single commits by squashing. Squashing can be done as part of a merge > or rebase operation (--squash flag), in which case it's often called a squash-merge or a squash-rebase.
  • Pull Requests: Popular git servers (Bitbucket, GitLab, GitHub, etc...) allow to configure how pull requests > are merged on a per-repo basis. the UI may show a "Merge" button by convention but the button can do any ?> operations with any flags (keywords: merge, rebase, squash, fast-forward).

 

2. fetch vs pull

 fetch와 pull은 둘 다 원격 저장소에서 데이터를 불러오지만, 불러오는 데이터 종류가 다르다.

Fetch

 git fetch는 로컬 Git에게 원격 저장소에서 최신 메타데이터 정보를 확인하라는 명령을 전달한다. 단 fetch는 원격 저장소에 변경사항이 있 는지 확인만 하고, 변경된 데이터를 로컬 Git에 실제로 가져오지는 않는다.

git fetch

 

Pull

반면 git pull은 원격 저장소에서 변경된 메타데이터 정보를 확인할 뿐만 아니라 최신 데이터를 복사하여 로컬 Git에 가져온다. 간단히 말해서 git pull 은 git fetch와 git merge(또는 rebase)가 합쳐진 것과 유사하다.
따라서, 만일 원격 저장소에 변경 사항이 존재하는 상황에서 pull을 바로 실행하면 현재 브랜치와 작업 복사본의 파일이 변경되는 동시에 새로 작업한 내용이 손실되는 일이 생길 수 있다.

다음은 pull 명령을 사용하는 예시 문법이다.

git pull origin yudility feature/login

 

여기서 유의할 점은 보통 작업 중인 워크스테이션에 최소 세 개 이상의 프로젝트 복사본이 존재한다는 것이다.

  • 커밋 기록이 있는 사용자의 저장소
  • 편집 및 작성 중이지만 사용자 저장소에 아직 커밋되지 않은 복사본
  • 원격 저장소의 로컬에 "캐시된 (cached)" 복사본

git fetch를 사용하면 마지막 pull 이후 원격 저장소 또는 브랜치에 적용된 변경 사항을 확인할 수 있다. 그렇기 때문에 fetch로 변경 사항을 먼저 확인한 후 pull을 실행하는 방법이 보다 안전하다.

git fetch  
git diff ...origin

 

 

Reference

merge, rebase 차이

fetch, pull 차이

 

yudility
yudility
yudility 님의 블로그 입니다.

티스토리툴바