Mercurial workflow – branching model

Mercurial(머큐리얼, Hg)에서 브랜치와 작업 흐름에 대한 내용은 Steve Losh의 다음 글이 매우 유명합니다.

위 글 중 두 번째에서도 밝히고 있는, ‘성공적인 Git 브랜치 모델‘이란 글 역시 매우 유명합니다. 이 글은 이런 글을 바탕으로 구성한 작업 흐름입니다. 물론 그림 형식은 성공적인 Git 브랜치 모델에서 따왔습니다. 특히 Steve Losh 글 중 세 번째, Stable & Default에서 제시하는 방법은 Mercurial에서 가장 기본적으로 사용하는 모델입니다. 이를 바탕으로 필요에 따라 브랜치를 만들어 진행하는데 각 브랜치별 설명은 다음과 같습니다.

Mercurial Workflow

  • default
    • 주 개발 브랜치로 대부분의 기능 개발은 여기서 합니다. 릴리스 시점에 stable로 병합합니다.
  • stable
    • 주 릴리스 브랜치로 버그 수정 등 릴리스 안정화를 합니다. 수정할 때마다 default와 필요에 따라 다른 브랜치에 병합합니다.
  • feature
    • 개발 기간이 길거나 변경이 많아 기능을 독립적으로 개발해야 할 때 사용합니다. 브랜치 이름은 feature-* 형식입니다. default나 develop 브랜치에서 분기하고 진행을 마치면 처음 분기했던 브랜치로 다시 병합합니다.
  • develop
    • default 배포 전에 먼저 배포해야 할 때나 이전 배포 버전을 바탕으로 기능을 추가해야 할 때 사용합니다. 브랜치 이름은 develop-* 형식입니다. default나 stable 브랜치에서 분기하고 진행을 마치면 default, stable과 필요에 따라 다른 브랜치에 병합합니다.
    • 이전 버전에서 분기할 때 이미 생성한 버전과 겹치거나 다른 브랜치의 높은 버전을 먼저 출시하는 등 출시 시기에 따라 버전 정보만으로 혼란이 있을 때는 분기하는 버전을 유지하고 뒤에 u1, u2 등을 추가합니다. 예를 들면, develop-1.0.0.u1과 같습니다. 빌드할 때도 버전 정보에 (update1), (update2) 등을 붙입니다.
  • hotfix
    • 이전 배포 버전에서 즉시 처리해야 하는 문제(오류)만 수정 배포합니다. 단 stable, develop 브랜치에서 바로 수정할 수 있으면 만들지 않습니다. 브랜치 이름은 hotfix-* 형식입니다. stable에서 분기하고 진행을 마치면 default, stable과 필요에 따라 다른 브랜치에 병합합니다.
    • 이전 버전에서 분기할 때 이미 생성한 버전과 겹치거나 다른 브랜치의 높은 버전을 먼저 출시하는 등 출시 시기에 따라 버전 정보만으로 혼란이 있을 때는 분기하는 버전을 유지하고 뒤에 fix1, fix2 등을 추가합니다. 예를 들면, hotfix-1.0.0.fix1과 같습니다. 빌드할 때도 버전 정보에 (fix1), (fix2) 등을 붙입니다.

위 브랜치 중 develop은 상황에 따라 사용하지 않아도 됩니다. 업무 특성상 고객 요청으로 현재 진행 중인 것과 별개로 일부 기능을 먼저 배포해야 할 때가 있습니다. 또는 현재 사용 중인 버전을 바탕으로 다른 것은 제외하고 특정 기능만 넣어 달라고 요청할 때도 있는데 이럴 때 사용합니다. 이런 내용을 제외하면 실질적으로는 일반적으로 쓰고 있는 흐름에서 벗어나지 않습니다.

기본적으로 이런 브랜치 정책을 갖는 것도 중요하지만, 무엇보다 중요한 것은 브랜치를 가급적 적게 유지하는 겁니다. 브랜치가 많아지면 여기저기 병합도 많이 해야 하므로 실수하기도 쉽고, 복잡하게 얽히는 이력 때문에 개발자들이 꽤 혼란스러워 합니다. 위 그림에서 보면 stable에서 직접 수정해서 릴리스하는 게 그 예입니다. 이 때 기능 추가는 stable에 하지 않도록 주의합니다.

각자 상황에 따라 세부적인 부분은 달라질 수 있으므로 적절히 변형해 사용하면 될 것으로 생각하고 각자 쓰고 있는 브랜치 정책이나 작업 흐름을 함께 나눠 보는 것도 좋을 것 같습니다.

You may also like...