SVN에서 Git까지, 마이그레이션 준비

Atlassian 마이그레이션 스크립트

갑작스럽게 Git로 전환하는 데 관심이 있다면 Atlassian의 마이그레이션 스크립트를 선택하는 것이 좋습니다. 이 스크립트는 기존 SVN 리포지토리를 Git 리포지토리로 안정적으로 변환하는 데 필요한 모든 도구를 제공합니다. 따라서 네이티브 Git 기록은 변환 프로세스 후에 SVN과 Git의 상호 운용성 문제를 해결할 필요가 없도록 해줍니다.

Atlassian에서는 이러한 스크립트를 사용하여 전체 코드베이스를 Git 리포지토리 컬렉션으로 변환하는 데 필요한 완전한 기술 안내를 제공했습니다. 이 안내에서는 SVN 작성자 정보 추출에서 비표준 SVN 리포지토리 구조 재구성에 이르기까지 모든 것을 설명합니다.

SVN Mirror for Stash(현재 Bitbucket) 플러그인

SVN Mirror for StashSVN Mirror for Stash는 Bitbucket 플러그인으로 SVN과 Git 모두에서 작동하는 하이브리드 코드베이스를 쉽게 유지할 수 있도록 합니다. Atlassian의 마이그레이션 스크립트와 달리 SVN Mirror for Stash를 사용하면 원하는 기간 동안 같은 프로젝트에서 Git과 SVN을 동시에 사용할 수 있습니다.

이 절충안 솔루션은 대기업을 위한 훌륭한 옵션입니다. 여러 팀이 편리한 시간에 워크플로를 마이그레이션할 수 있게 해주므로 Git을 점진적으로 채택할 수 있습니다.

Git-SVN이란?

git-svn 도구는 로컬 Git 리포지토리와 원격 SVN 리포지토리 사이의 인터페이스입니다. Git-SVN을 사용하면 개발자가 Git으로 로컬에서 코드를 작성하고 커밋을 만든 다음, svn 커밋 방식의 동작으로 중앙 SVN 리포지토리에 푸시할 수 있습니다. 이것은 일시적이지만 SVN에서 Git으로의 전환을 논의할 때 유용합니다.

Git으로 전환하는 것에 대해 확신이 서지 않고 일부 개발자가 전체 마이그레이션을 수행하지 않고도 Git 명령을 탐색할 수 있도록 하려면 git svn을 사용하는 것이 좋습니다. 또한 교육 단계에도 적합합니다. 갑작스러운 전환 대신 팀이 공동 작업 워크플로에 대해 걱정하기 전에 로컬 Git 명령을 사용하여 쉽게 전환할 수 있습니다.

참고로 git svn은 마이그레이션 프로세스의 일시적인 단계여야 합니다. “백엔드”를 위해 여전히 SVN에 의존하기 때문에 브랜칭 또는 고급 공동 작업 워크플로와 같은 더 강력한 Git 기능을 활용할 수 없습니다.

롤아웃 전략

코드베이스 마이그레이션은 Git 채택의 한 측면일 뿐입니다. 코드베이스 이면에 있는 이해 관계자에게 Git을 소개하는 방법도 고려해야 합니다. 개발 팀을 Git으로 마이그레이션하기 위한 세 가지 주요 전략은 외부 컨설턴트, 내부 Git 챔피언 및 파일럿 팀입니다.

외부 Git 컨설턴트

기본적으로 Git 컨설턴트는 소액의 비용으로 마이그레이션 프로세스를 처리해 줍니다. 이렇게 하면 스스로 파악하기 위해 시간을 투자하지 않고도 팀에 완벽하게 적합한 Git 워크플로를 만들 수 있다는 장점이 있습니다. 또한 팀이 Git을 배우는 동안 전문 교육 리소스를 활용할 수도 있습니다. Atlassian 파트너는 SVN에서 Git으로 마이그레이션하는 데 있어 전문가이며, Git 컨설턴트를 찾기 위한 유용한 리소스입니다.

반면에 Git 워크플로를 직접 설계하고 구현하는 것은 팀이 새로운 개발 프로세스의 내부 작업 방식을 이해하는 좋은 방법입니다. 컨설턴트가 떠날 때 팀이 아무것도 모르는 상황에 놓이는 위험을 방지할 수 있습니다.

내부 Git 챔피언

Git 챔피언은 Git 사용을 시작하게 되어 기대가 가득한 회사 내 개발자입니다. 탄탄한 개발자 문화와 얼리 어답터가 되기를 좋아하는 열정적인 프로그래머가 있는 회사라면 Git 챔피언을 활용하는 것이 좋습니다. 이 아이디어는 엔지니어 중 한 명이 Git 전문가가 되어 회사에 맞춤화된 Git 워크플로를 설계하고 나머지 팀을 Git으로 전환할 때 내부 컨설턴트 역할을 할 수 있도록 하는 것입니다.

