해피 코딩!

Git 활용 - pull fetch merge rebase 본문

Git

Git 활용 - pull fetch merge rebase

지속가능한 성장을 2020. 12. 3. 00:15

해당 내용은 Rebase가 주를 이룹니다.

Fetch

  • local git 에게 원본에서 최신 메타 데이터러 정보를 검색하도록 지시

    https://user-images.githubusercontent.com/35748895/100895654-26600b00-3501-11eb-97c1-27e0d0e87cfd.png

    https://user-images.githubusercontent.com/35748895/100895647-25c77480-3501-11eb-9453-1e6f1cfbc526.png

git diff head origin/main 을 통해 확인 가능

Pull

  • git pull 원격 저장소에서 변경 사항을 가져오고 복사

    https://user-images.githubusercontent.com/35748895/100895634-23651a80-3501-11eb-90c6-948ea9016b3a.png

pullfetch의 차이는 가져온 파일에 대한 merge 수행 여부입니다.

Merge

https://user-images.githubusercontent.com/35748895/100893834-252dde80-34ff-11eb-9b36-4245364b19e7.png

https://user-images.githubusercontent.com/35748895/100893842-26f7a200-34ff-11eb-9897-7f8744f70496.png

  • 머지는 추가적인 커밋을 생성시킨다.

Rebase

https://user-images.githubusercontent.com/35748895/100893849-27903880-34ff-11eb-8efd-68f0c826dcc2.png

https://user-images.githubusercontent.com/35748895/100893851-2828cf00-34ff-11eb-8145-3228d2ce7dbd.png

  • Rebase 는 커밋 히스토리가 보다 깔끔하다.
  • main을 보면 커밋의 ID는 그대로 인데, develop 의 커밋 ID들이 변경이 되었다.
  • head -> develop 에서 git rebase master 하면 된다.

Rebase한 브랜치의 log 를 살펴보면 히스토리가 선형이다. 일을 병렬로 동시에 진행해도 Rebase하고 나면 모든 작업이 차례대로 수행된 것 처럼 보인다.

Rebase는 보통 리모트 브랜치에 커밋을 깔끔하게 적용하고 싶을 때 사용한다.

Rebase를 하든지, Merge를 하든지 최종 결과물은 같고, 커밋 히스토리만 다르다는 것이 중요하다. Rebase의 경우는 브랜치의 변경 사항을 순서대로 다른 브랜치에 적용하면서 합치고, Merge같은 경우는 두 브랜치의 최종 결과만을 가지고 합친다

Rebase의 위험성

이미 공개 저장소에 push 한 커밋을 rebase하지 마라

Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만든다.

다음의 예제는 깃 공식문서에 있는 Rebase의 위험성을 보여주는 예시이다.

  1. 중앙 저장소에서 clone하고 일부 수정을 하면 커밋 히스토리는 아래와 같다.

    https://git-scm.com/book/en/v2/images/perils-of-rebasing-1.png

  2. 팀원 중 누군가가 커밋, 머지를 한 후 서버에 push를 한다. 해당 이 리모트 브랜치를 로컬에 fetch, merge하면 히스토리는 아래와 같다.

    https://git-scm.com/book/en/v2/images/perils-of-rebasing-2.png

  3. 그런데 push한 팀원은 merge한 일을 되돌리고 다시 rebase한다. 이후 저장소에서 fetch하고 나면 히스토리는 이렇게 된다.

대참사 발생 C4가 중복되기 시작한다.

https://git-scm.com/book/en/v2/images/perils-of-rebasing-3.png

  1. 다른 팀원이 c4에 의존하던 커밋 c4, c6을 삭제하고 rebase한 커밋을 다시 push한다.

지속적인 대 참사가 발생한다

로컬에서는 c4'c4, c6, c8등 여러 문제를 가진 커밋들이 생겨난다.

https://git-scm.com/book/en/v2/images/perils-of-rebasing-4.png

  1. git log 로 히스토리를 확인해보면 저자, 커밋 날짜, 메시지가 같은 커밋이 두 개 있다(C4, C4'). 이렇게 되면 혼란스럽다. 게다가 이 히스토리를 서버에 Push 하면 같은 커밋이 두 개 있기 때문에 다른 사람들도 혼란스러워한다. C4C6는 포함되지 말았어야 할 커밋이다. 애초에 서버로 데이터를 보내기 전에 Rebase 로 커밋을 정리했어야 했다.

git pull 명령을 실행할 때 옵션을 붙여서 git pull --rebaseRebase 할 수도 있다.

추가해야 할 내용

  • 해결의 과정을 알지 못합니다.
  • git pull --rebase 의 정확한 의미를 아직 파악하지 못했습니다.
  • git rebase --onto 찾아보기

요약

  • git에서 한 브랜치에서 다른 브랜치로 합치는 방법으론 두 가지가 있다. MergeRebase
  • Merge는 새로운 커밋을 만들어낸다
  • Rebase는 변경된 사항을 Patch로 만들고, 이를 head로 가리키고 있는 브랜치에 적용하는 방법.
  • git pull = git fetch + git merge
  • git pull --rebase = git fetch + git rebase

참고링크

후기

  • 협업을 할 때 rebase 를 사용하지 않고 merge 만 사용하였던 것이 커밋의 로그를 지저분하게 만들고 있었다는 것을 깨닫고 반성하게 되었으며
  • upstream remote 에서 항상 fetch를 확인하지 않고 pull로 파일 및 데이터의 컨플릭트를 해결하였던 부분이 무지에서 비롯된 버릇이었다는 것을 깨닫게 되었다.
  • 항상 올바른 피드백을 주시는 지인에게 무한한 감사를

'Git' 카테고리의 다른 글

Git 활용하기  (0) 2020.11.23
Comments