Original article: An introduction to Git merge and rebase: what they are, and how to use them

영어 원문: An introduction to Git merge and rebase: what they are, and how to use them 글쓴이: [Vali Shah]

개발자로서 많은 사람이 머지(merge)와 리베이스(rebase) 중에 하나를 선택해야 하는 경우가 발생합니다. 인터넷에서 얻는 모든 참고 자료와 함께 모든 사람은 "심각한 문제가 발생할 수 있으니, 리베이스는 절대 사용하지 마세요."라고 생각합니다. 그럼, 리베이스와 머지가 무엇인지, 사용해야 하는 이유(사용해서는 안 되는 이유) 및 사용 방법에 관해 설명하겠습니다.

깃 머지와 깃 리베이스는 동일한 용도로 사용됩니다. 둘 다 여러 브렌치에서의 변경 사항을 하나로 통합하도록 설계됐습니다. 비록 최종 목표는 같지만, 이 두 방법은 다른 방식으로 목표를 달성하며, 더 나은 소프트웨어 개발자가 되기 위해서 차이점을 아는 것이 좋습니다.

이 질문은 깃 커뮤니티에서 말이 많습니다. 어떤 사람들은 항상 리베이스를 사용해야 한다고 생각하고, 다른 사람들은 항상 머지해야 한다고 믿습니다. 각각의 측면은 설득력 있는 이점을 가지고 있습니다.

깃 머지

버전 제어 시스템을 사용하는 개발자는 일반적으로 깃 머지를 사용하는 게 관행입니다. 테스트, 버그 수정 혹은 기타 이유로 브렌치가 생성됐는지 여부와 관계없이, 머지를 실행하면 변경 사항이 다른 위치에 커밋됩니다. 더 구체적으로 말하면, 머지는 소스 브렌치의 내용을 가져와 타겟 브렌치와 병합시킵니다. 이 작업을 통해, 타겟 브렌치만 변경되며 소스 브렌치 기록은 동일하게 유지됩니다.

마스터에서 피처로 머지하는 이미지

마스터 브렌치에서 피처로 머지

장점

  • 간단하고 친숙하다
  • 전체 기록과 연대순으로 보존한다
  • 해당 브렌치의 내용을 유지한다

단점

  • 많은 머지 커밋으로 커밋 기록이 오염될 수 있다.
  • git bisect를 사용한 디버깅이 더 어려워질 수 있다.

사용 방법

checkoutmerge 명령어를 사용해 마스터 브렌치를 피처 브렌치로 머지해 보겠습니다.

$ git checkout feature
$ git merge master

(or)

$ git merge master feature

이렇게 하면 두 브렌치의 기록을 두고 있는 피처 브렌치에 새로운 "머지 커밋"이 생성됩니다.

깃 리베이스

리베이스는 한 브렌치에서 다른 브렌치로 변경 사항을 통합하는 또 다른 방법입니다. 리베이스는 모든 변경 사항을 하나의 패치로 압축합니다. 그런 다음 타겟 브렌치에 이 패치를 통합합니다.

머지와 달리 리베이스는 완료된 작업을 한 브렌치에서 다른 브렌치로 전송하기 때문에 기존의 기록을 제거합니다. 이 과정에서 원치 않는 기록이 제거됩니다.

리베이스는 변경 사항이 계층 구조의 맨 위에서 아래로 전달되는 방식이며, 머지는 변경 사항이 다시 위로 흐르는 방법입니다.
마스터에서 피처로 리베이스하는 이미지

마스터 브렌치에서 피처로 리베이스

장점

  • 복잡해졌을 수도 있는 기록을 간소화한다
  • 단일 커밋을 조작하기 쉽다(예: 되돌리기)
  • 여러 브렌치가 있는 분주한 리퍼지토리에 머지 커밋 "노이즈"를 방지한다
  • 중간 커밋을 단일 커밋으로 만들어 정리하고, 이는 DevOps 팀에 도움이 된다

단점

  • 소수의 커밋으로 기능을 축소하면 내용이 숨겨질 수 있다
  • 공용 리퍼지토리를 리베이스하는 것은 팀으로 작업할 때 위험할 수 있다
  • 리베이스로 피처 브렌치를 항상 업데이트해야 하므로 더 많은 작업을 해야 한다
  • 리모트 브렌치로 리베이스하려면 강제 푸쉬가 필요하다. 사람들이 직면하는 가장 큰 문제는 강제 푸시를 하지만 git push 기본값을 설정하지 않는 것이다. 이에 따라 로컬과 리모트 모두에서 동일한 이름을 가진 모든 브렌치가 업데이트되고, 이 문제는 처리하기가 매우 어렵다.
부정확하게 리베이스하다가 의도치 않게 기록을 재작성하면, 심각한 문제로 이어질 수 있으니, 리베이스 작업을 시도하기 전에 반드시 다시 한 번 확인하세요!

사용 방법

다음 명령을 사용해 피처 브렌치를 마스터 브렌치로 리베이스합니다.

$ git checkout feature
$ git rebase master