외부 컨설턴트와 비교하면 Git 전문 지식을 사내에서 유지할 수 있다는 장점이 있습니다. 그러나 Git 챔피언을 교육하려면 더 많은 시간을 투자해야 하고, 잘못된 Git 워크플로를 선택하거나 잘못 구현할 위험이 있습니다.

파일럿 팀

Git으로 전환하기 위한 세 번째 옵션은 파일럿 팀에서 테스트하는 것입니다. 이 옵션은 상대적으로 분리된 프로젝트를 진행하는 소규모 팀이 있는 경우 가장 효과적입니다. 외부 컨설턴트와 파일럿 팀의 내부 Git 챔피언을 결합한 완벽한 전략을 구사하면 훨씬 더 효과적일 수 있습니다.

이렇게 하면 팀 전체의 승인을 요구한다는 장점이 있으며, 새로운 개발 프로세스를 설계하는 동안 전체 팀의 의견을 받기 때문에 잘못된 워크플로를 선택할 위험도 줄어듭니다. 즉, 컨설턴트나 챔피언이 스스로 새 워크플로를 설계할 때보다 누락된 부분을 더 빨리 찾아낼 수 있습니다.

반면에 파일럿 팀을 사용하면 초기 교육 및 준비 시간이 더 필요합니다. 한 개발자가 새 워크플로를 파악하는 대신 팀 전체가 새로운 워크플로에 익숙해져야 하므로 일시적으로 생산성이 떨어질 수 있습니다. 하지만 장기적인 이점을 고려하면 이러한 단기적인 문제는 감수할 가치가 있습니다.

보안 및 권한

액세스 제어는 코드베이스를 관리하는 방법을 근본적으로 재고해야 하는 Git의 한 측면입니다.

SVN에서는 보통 전체 코드베이스를 하나의 중앙 리포지토리에 저장한 다음 폴더별로 다른 팀이나 개인에 대한 액세스를 제한합니다. 하지만 Git에서는 불가능합니다. 개발자가 리포지토리로 작업하려면 리포지토리 전체를 가져와야 합니다. SVN에서와 같이 리포지토리의 일부만 가져올 수 없습니다. 권한은 전체 Git 리포지토리에만 부여할 수 있습니다.

즉, 대규모 모놀리식 SVN 리포지토리를 여러 개의 작은 Git 리포지토리로 분할해야 한다는 뜻입니다. Jira 개발 팀이 Git으로 마이그레이션했을 때 Atlassian에서 실제로 이러한 상황을 직접 경험했습니다. 모든 Jira 플러그인은 단일 SVN 리포지토리에 저장되어 있었는데 마이그레이션 후에는 각 플러그인이 자체 리포지토리에 저장되었습니다.

Git은 수천 명의 독립적인 Linux 개발자의 코드 기여를 안전하게 통합하도록 설계되었으므로 팀에 필요한 액세스 제어를 설정할 수 있는 방법을 제공합니다. 그러나 이를 위해서는 빌드 주기를 새로 검토해야 할 수 있습니다.

새 Git 리포지토리 컬렉션 간의 종속성을 유지하는 것이 걱정된다면 Git뿐만 아니라 종속성 관리 계층이 유용할 수 있습니다. 프로젝트가 성장함에 따라 빌드 시간을 단축하기 위해 “캐싱”이 필요하기 때문에 종속성 관리 계층은 빌드 시간에 도움이 될 수 있습니다. 모든 기술 스택에 권장되는 종속성 관리 계층 도구 목록은 유용한 문서인 "Git 및 프로젝트 종속성"에서 확인할 수 있습니다.

모든 개발자를 위한 리포지토리

개발자로서 적응해야 할 가장 큰 변화는 Git의 분산 특성입니다. 모든 개발자는 단일 중앙 리포지토리 대신 전체 리포지토리의 자체 복사본을 가집니다. 따라서 동료 프로그래머들과 공동 작업하는 방식이 크게 달라집니다.

svn checkout으로 SVN 리포지토리를 체크아웃하고 작업 복사본을 얻는 대신 git clone을 사용하여 전체 Git 리포지토리를 로컬 컴퓨터에 복제합니다.

공동 작업은 git push, git fetch 또는 git pull을 사용하여 리포지토리 간에 브랜치를 이동하면서 이루어집니다. 공유는 보통 Git의 브랜치 수준에서 이루어지지만 SVN과 비슷하게 커밋 수준에서도 가능합니다. 그러나 Git에서 커밋은 파일 수정이 아니라 프로젝트의 전체 상태를 나타냅니다. Git과 SVN 모두에서 브랜치를 사용할 수 있기 때문에 여기서 중요한 차이점은 Git에서 작업을 공유하지 않고도 로컬에서 커밋할 수 있다는 것입니다. 이를 통해 보다 자유롭게 실험하고, 오프라인에서 더 효율적으로 작업하며, 버전 제어와 관련된 거의 모든 명령의 속도를 높일 수 있습니다.

