이전 회사에서 SVN을 사용할 때에는 main trunk에서 주로 작업을 했었다. 작은 팀이어서 각자가 담당하는 디렉토리를 다른사람과 공유할 일도 없고 하다보니 큰 문제는 발생하지 않았다. 일을 시작하기 전과 commit 하기 전에 svn update를 반드시 하기로 약속 했었고, 그런대로 잘 지켜 졌었던 것 같다.

영국에 온후로 윈도우 기반의 서버 개발을 하게 되었다. 회사에서는 오래전부터 써오단 Perforce라는 상용 버젼관리 툴을 사용해 오던 터라, SVN을 사용할 일은 전무 하였다. 그러다가 몇달 전, 새로운 프로젝트가 Linux 기반으로 결정됨에 따라서 다시 SVN과 함께 하게 되었다.

한국에서 하던것과 다른점 하나는, 무엇을 구현하던지 무조건 branch를 만들어서 하라는 것이었다. 개념이야 알고 있었지만 실제로 자주 써보지 않았으니 조금 막연하기도 하고, 한편으로는 코드 한두줄 고치는데도 branch를 만들어야 한다는게 비효율적인것 같았다. 하지만 내 예상외로, 프로젝트의 특성상 작은 코드라도 여러명이 함께 일하게 되는 경우가 상당히 잦았고, 그럴때마다 branch의 유용성을 실감하면서 지금껏 잘 쓰고 있다.

Branch를 만들어서 개발하고, 다시 Trunk에 merge 하는 과정은 단순한것 같으면서도 처음 시작할때는 그렇게 수월하지만도 않은것이 사실이다. 혹시나 이제 막 branch를 사용하려고 하는 사람들을 위해 간략히 정리해 보려고 한다.


1. Branch 생성

Branch를 생성하는것은 매우 간단하다. Trunk를 직접 복사하는 방법도 있으나 가장 효율적이고 확실한 방법은 아래와 같다.

이렇게 생성된 branch는 checkout을 통해서 사용할 수 있다. 그리고 당연한 이야기지만 본인 말고 다른사람들은 사용할 리가 없으니 안전하다.


2. Branch에서 작업중

Branch에서 작업할 때에는 남들과 상관 없이 마음대로 commit 할 수 있어서 편리하다. 그런데 조금 귀찮은 것이 있다면, 주기적으로 Trunk의 변동 사항을 적용해 주는것이 좋다는 것이다. 미리미리 하지 않으면 나중에 둘이 함께 앉아서 resolving을 해야 하는 더욱더 귀찮은 상황이 발생할 수도 있으니 말이다.

Repositoy 설정이 잘 되어 있다면, Trunk의 변동 사항이 메일로 올것이다. 나는 그럴때마다 변동사항을 내 branch에 적용한다. 적용하는 방법은 간단히 아래와 같다.

위와 같이하면, 현재 내 디렉토리에 다운로드 받아져 있는 Revision에 Trunk의 변동사항을 적용하게 된다. 이러한 과정을 Merge라고 부른다. 이때 Conflict 들이 발생할 수 있는데, 이를 모두 깔끔히 해결한 후 즉시 commit을 해두도록 한다.


3. Branch 작업 완료 후

Branch에서의 작업이 완료 되면, 이를 다시 Trunk에 적용해야 할것이다. 이부분이 가장 햇갈렸던 부분인데, 구글링을 하다보면 더더욱 햇갈린다. 적어도 나의경우에는 그랬다. 특히나 여러 사람에 의해 trunk에 많은 변경사항이 발생하여, 내 branch가 많이 달라져버린 경우라면 상당히 귀찮은 일들이 발생한다. 

여러가지 방법이 있지만 나의 경우에는 다음과 같은 과정을 통해 Merge into trunk를 수행한다.

첫째, (2) 과정을 수행한다. 이 과정을 Merge into trunk 하기전에 반드시 해두어야만 나중에 Auto resolving이 불가능한 tree conflict를 예방할 수 있다.

둘째, 상위 디렉토리에서 Trunk를 하나 새로 checkout 한다. 이 때, 혼동되지 않도록 이름을 잘 짓는다.

셋째, repository path와 임시로 받아놓은 싱싱한 Trunk를 이용해 merge를 수행한다. 여기서 빨간 글씨로 써 져 있는 --dry-run은 merge command의 옵션중 하나인데, 이 옵션이 있으면 실제로 merge를 수행하지 않고 테스트만 해보는 것이다. 문제 없는 것 같으면 저 옵션을 제거하고 다시 실행하여 실제로 merge가 되도록 한다.


Merge중에는 별의 별 이유로 별의 별 conflict들이 발생할 수 있지만, 첫째 과정을 제대로 수행했다면 conflict이 없어야 정상이다. 있으면 뭔가 이상한 것이니 첫째 과정을 다시 잘 수행하길 권한다. conflict 없는 깨끗한 복사본이 만들어지면, 이를 check in 한다.