이렇게 하면 전제 피처 브렌치가 마스터 브렌치 위로 이동합니다. 원래(피처) 브렌치의 각 커밋에 대해 완전히 새로운 커밋을 만들어 프로젝트 기록을 다시 작성해 이를 수행합니다.

인터렉티브한 리베이스

Interactive 리베이스는 커밋이 새로운 브렌치로 이동할 때 커밋을 변경할 수 있습니다. 이는 브렌치의 커밋 기록을 완벽하게 제어할 수 있기 때문에 자동화된 리베이스보다 강력합니다. 일반적으로 피처 브렌치를 마스터에 머지하기 전에 지저분한 기록을 정리하는 데 사용됩니다.

$ git checkout feature
$ git rebase -i master

이 명령은 에디터를 열어 이동하려는 모든 커밋을 나열합니다. 아래 코드블록 같이 말이죠.

pick 22d6d7c Commit message#1
pick 44e8a9b Commit message#2
pick 79f1d2h Commit message#3

나열된 커밋의 내용과 순서는 리베이스가 수행된 후에 브렌치 이력이 어떻게 보일지 보여줍니다. 커밋들을 재정렬해 원하는 대로 기록을 표시할 수 있습니다. 예를 들어, pick 대신 fixup, squash, edit과 같은 명령어를 사용할 수 있습니다.

리베이스로 재정렬하는 명령어 리스트

둘 중에 무엇을 선택해야 할까

그래서 뭐가 제일 좋을까요? 전문가들이 무엇을 추천할까요?

모든 팀이 다르기 때문에, 하나가 더 좋다고 일반화하고 결정하는 것은 어렵습니다. 하지만 일단 결정을 해야 뭐라도 시작하겠죠?

각 팀은 깃 리베이스와 머지를 사용할 상황을 정할 때 질문 몇 가지를 고려해야 합니다. 결과적으로 하나의 워크플로우 전략이 다른 하나보다 나은 것이 아니기 때문입니다. 그것은 당신의 팀에 따라 다릅니다.

조직 전체의 리베이스 및 깃 역량 수준을 고려해 봅시다. 머지의 추적 가능성 및 기록과 비교해 리베이스의 단순성을 어느 정도 중요시 하는지 결정합니다.

마지막으로, 머지와 리베이스에 대한 결정은 명확한 브렌치 전략의 맥락에서 고려되어야 합니다. (브렌치 전략에 대한 자세한 내용은 이 문서를 참조하세요). 성공적인 브렌치 전략은 팀 조직을 중심으로 설계됩니다.

제가 추천하는 방법은?

팀이 성장함에 따라, 항상 머지를 사용한다면 이후 개발 변경 사항을 추적하거나 관리하기가 어려워집니다. 깨끗하고 이해하기 쉬운 커밋 기록하기 위해서는, 리베이스를 사용하는 것이 효과적이고 합리적입니다.

다음 상황과 지침을 고려하면, 리베이스를 최대한 활용할 수 있습니다.

  • 로컬에서 개발 중인 경우: 다른 사람과 작업을 공유하지 않은 시점에는 기록을 깔끔하게 유지하려면 머지보다 리베이스를 선호해야 합니다. 리퍼지토리의 개인 포크가 있고 다른 개발자와 공유되지 않는 경우, 당신의 브렌치를 푸쉬한 후에도 안전하게 리베이스 할 수 있습니다.
  • 코드리뷰할 준비가 된 경우: pull request(PR)을 생성했거나 다른 사람들이 당신의 작업을 검토하기 위해 해당 작업을 본인의 로컬 저장소로 포크할 가능성이 있다면, 그 시점에서는 작업을 리베이스를 해서는 안 됩니다. '재작업' 커밋을 만들고 피쳐 브렌치를 업데이트해야 합니다. 이렇게 하면 PR의 추적 가능성에 도움이 되며 우발적인 기록 손상을 방지합니다.

-검토가 완료됐으며 타겟 브레치에 통합될 준비가 된 경우: 축하합니다! 당신의 피처 브렌치를 삭제하려고 합니다. 이 시점부터 다른 개발자가 변경 사항을 패치-머지하지 않을 것이라는 점을 감안할 때, 이는 당신의 기록을 정리할 기회입니다. 이 시점에서 기록을 재작성하고 원래 커밋과 성가신 'pr 재작업'과 '머지' 커밋을 작은 집중 커밋 집합으로 만들 수 있습니다. 이러한 커밋에 대한 명시적인 머지를 만드는 것은 선택 사항이지만 그럴만한 가치가 있습니다. 이는 피쳐가 마스터로 전환된 시점을 기록합니다.

마치며

이 글이 깃 머지깃 리베이스에 대한 이해도를 높였기를 바랍니다. 머지 혹은 리베이스 방식을 사용할지는 항상 논쟁의 여지가 있습니다. 그러나 이 글이 여러분의 의구심을 해소하고 팀에 맞는 접근 방식을 채택하는 데 도움이 되기를 바랍니다.

깃 워크플로우에 대한 글을 기대하고 있습니다. 다음에 제가 쓰길 원하는 주제가 있으면 댓글 달아주세요. 감사합니다!

소프트웨어 개발자를 위한 코딩 스쿨