그러나 원격 리포지토리는 다른 사용자의 리포지토리로 직접 연결되는 링크가 아니라는 점을 이해하는 것이 중요합니다. 원격 리포지토리와 상호 작용할 때마다 전체 URL을 다시 입력할 필요가 없도록 하는 책갈피일 뿐입니다. 브랜치를 원격 리포지토리로 명시적으로 풀 또는 푸시하기 전까지는 분리된 환경에서 작업하게 됩니다.

SVN 사용자가 적응해야 하는 또 다른 큰 변화는 “로컬”과 “원격” 리포지토리라는 개념입니다. 로컬 리포지토리는 로컬 컴퓨터에 있으며 다른 나머지 리포지토리는 모두 원격 리포지토리라고 합니다. 원격 리포지토리의 주요 목적은 나머지 팀원도 사용자의 코드에 액세스할 수 있도록 하는 것이므로 그 안에서 활성 개발은 이루어지지 않습니다. 로컬 리포지토리는 로컬 컴퓨터에 있으며 모든 소프트웨어 개발을 수행하는 곳입니다.

브랜칭 또는 병합 두려워하지 않기

SVN에서는 작업 복사본에서 파일을 편집하여 코드를 커밋한 다음 svn commit 명령을 실행하여 중앙 리포지토리로 코드를 보냅니다. 그러면 다른 모든 사용자가 svn update를 사용하여 변경 사항을 자신의 작업 복사본으로 가져올 수 있습니다. SVN 브랜치는 보통 장기적으로 실행되는 대규모 프로젝트에 사용합니다. 병합은 프로젝트를 중단시킬 가능성이 있는 위험한 절차이기 때문입니다.

Git의 기본 개발 워크플로는 많이 다릅니다. 하나의 개발 라인(예: trunk/)에 얽매이지 않고 브랜칭 및 병합을 중심으로 돌아갑니다.

Git에서 작업을 시작하려면 git checkout -b를 사용하여 새 브랜치를 만들고 체크아웃합니다. 이렇게 하면 다른 팀원에게 영향을 미칠 염려 없이 코드를 작성할 수 있는 전용 개발 라인이 생깁니다. 복구할 수 없을 정도로 망치더라도 git branch -d를 사용하여 브랜치를 버리면 됩니다. 유용한 기능을 만들면 메인 브랜치에 병합하도록 요청하는 풀리퀘스트를 제출합니다.

잠재적인 Git 워크플로

Git 워크플로를 선택할 때는 팀의 요구 사항을 고려해야 합니다. 단순한 워크플로는 개발 속도와 유연성을 최대화할 수 있는 반면, 복잡한 워크플로는 진행 중인 작업의 일관성과 제어를 향상할 수 있습니다. 아래 나열된 일반적인 접근 방식을 사용자의 요구 사항과 팀의 다양한 역할에 맞게 조정하고 결합할 수 있습니다. 예를 들어 계약업체가 포크에서 작업하는 동안 핵심 개발자는 기능 브랜치를 사용할 수 있습니다.

• 중앙 집중식 워크플로는 일반적인 SVN 프로세스와 가장 비슷한 기능을 제공하므로 시작하기에 좋은 옵션입니다.
• 이러한 아이디어를 바탕으로 기능 브랜치 워크플로를 사용하면 개발자는 진행 중인 작업을 분리하고 중요한 공유 브랜치를 보호할 수 있습니다. 기능 브랜치도 풀리퀘스트를 통해 변경 사항을 관리하기 위한 기반을 형성합니다.
• Gitflow 워크플로는 기능 브랜칭에 대한 보다 형식적이고 구조화된 확장 기능으로, 릴리스 주기가 잘 정의된 대규모 팀에 적합한 옵션입니다.
• 마지막으로 변경 사항을 최대한 분리하고 제어해야 하거나 여러 개발자가 하나의 리포지토리에 기여해야 하는 경우 포킹 워크플로를 고려하세요.

하지만 전문가 팀으로서 Git을 최대한 활용하고 싶다면 기능 브랜치 워크플로를 고려하는 것이 좋습니다. 기능 브랜치 워크플로는 진정한 분산형 워크플로로 매우 안전하고, 확장성이 뛰어나며, 근본적으로 애자일합니다.

팀을 Git으로 전환하는 것은 벅찬 작업일 수 있지만 반드시 그럴 필요는 없습니다. 이 문서에서는 기존 코드베이스를 마이그레이션하고, 개발 팀에 Git을 배포하며, 보안 및 권한을 관리하는 몇 가지 일반적인 옵션을 알아보았습니다. 또한 마이그레이션 프로세스 중에 개발자가 대비해야 할 가장 큰 문제에 대해서도 살펴봤습니다.

이제 회사의 규모나 현재의 개발 관행에 관계없이 분산형 개발을 도입할 수 있는 탄탄한 기반이 마련되었기를 바랍니다.