SVN에서 Git까지, 마이그레이션 준비
Git을 사용하는 이유에서 Git이 팀을 더욱 애자일하게 만드는 데 도움이 되는 여러 가지 방법을 살펴봤습니다. 전환하기로 결정했으면 다음 단계는 기존 개발 워크플로를 Git으로 마이그레이션하는 방법을 파악하는 것입니다.
이 문서에서는 팀을 SVN에서 Git으로 전환하는 동안 겪게 되는 가장 큰 변화에 대해 설명합니다. 마이그레이션 과정에서 기억해야 할 가장 중요한 점은 바로 Git은 SVN이 아니라는 것입니다. Git의 잠재력을 최대한 활용하려면 버전 제어에 대한 새로운 사고 방식을 수용해야 합니다.
관리자용
Git을 채택하는 것은 팀 규모에 따라 며칠에서 몇 개월까지 걸릴 수 있습니다. 이 섹션에서는 직원에게 Git을 교육하고 SVN에서 Git으로 리포지토리를 마이그레이션할 때 엔지니어링 관리자가 고려해야 하는 몇 가지 주요 문제를 다룹니다.
기본 Git 명령
Git은 한때 가파른 학습 곡선으로 알려져 있었습니다. 하지만 Git 관리자들은 적합한 기본값 및 상황별 도움말 메시지와 같은 새로운 개선 사항을 꾸준히 릴리스하여 온보딩 프로세스를 훨씬 더 즐겁게 만들었습니다.
Atlassian에서는 자기 주도 방식 Git 자습서의 포괄적인 시리즈와 웹 세미나 및 실시간 교육 세션을 제공합니다. 이 모든 것은 팀이 Git을 시작하는 데 필요한 모든 교육 옵션을 제공합니다. 여러분이 Git을 시작하는 데 도움이 되는 몇 가지 기본 Git 명령은 다음과 같습니다.
관련 자료
전체 Git 리포지토리를 이동하는 방법
솔루션 보기
Bitbucket Cloud에서 Git에 대해 알아보기
Git 작업 | 참고 | Git 명령 |
|---|---|---|
| 참고 커밋에 사용할 작성자 이름 및 이메일 주소를 구성합니다. 참고로 Git은 user.name에서 일부 문자(예: 후행 마침표)를 제거합니다. | Git 명령 git config --global user.name "Sam Smith"git config --global user.email sam@example.com | |
| Notes
| Git 명령 git init | |
| 참고 로컬 리포지토리의 작업 복사본 만들기: | Git 명령 git clone /path/to/repository | |
|
| 참고 원격 서버의 경우, 다음을 사용: | Git 명령 git clone username@host:/path/to/repository |
| 참고 스테이징에 하나 이상의 파일 추가(색인): | Git 명령 git add * | |
| 참고 헤드에 변경 사항 커밋(하지만 원격 리포지토리에는 아직 커밋하지 않음): | Git 명령 git commit -m "Commit message" | |
|
| 참고 git add로 추가한 모든 파일을 커밋하고 그 이후로 변경한 파일도 커밋: | Git 명령 git commit -a |
| 참고 원격 리포지토리의 메인 브랜치로 변경 사항 보내기: | Git 명령 git push origin main | |
| 참고 변경한 파일 및 아직 추가하거나 커밋해야 하는 파일 나열: | Git 명령 git status | |
| 참고 로컬 리포지토리를 원격 서버에 연결하지 않은 경우 푸시할 수 있는 서버 추가: | Git 명령 git remote add origin | |
|
| 참고 현재 구성된 원격 리포지토리 모두 나열: | Git 명령 git remote -v |
| 참고 새 브랜치를 만들어 전환: | Git 명령 git checkout -b | |
|
| 참고 한 브랜치에서 다른 브랜치로 전환: | Git 명령 Git 체크아웃 |
|
| 참고 리포지토리의 모든 브랜치를 나열하고 현재 어떤 브랜치에 있는지 알림: | Git 명령 git branch |
|
| 참고 기능 브랜치 삭제: | Git 명령 git branch -d |
|
| 참고 다른 사용자가 사용할 수 있도록 브랜치를 원격 리포지토리로 푸시: | Git 명령 git push origin |
|
| 참고 모든 브랜치를 원격 리포지토리로 푸시: | Git 명령 git push --all origin |
|
| 참고 원격 리포지토리에서 브랜치 삭제: | Git 명령 git push origin : |
| 참고 원격 서버의 변경 사항을 작업 디렉터리로 가져와 병합: | Git 명령 git pull | |
|
| 참고 다른 브랜치를 활성 브랜치에 병합: | Git 명령 Git 병합 |
|
| 참고 병합 충돌 모두 보기:기본 파일과의 충돌 보기:병합하기 전 변경 사항 미리 보기: | Git 명령 git diffgit diff --basegit diff |
|
| 참고 수동으로 충돌을 해결한 후 변경된 파일을 표시: | Git 명령 git add |
| 태그 | 참고 태그를 사용하여 릴리스와 같은 중요한 변경 집합을 표시: | Git 명령 git tag 1.0.0 |
|
| 참고 커밋 ID는 변경 집합 ID의 선행 문자로 최대 10자이며 고유해야 합니다. 다음을 사용하여 ID 얻기: | Git 명령 git log |
|
| 참고 모든 태그를 원격 리포지토리로 푸시: | Git 명령 git push --tags origin |
| 참고 실수하는 경우 작업 트리의 변경 사항을 헤드의 마지막 콘텐츠로 바꿀 수 있습니다. 새 파일뿐만 아니라 색인에 이미 추가된 변경 사항도 그대로 유지됩니다. | Git 명령 git checkout -- | |
|
| 참고 대신 로컬 변경 사항과 커밋을 모두 삭제하고 서버에서 최신 기록을 가져와 로컬 메인 브랜치를 가리키도록 하려면 다음을 수행합니다. | Git 명령 git fetch origingit reset --hard origin/main |
| 검색 | 참고 작업 디렉터리에서 foo() 검색: | Git 명령 git grep "foo()" |
Git 마이그레이션 도구
기존 프로젝트를 SVN에서 Git으로 마이그레이션하는 데 도움이 되는 여러 도구가 있지만 어떤 도구를 사용할지 결정하기 전에 코드를 마이그레이션하는 방법을 파악해야 합니다. 옵션은 다음과 같습니다.
- 전체 코드베이스를 Git으로 마이그레이션하고 SVN 사용을 완전히 중지합니다.
- 기존 프로젝트를 Git으로 마이그레이션하지 않고 모든 새 프로젝트에 Git을 사용합니다.
- 일부 프로젝트를 Git으로 마이그레이션하고 나머지 프로젝트에서는 SVN을 계속 사용합니다.
- 같은 프로젝트에서 SVN과 Git을 동시에 사용합니다.
Git으로 완전히 전환하면 개발 워크플로의 복잡성이 제한되므로 이 옵션을 사용하는 것이 좋습니다. 하지만 수십 개의 개발 팀을 비롯해 프로젝트가 수백 개일 수도 있는 대기업에서는 항상 가능한 옵션이 아닙니다. 이 상황에서는 하이브리드 접근 방식이 더 안전한 옵션입니다.
마이그레이션 도구 선택은 위의 전략 중 어떤 전략을 선택하는지에 따라 크게 달라집니다. 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을 배포하며, 보안 및 권한을 관리하는 몇 가지 일반적인 옵션을 알아보았습니다. 또한 마이그레이션 프로세스 중에 개발자가 대비해야 할 가장 큰 문제에 대해서도 살펴봤습니다.
이제 회사의 규모나 현재의 개발 관행에 관계없이 분산형 개발을 도입할 수 있는 탄탄한 기반이 마련되었기를 바랍니다.
이 문서 공유
다음 토픽
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
Bitbucket 블로그
DevOps 학습 경로
