Mercurial Workflows: Branch As Needed

원문: http://stevelosh.com/blog/2010/02/mercurial-workflows-branch-as-needed/

얼마전 빈센트 드리에센(Vincent Driessen)성공적인 git 브랜치 모델(a successful git branching model)의 예에 대한 글을 올렸다. 그 글은 많은 git 사용자에게 매우 유용했기에 더칸 오치만(Dirkjan Ochtman)은 내가 Mercurial 사용자를 위해 비슷한 글을 써야 한다고 내게 얘기했다.

난  그저 한 가지 브랜치 작업 흐름에 대해 설명하는 글 하나로만 끝내지 않기로 했다. Mercurial은 유연해서 서로 다른 여러가지 작업 흐름을 지원할 수 있으며 그 중 어떤 것은 다른 것보다 특정 프로젝트에 더 알맞을 것이다. 그러므로 각 작업 흐름에 대해 설명하는 글을 하나씩 이어서 쓰려한다.

내가 생각할 수 있는 가장 간단한 예인 “브랜치 만드는 것을 절대 두려워 말고 필요할 때마다 하라”는 것으로 시작하겠다.

참고: 이 일련의  글에서는 여러분이 기본적인 Mercurial 명령에 익숙하며 Mercurial에서 여러가지 브랜치 작업을 어떻게 하는지 알고 있다고 가정한다. Mercurial 명령을 다시 봐야 하면 hg book을 살펴 본다. 브랜치 개념에 대한 정보가 더 필요하면 내가 올린 Guide to Branching in Mercurial이 맘에 들지도 모르겠다.

“필요할 때 브랜치를 만든다”에 대해 간단히

이 작업 흐름에서는 실제 브랜치를 만들어야 할 때까지는 그에 대해 걱정하지 말라는 게 기본 개념이다.

미리 해야 할 추가 작업이 없어 매우 간단하게 유지할 수 있다는 것이 장점이다.

단점은 그다지 유연하지 않다는 것이다. 작은 프로젝트에는 훌륭하지만 규모가 더 커지면 분명히 좀 더 구조화할 필요가 있을 것이다.

예제 시나리오

이 작업 흐름은 작은 프로젝트에 가장 적합하다. 다음 예제 저장소에는 일련의 체인지셋이 선형적으로 하나만 있다.

Sample Repository

이 예에서는 기능을 추가하고 버그를 수정하는 등 프로젝트에 참여하는 개발자는 대체로 한 명이다.

저장소는 온라인으로 연결되어 있으므로 다른 이가 그  코드를 받을 수 있으며 원하면 기능을 추가하고 버그를 수정할 수 있지만 작은 프로젝트이므로 그런 일은 그리 자주 생기지 않는다.

참고: 저장소에 있는 체인지셋에 대해 그래프로 표시해 보는 것은 어떻게 진행했는지 볼 수 있어 유용하다. 저장소를 ASCII 예술로 빠르게 표현해 주는 멋진 그래프를 보고 싶으면 graphlog 확장[1]을 사용하면 된다.

브랜치 준비

이 작업 흐름에서는 미리 설정해 둘 것이 전혀 없다. 변경 내용을 커밋하고 (BitBucket처럼) 다른 이가 그 내용을 받을 수 있도록 어딘가로 보내는(push) 등 그저 평상시처럼 Mercurial을 사용하면 된다.

프로젝트에 기여하기

누군가가 여러분의 프로젝트를 사용하기 시작해 버그를 찾았다고 해 보자. 그들은 직접 버그를 수정하고 그 체인지셋을 커밋한다. 그런 후 (자신의 BitBucket 계정과 같은) 공개 장소 어딘가에 그 저장소 복사본을 올릴 수 있으며 저장소는 다음과 같은 모습일 것이다.

Contributor Repository

일단 공개 장소 어딘가에 변경 내용을 올려 둔 다음에는 여러분에게 이메일을 보내 다음처럼 얘기할 수 있다.

이봐요, 당신 프로젝트에서 버그를 수정했어요.

수정 내용은 당신 저장소를 복제한 내 저장소 체인지셋 be3063198fea이고 위치는 http://…/ 예요.

기여자가 보낸 변경 내용 병합하기

여러분이 이와 같은 이메일을 받으면 그 저장소로 찾아가 해당 체인지셋을 살펴볼 것이다. 내용이 좋아 여러분의 저장소에 반영하기로 결심한다면 간단히 hg pull http://their/repo/ 같은 명령만 실행하면 된다.

여러분이 저장소에 새 변경 내용을 추가하지 않았으면 저장소 모습은 상대와 정확히 같아질 것이고 새로운 팁으로 갱신해 평상시처럼 작업을 계속 하면 된다.

상대가 여러분의 저장소를 복제 (또는 마지막으로 pull) 한 때와 여러분이 그 이메일을 읽고 상대방의 변경 내용을 pull 한 때 사이에 여러분이 무언가 변경한 게 있으면 어떻게 될까? 이 경우 상대 저장소에서 변경 내용을 가져온 후 여러분 저장소는 다음처럼 된다.

Sample Repository Before Merging

존(John)이 수정한 체인지셋과 여러분이 리팩토링한 체인지셋 모두 부모가 같으므로 여러분 저장소에는 “익명 브랜치” 두 개가 생겼다. Mercurial에서 이는 전혀 문제되지 않는다. 원하는 대로 저장소에 “익명 브랜치”를 만들 수 있다.

분명 이런 브랜치를 병합하려 할 텐데, 그럴 때는 (이 체인지셋에 위치해 있는 게 아니라면) hg update a2125cb20c54를 실행한 다음 hg merge be3063198fea를 실행해 존의 수정 내용을 병합한 새 변경 내용을 만든다. 결과는 다음과 같다.

Sample Repository After Merging

이제 다시 헤드가 하나인 상태로 돌아왔으며 존과 여러분이 변경한 내용을 하나로 병합한 것에서 평상시처럼 작업을 계속하면 된다.

요약

이 작업 흐름은 가능한 가장 간단한 것 중 하나이다. 미리 설정해 둘 것도 없어 프로젝트에 기여하려는 신참에게도 매우 쉽다. 그저 복제, 커밋, 전달(push) 한 후 변경한 내용을 여러분에게 알리는 것이 전부이다. 주 개발자가 한 명이며 기여자가 간혹 나타나는 작은 프로젝트에 매우 좋다.

함께 일하는 이가 많은 프로젝트에서 이 작업 흐름은 꽤 혼란스러울 수 있다. 여러분의 저장소 그래프는 복잡하게 얽혀 보일 것이므로 좀 더 구조화한 작업 흐름을 필요로 할 것이다.

난 앞으로 더 복잡한 브랜치 작업 흐름에 대한 글을 적어도 두 세 개 정도 더 쓸 것으로 계획하고 있다. 내가 글을 썼으면 하는 특정한 예가 있으면 그에 대해 알려주길 바란다!


[1] 윈도에서는 TortoiseHg를 사용하면 작업대(workbench)에서 쉽게 확인 할 수 있다.

You may also like...