Mercurial Workflows: Stable & Default

원문: http://stevelosh.com/blog/2010/05/mercurial-workflows-stable-default/

이 글은 다양한 Mercurial 작업 흐름을 설명하는 일련의 글 중 두 번째이다. 첫 번째에서는 가장 간단한, 필요할 때에 브랜치를 만든다를 설명했다.
여러분이 더 큰 프로젝트에서 일한다면 좀 더 구조화한 무언가가 필요할 것이다. 이 글에서는 “stable과 default” 작업 흐름에 대해 설명한다.

“Stable과 Default”에 대해 간단히

이 작업 흐름에 대한 기본 개념은 default와 stable이라는 두 브랜치를 유지하는 것이다.

• default는 새로운 기능(feature and functionality^[1])을 추가하는 브랜치이다.
• stable은 버그를 수정하고 새 기능과 관계 없는 문서적인 개선 등을 추가하는 브랜치이다.

항상 버그는 stable에서 수정하고 default에 병합하므로 default는 stable을 포함한다.

(“주요 배포판(major release)”이 준비 될 때마다) 주기적으로 default에서 stable로 병합해 새 기능을 배포판에 포함할 수있다.

Mercurial 자체 개발에서는 이 작업 흐름을 사용하며 중대형 프로젝트에 적절하다.

브랜치 설정

이 작업 흐름을 사용하려면 stable로 이름 붙인 브랜치를 만들어야 한다.

이렇게 하고 나면 프로젝트 사용자는 stable 브랜치를 복제해 여러분의 코드에서 상대적으로 안정한 버전을 사용한다고 확신할 수 있다. 이처럼 브랜치를 복제하려면 다음과 같이 하면 된다.

이렇게 하면 stable 브랜치에 있는 체인지셋(과 그 이전의 변경 내용 중 조상에 해당하는 것)만 포함해 여러분의 저장소를 복제한다.

변경하기

이 작업 흐름에서 목표는 버그 수정이 아닌 개발은 모두 default 브랜치에서 하는 것이다. 순수 버그 수정은 stable 브랜치에서 진행해 stable 브랜치를 가능한 “안정적”으로 유지하도록 한다.

매우 불안정하지만 최신 기능을 원하는 사용자는 default 브랜치를 사용할 수 있다. 아마 여러분의 프로젝트에는 기꺼이 default에서 작업하며 여러분이 해당 브랜치에 추가한 새 기능에서 찾은 버그를 여러분에게 알려 주는 사용자가 있을 것이다.

stable 브랜치에 변경을 할 때마다 그 내용을 default에 병합하려 할 것이므로 default는 항상 stable을 포함한다. 이를 통해 default를 가능한 안정적으로 만들고 주요 배포판이 준비될 때마다 default를 다시 stable로 병합하는 것이 더 쉽도록 한다.

다음은 저장소 그래프가 어떻게 되는지 보여주는 예이다.

매번 stable에 변경한 내용을 어떻게 default에 병합하는지에 주의한다.

주요 버전 배포하기

언제든 일반 대중에게 버그 수정이 아닌 기능 개선 내용을 배포할 때가 올 것이다. 기능 개선 내용은 default 브랜치에서 만들므로 배포할 준비가 되면 default 내용을 stable로 병합한다.

프로젝트에는 불안정한 최신 기능을 사용하는 이보다 stable 사용자가 더 많으므로 주요 버전을 배포한 후에는 분명히 평상시보다 더 많은 버그 보고를 받을 것이다. 이는 예상한 것이므로 그에 대해 준비해야 한다.

배포판에 태그 붙이기

모든 제대로된 프로젝트에서는 배포판에 태그를 붙여야 한다. 이를 통해 사용자는 동작하는 여러분의 프로젝트 버전을 쉽게 알고 사용할 수 있다.

배포판에 태그는 언제 붙이고 태그 내용은 무엇으로 해야 할까? 의미론적 버전 번호 붙이기 사양은 각 배포판에서 바뀐 것을 프로젝트 사용자가 (넓은 의미에서) 쉽게 알 수 있도록 하는 훌륭한 지침이 된다.

요약하면, 의미론적으로 버전을 붙인 프로젝트에서 태그는 다음과 같다.

• 태그 형식은 “v[MAJOR].[MINOR].[BUGFIX]”이다.
• 태그에서 주 버전이 “0”일 때는 어느 것도 보장하지 않으며, 이는 알파/베타 버전에서 사용한다.
• 버그 수정 버전을 증가 시키면 “버그를 수정한 것”을 뜻한다.
• 부 버전을 증가 시키면 “하위 호환성을 유지하며 새 기능(functionality)을 추가한 것”을 뜻한다.
• 주 버전을 증가 시키면 “하위 호환성이 깨진 것”을 뜻한다.

불행히도 이 작업 흐름에서 의미론적으로 버전을 붙인 태그를 추가하는 건 다소 복잡하다. 의미론적인 태그를 붙이는 규칙은 다음과 같다.

• stable 브랜치에서 버그를 수정할 때는 stable에 대해 버그 수정 버전을 증가 시키고 stable을 default에 병합한다.
• 새 기능(functionality)을 추가하고 대중에 배포할 때가 되면 default를 stable로 병합하고 stable의 부 버전을 증가 시킨다.
• 하위 호환이 안 되는 배포판을 배포할 준비가 되면 default를 stable로 병합하고 stable의 주 버전을 증가 시킨다.

이 과정에서 문제는 default에 버전 태그를 절대 붙이지 않는다는 점이다. 하지만 default 사용자는 불안정하지만 최신 기능을 원하며 안정성은 중요하지 않을 것이므로 큰 문제는 아니다.

Default와 Dev 대신 왜 Default와 Stable인가?

이 작업 흐름에는 두 브랜치 default와 stable이 있다고 설명했다. 왜 default를 새로운 개발에 사용하고 “stable” 브랜치를 명명한 브랜치로 했는지 궁금해 할지도 모르겠다.

이는 일반적으로 stable보다 default에 체인지셋을 아주아주 많이 추가하기 때문이며 “개발” 브랜치를 기본으로 하는 게 개발자에게도 더 쉽다.

default를 “안정” 브랜치로 하고 dev 브랜치를 만들어 “불안정”한 변경에 사용한다고  해서 잘못된 것은 절대 아니다. 여러분의  프로젝트에서  새 기능(functionality)은 거의 추가하지 않고 버그 수정이 더 중요하다면 이렇게 하는 게 분명히 더 나을 것이다.

게다가 이렇게 하면 (브랜치를 지정하지 않고도) 사용자가 자연스럽게 안정 버전을 얻는 장점도 있다. 안내문을 제공하더라도 많은 사용자는 일부러 수고하며 읽으려 하지 않으므로 여러분의 프로젝트에서 버그 수정을 과도하게 하지 않는다면 그렇게 사용하는 강한 근거가 된다.

어떻게 사용할지는 여러분에게 달렸다.