[코드잇][위클리페이퍼][1주차] Git 내용에 관한 정리

아래는 1주차 위클리페이퍼 주제이다.

• git rebase와 git merge의 차이점을 설명하고, 각각 어떤 상황에서 사용하는 것이 적절한지 설명해주세요.
• git fetch와 git pull의 차이점을 설명하고, 각각을 사용하는 것이 적절한 상황을 설명해주세요.

---

먼저 첫번째 주제에 대한 설명이다.

브랜치를 병합할 때, merge와 rebase 두 방식을 사용할 수 있다. merge는 어떤 브랜치에서 커밋이 되었는지, 브랜치의 분기와 병합이 언제인지 기록이 남는다. 반면 rebase는 이름 그대로 현재 브랜치의 시작점(base)을 목적지 브랜치의 최신 커밋 뒤로 재배치한다. merge와 달리 별도의 병합 커밋을 남기지 않기 때문에, 처음부터 목적지 브랜치에서 작업한 것처럼 보인다. 이 과정에서 커밋 해시가 새로 생성되어 히스토리가 재작성된다는 특징이 있다.

 

각 방식의 특성에 따른 적절한 사용 상황을 생각해보았다. merge는 모든 브랜치의 가지와 히스토리를 모두 보존하니까 일반적인 협업이나 작업의 전체 맥락을 유지해야 할 때 좋다. 과거 이력이 상세히 남으므로 문제 발생 시 추적이 쉽기 때문이다.

 

그에 반해 rebase는 브랜치를 히스토리를 선형적으로 깔끔하게 유지하고 싶을 때 용이하다. 특히 충돌이 여러 번 예상되는 상황이라면 merge보다 rebase가 유리할 수 있다. merge는 병합 시점에 커밋들의 충돌을 모두 한꺼번에 해결해야 해서 복잡도가 높지만, rebase는 커밋을 하나씩 적용하며 충돌을 단계적으로 해결하기 때문이다. 덕분에 어떤 변경 사항에서 문제가 생겼는지 파악하기 쉽고 대응도 훨씬 수월하다. 다만, 이미 원격 저장소에 공유된 커밋을 rebase하면 팀원들의 히스토리와 충돌이 발생하므로 협업 중에 사용하는 것은 까다로운 규칙이 필요하다. 자신만이 작업중인 Feature브랜치에서 한정하여 사용해야 한다는 Golden Rule을 작성하는 것이 좋다. 또한, 원격 반영 시 --force-with-lease(마지막으로 확인한 원격 상태와 현재 상태가 다르면 push 중단)와 같은 방법으로 push 하는 것이 히스토리 충돌을 방지하고 프로젝트의 무결성을 지킬 수 있다.

 

대규모 협업에서는 수많은 브랜치가 병합되면서 발생하는 복잡한 브랜치 구조와 의미 없는 머지 커밋들로 인해 히스토리 추적이 어려워질 수 있다. 이럴 때 Squash and Merge 방식이 아주 훌륭한 대안이 된다.

이 방식은 Rebase처럼 메인 브랜치의 히스토리를 선형적으로 유지해주지만, 리베이스와는 달리 작업 브랜치의 자잘한 커밋들을 단 하나의 커밋으로 압축하여 병합한다.(만약 특정 커밋만 고르거나 합치고 싶으면, rebase의 -i 옵션으로 할 수 있다.) 덕분에 메인 브랜치에는 '기능 단위(Feature unit)'의 굵직한 커밋만 남게 되어, 전체적인 프로젝트의 흐름을 파악하기가 훨씬 쉬워진다.

비록 작업 중 발생했던 세부적인 커밋 기록은 사라진다는 단점이 있지만, 대규모 프로젝트의 유지보수 관점에서는 군더더기 없는 깔끔한 브랜치 구조를 가질 수 있다는 점이 훨씬 큰 메리트로 작용한다.

---

두번째 주제에 대한 설명이다.

원격 저장소의 변경 이력을 로컬로 가져올 때는 fetch와 pull을 사용한다. fetch는 원격 저장소의 최신 메타데이터와 커밋 객체들을 로컬로 다운로드하되, 현재 작업 중인 브랜치에 직접적인 병합은 수행하지 않는다. 반면, pull은 fetch를 수행한 직후 자동으로 merge(또는 설정에 따라 rebase)를 진행하여 로컬 코드를 즉시 갱신한다.

이러한 특성을 바탕으로 작업 상황에 따른 적절한 선택 기준을 정리해 보았다.

 

따라서 fetch는 높은 안정성과 코드 리뷰가 필요한 협업에서 용이하다 . 원격에 쌓인 커밋이 많거나 변경 사항이 방대할 때, 무작정 pull을 받으면 예상치 못한 충돌이 발생할 수 있다. 이때 fetch를 사용하면 원격의 변경 내용을 로컬 작업 공간에 영향을 주지 않고 git log나 git diff로 미리 검토할 수 있어 안전하다. 또한, 여러 명의 팀원이 동시에 작업하는 환경에서는 내가 작업 중인 코드와 원격의 코드가 충돌할 가능성이 크다. 이때 fetch 후 원격 브랜치를 확인하는 과정은 충돌지점을 미리 파악하여 병합 전략을 세울 수 있게 해준다.

 

반면 pull은 기본적으로 개인 프로젝트에서 사용하는 것이 효율적이나, 협업에서 사용을 할 것이라면 새로운 작업을 시작하기 위에 메인 브랜치에서 분기하기 전에 사용하는 것이 좋다. 충돌 위험이 없다는 것이 확실할 때 원격의 최신 상태를 즉시 반영하여 작업 효율을 높이고 싶을 때 사용하면 좋다. 위에서 언급한 rebase와 함께 사용한다면 선형적이고 깔끔한 히스토리를 유지하는게 효과적이다.