[위클리 페이퍼] git 활용

 

앞으로 매주 주어지는 질문에 대해 찾아보고 그 내용을 정리해 기록을 남기는 위클리페이퍼를 진행하려고 한다.

 

이번주의 주제는 

git rebase, git merge의 차이점과 각각의 적절한 사용 상황에 대해 설명해보자

git fetch와 git pull의 차이점과 각각의 적절한 사용 상황에 대해 설명해보자

---

 

git rebase와 git merge의 차이와 적절한 사용 상황

 

Git에서 어떤 브랜치에서 다른 브랜치로 합쳐주는 방법은 Rebase와 Merge가 있다.

 

git rebase

ATLASSIAN의 git 설명 문서에 따르면 git rebase는 " 커밋 시퀀스를 새 기준 커밋으로 이동하거나 결합하는 프로세스"라고 적혀있다. git rebase는 한 브랜치의 커밋들을 다른 브랜치를 기준으로 다시 배치하는 명령이다.

rebase 용어 그대로 Base가 되는 브랜치를 다시 설정하는 작업이다.

 

git rebase의 장점은 잘 사용한다면 히스토리가 직렬화 되어서 깔끔하게 보인다.

 

o---o---o---o---o  main
         \
          o---o---o---o---o  featureA
               \
                o---o---o  featureB

출처: https://www.atlassian.com/ko/git/tutorials/rewriting-history/git-rebase

이런 형태의 깃 히스토리가 있다고 가정한다. featureB 브랜치를 main 브랜치에 rebase 한다고 하면

 

git rebase --onto main featureA featureB

이런 명령어를 통해 featureB 브랜치를 main 브랜치에 rebase 할 수 있다.

 

                      o---o---o  featureB
                     /
    o---o---o---o---o  main
             \
              o---o---o---o---o  featureA

rebase를 한 모습이다. main 브랜치를 부모브랜치로 하여 featureB가 베이스를 이동한 것을 볼 수 있다.

그 후 Fast-forward Merge를 시켜준다.

 

    o---o---o---o---o---o---o---o main
             \
              o---o---o---o---o  featureA

그렇다면 이런 형태의 히스토리로 변한다. 이렇게 rebase를 하게 되면 커밋 히스토리가 직렬로 깔끔하게 정리된다!

 

하지만 잘못했다간 문제가 발생할 수 있다.

rebase로 인해 로컬 브랜치의 깃 히스토리가 변경된 뒤 원격 브랜치에 push 하는 상황에 충돌이 발생한다.

이름만 같지 다른 브랜치로 간주하기 때문이라고 한다.

git rebase에는 강제로 Push하는 작업으로 로컬과 원격 브랜치의 히스토리를 맞춰준다.

혼자 진행하는 프로젝트에선 문제가 생기지 않을 수 있지만, 협업하는 경우엔 문제가 발생할 수 있다. rebase를 진행하면서 커밋의 순서가 꼬일 수 있고, 내용이 똑같은 커밋이 중복될 수 있다.

따라서 외부에 Push로 내보낸 커밋에 대해서는 절대로 rebase 하지 말아야 한다.

 

히스토리 관리에 용이하지만 git rebase 사용에 익숙한 사람이 아니라면 충돌이 날 수 있으니 연습 및 학습이 필요해보인다.

 

 

git merge

git merge는 여러 커밋 기록을 하나의 통합된 기록으로 결합한다

출처: https://www.atlassian.com/ko/git/tutorials/using-branches/git-merge

 

위와 같이 main 브랜치를 기준으로 하는 feture 브랜치가 있다. 이 브랜치를 main에 병합하려고 한다.

 

그렇다면 이런식으로 병합된다. 이 방법이 git merge이다. 병합할 대상 브랜치와 연결된 선형 경로가 없는 경우엔 위 처럼 3-way merge 방법을 사용해 병합해야한다,

 

병합하려는 두 브랜치가 동일한 파일의 동일한 부분에서 변경되면 Git은 어떤 버전을 사용해야 할지 모른다.

이런 상황이 병합에서 발생하는 충돌이다. 충돌이 발생하면 병합이 중지되므로 수동으로 충돌을 해결하여 다시 병합을 진행하면 된다.

위의 그림처럼 git merge를 사용하면 git rebase보다 히스토리가 깔끔하지 못하다.

git merge는 관리 이력을 정확하게 남겨준다. rebase와 반대되는 부분이다.

 

 

각 방법의 적절한 사용 상황

따라서 협업 과정에선 git merge가 더 적절할 것 같고, 개인 브랜치에서 작업 정리를 하고 개인 프로젝트의 커밋 히스토리를 깔끔하게 유지할 때 git rebase를 사용하면 좋을 것 같다.

 

---

 

git fetch와 git pull의 차이와 적절한 사용 상황

 

git fetch와 git pull 명령어는 둘 다 원격 저장소로부터 데이터를 가져오는 명령어이다. 하지만 차이점이 있다.

 

git fetch

우선 git fetch는 local Git에게 원격 저장소의 최신 메타 데이터를 확인하라는 지시를 내린다.

이때 원격 저장소에 변경사항이 있는지 확인만 하고, 변경된 데이터를 로컬로 가져오지는 않는다.

 

그렇기에 원격 브랜치의 상태를 업데이트 해주지만 현재 작업중인 로컬 브랜치에는 변화를 주지 않는다. 

→ 안전하게 원격 저장소의 상태를 로컬에서 확인 가능하다.

git fetch origin

git fetch 명령을 실행하는 방법이다.

 

 

git pull

git pull은 git fetch와 git merge의 결합된 명령어이다.

원격 저장소의 데이터를 가져온 후, 체크아웃 된 브랜치 (작업 중인 브랜치)에 해당 데이터를 복사하여 병합한다.

현재 작업중인 브랜치에서 원격 저장소의 최신 변경사항을 빠르게 반영하고자 할 때 유용하게 사용한다.

git pull origin main

git pull 명령을 실행하는 방법이다.

 

 

이처럼 원격 저장소의 변경된 정보를 로컬 Git에 병합하는지 여부로 차이가 생긴다.

 

각 방법의 적절한 사용 상황

• fetch는 원격 저장소와 로컬 저장소의 변경 사항이 다른 상황에서 이를 비교하고 대조하는 확인작업을 수행할 때
  사용하는 게 적합하다. 이런 확인작업을 통해 충돌 사항이 있다면 해결하고 나서 git merge를 하여
  안전하게 병합할 수 있다.
• pull은 빠르게 최신 상태로 작업해야 하는 경우에 편리하게 사용할 수 있다.