migration svn to git

svn to git

 

오래된 회사에서 일하다 보니 svn 으로 관리하는 프로젝트들이 허다하다. svn이 나쁘다고 할 수는 없겠지만 솔직히 올드한 건 사실. 팀장님 부터 팀원들까지 git으로 마이그레이션을 원했기 때문에 가장 작은 프로젝트 부터 git으로 옮기기 시작했다. 여전히 많은 프로젝트들이 svn에 남아 있기 때문에 이 작업을 반복해야 할 것이고 그 때 마다 참조하기 위해 포스트로 정리해 둔다.

 

어떤 기술이든지 새로 도입하거나 마이그레이션을 하기 전에 생각해야 할 것은 팀원들의 학습 곡선을 고려해야 한다는 것이다. 우리팀의 경우에도 git에 익숙하지 않은 외주제작자 분들이 계셨기 때문에 일단 외주 제작자 분들이 작업중인 프로젝트들은 마이그레이션의 대상에서 제외했다.

 

또한 마이그레이션 하는 기술이 본질적인 기술 철학과 컨셉에 차이가 있다는 사실도 이해해야 한다. svn 같은 중앙 집중식 버전 관리 시스템과 달리 git은 협업 개발자들을 지원하기 위해서 히스토리와 브랜치 정보를 각각 저장한다. 성공적인 마이그레이션을 하기 위해서는 이 본질적인 차이를 이해하는 것이 중요하다.

 

git 마이그레이션을 위해 고려해야 할 것들

이번에 마이그레이션을 하기 위해 내가 고려한 것들은 다음과 같다.

 

• 현재 도구와 프로세스
• 깃 브랜치 전략 선택
• 히스토리 마이그레이션 여부
• svn 유지 여부
• 팀원들의 git 학습 방법

 

현재 도구와 프로세스

현재 사용하는 각종 개발 도구들과 개발 프로세스를 계속해서 사용할 수 있는지 혹은 불가피하게 수정이 필요한 지 고민해야 한다. 만약 팀에서 공통으로 사용하고 있는 개발 도구들이 git 을 지원하지 않는다거나 하는 경우가 있을 수 있기 때문이다. 물론 2022년 현재 그런 개발 도구는 거의 없을 것으로 생각 된다. 또 현재 개발 프로세스에 얼마나 영향을 끼칠지도 고려해야 한다. 다행히 우리팀의 개발 프로세스에서 git 전환 때문에 바꿔야 할 부분은 크게 없었으나 앞으로는 pull request 를 하기 전에 코드리뷰 과정을 추가하기로 하였다.

 

브랜치 전략 선택

git을 잘 사용하기 위해서는 브랜치 전략이 먼저 수립되어야 한다. git은 기본적으로 생명주기가 길고 병합까지 시간이 오래 걸리는 브랜치를 싫어한다. 병합 난이도 높아지기 때문이다. 그래서 대부분 브랜치 전략들은 생존주기가 짧은 브랜치들을 사용하도록 해서 개발자들이 더 쉽고 빠르게 일하고, 병합시에 실수를 줄이도록 한다. 가장 대중적은 전략은 git flow 와 github flow 가 있다. 

 

브랜치 전략 선택에 관한 고민은 아래 포스팅에서 다뤘으니 참조 바란다.

 

https://thinkbigtech.tistory.com/2

git 브랜치 전략 선택하기 git-flow vs github-flow vs gitlab-flow

 

히스토리를 마이그레이션 할 지 여부

svn에 남아있는 히스토리를 마이그레이션에 포함할 지 여부도 선택해야 했다.

 

우리 팀의 경우 몇몇 프로젝트의 경우에는 히스토리가 너무 엉망이고 팀 특성상 이미 퇴사한 외주 개발자들의 코드가 많이 묻어 있었기 때문에 히스토리를 같이 마이그레이션 해야 하나 하는 고민이 있었지만 일단 함께 마이그레이션 하기도 했다. 그러나 svn과 git은 브랜치를 관리하는 방식이나 기록 방식이 완전히 다르기 때문에 어느정도 고민이 필요하다. 히스토리와 함께 옮기는 방법은 아래 git-scm 페이지를 참조 바란다.

 

https://git-scm.com/book/ko/v2/Git%EA%B3%BC-%EC%97%AC%ED%83%80-%EB%B2%84%EC%A0%84-%EA%B4%80%EB%A6%AC-%EC%8B%9C%EC%8A%A4%ED%85%9C-Git%EC%9C%BC%EB%A1%9C-%EC%98%AE%EA%B8%B0%EA%B8%B0

Git - Git으로 옮기기

 

svn 유지 여부

마이그레이션 이후 svn 을 유지해야 할 지도 고민이었다. 사실상 필요 없지만 혹시 git에 제대로 마이그레이션 되지 않은 히스토리나 옛날 코드가 궁금할 때를 대비해서 유지하기로 하였다. 하지만 충분히 시간이 흐른 뒤에는 삭제할 계획이다.

 

팀원들의 git 학습

git 을 모르는 팀원들의 경우 어떤 방법으로 학습할지에 대한 고민도 있었다. 처음에는 한, 두시간 정도 학습 스터디를 구성해 볼까 하는 생각도 했었지만 끽해야 git command 몇 개 소개하면 끝날 것 같았고, 그렇다고 git 을 위해 장기적인 스터디를 하는 것도 오바스러운 것 같아서 일단 개인적으로 학습하되 필요한 부분이 있다면 다른 익숙한 팀원들에게 질문하는 식으로 진행했다. 사실 우리 팀이 사용하는 git 수준에서 그리 어려울 것들도 없기 때문에 무리는 없을 듯 싶다.

 

실제 마이그레이션 방법

사실 장황하게 블로그를 작성한 것에 비해 실제 마이그레이션 방법은 별 것이 없다. 일단 아래와 같은 users.txt 파일을 하나 생성한다. 꼭 이 이름이 아니라도 상관은 없다.

 

author1 = author1 <author1@domain.com>
author2 = author2 <author1@domain.com>
author3 = author3 <author1@domain.com>
author4 = author4 <author1@domain.com>

 

위 파일에서 author1~4 는 실제 코드를 커밋했던 개발자들이다. svn log 명령어나 기존에 사용하고 있는 svn ui 도구에서 확인할 수 있는 기능을 제공하고 있다.

 

이후에는 빈 디렉토리에 users.txt 파일을 옮기고 다음 명령어를 연달아 수행한다.

 

git svn clone svn://[svn위치] --authors-file-users.txt --no-metadata
git remote add origin [git위치]
git push origin

 

우리팀의 프로젝트는 워낙 관리가 되어있지 않았기 때문에 --no-metadata 옵션을 통해 메타데이터를 날려 버렸고 태그나 기다 브랜치도 제대로 된 것이 없어서 고려하지 않았다. 아마 대부분 svn 에서 git으로 마이그레이션을 고민하고 있는 팀들은 사정이 비슷할 테니 위와 똑같이 수행하면 별 문제는 없을 것이다.

 

참조

https://docs.microsoft.com/ko-kr/devops/develop/git/centralized-to-git

중앙 집중식 버전 제어에서 Git으로 마이그레이션 - Azure DevOps