SVN -> Git 이관 (하위 디렉토리 구조)

 

svn 에서 git 으로의 전환은 git svn clone 을 이용하면 쉽게 할 수 있다.

 

그런데 보통 대형 프로젝트의 경우 코드베이스를 모듈화하여 관리하거나

단순히 directory 구조를 tree 형태로 구조화 하여 관리하는 경우들이 있고

svn 에서는 단순히 trunk 밑에도 아래와 같이 하위 디렉토리를 두고 관리하는 경우가 있다.

main-prj

- abc (sub module #1)

- def (sub module #2)

. jkl (sub module #2's sub module)

. mno (sub module #2's sub module)

- ghi (sub module #3)

 

이런 경우 git 에서 어떻게 관리해야 할지 적당한 방법을 선택해야 한다.

 

 

Git Submodule

• 하나의 저장소를 다른 저장소의 하위 디렉토리로 포함시키는 방법으로 주로 외부 라이브러리나 공통 코드가 있는 경우에 사용한다.
• 장점
  • submodule은 메인 프로젝트와 독립적으로 커밋, 업데이트, 체크아웃 가능하다.
  • 특정 시점의 커밋을 지정하여 고정시킬 수 있어 외부 라이브러리의 특정 버전을 유지하고자 할 때 유용하다.
• 단점
  • submodule 을 초기화하고 업데이트 하는 과정이 복잡하며 관리하는데 어려움이 있다.
  • submodule 의 내용을 메인 저장소의 커밋에 직접 포함시키지 않으므로, 메인 프로젝트와 함께 자동으로 클론되지 않는다.

 

 

Git Subtree

• 다른 프로젝트의 저장소를 하위 디렉토리로 통합하되, 해당 코드의 history도 함께 통합할 수 있다. submodule 보다 관리가 간단하며, 외부 저장소의 변화를 추적하기도 쉽다.
• 장점
  • 메인 프로젝트에 직접 코드를 포함시키므로 별도의 초기화 작업 없이 클론할 때 외부 코드도 함께 클론된다.
  • 외부 저장소의 변경 사항을 가져오거나 변경 사항을 외부 저장소에 푸시하는 것이 비교적 간단하다.
• 단점
  • 외부 코드의 전체 history 가 메인 프로젝트에 통합되기 때문에 저장소의 크기가 커질 수 있다.
  • 때로 외부 저장소의 history 가 메은 프로젝트의 history와 섞여 복잡해질 수 있다.

 

 

New Directory

• 새 디렉토리를 만들어 별도의 프로젝트로 관리하는 방식은 각각의 프로젝트를 완전히 독립적으로 관리하되, 같은 위치에 저장하는 방식으로 기존의 svn 과 유사하다.
• 장점
  • 각 프로젝트가 완전히 독립적으로 관리되므로 각자의 라이프 사이클, 의존성, 버전 관리 시스템을 가질 수 있다.
  • 구조가 간단해 진다.

 

기존의 svn 구조를 그대로 가져오면서 별도의 독립적인 프로젝트로 관리하고자 New Direcoty 방법으로 관리하기로 결정.

 

 

 

gitlab 에서 main-prj 밑에 필요한 sub project 들에 대하여 New Directory 를 생성한다.

 

 

PC 에서 git 을 설치하고

Git global setup (git branch 또는 cmd 로 진행) 를 진행해 준다.

git config --global user.name "김영회"
git config --global user.email "yhkim@....."

 

 

main-prj 를 clone 하여 가져온다.

git clone https://git......./main-prj.git
cd main-prj
git switch --create master
touch README.md
git add README.md
git commit -m "add README"
git push --set-upstream origin master

 

 

main-prj 하위에 New Directory 로 생성한 sub project 를 pull 로 가져온다.

 

 

svn 을 git 으로 이관하기 위해서는 git svn clone 을 이용하는데

이때 git 과 svn 이 모두 설치되어 있어야 하며

특히 svn 의 경우 설치 시 command line client tools 가 체크되어 있어야 한다.

만약 위 옵션을 활성화 하지 않을 경우 아래와 같은 오류가 발생 할 수 있다.

 

svn 의 commit history 를 모두 이관하기 위해서는 svn history 에 있는 사용자들의 정보를 git svn clone 할때 사용해야 하기 때문에 authors.txt 라는 파일로 만들어 준다.

yhkim = yhkim <yhkim@mail-domain.com>

 

위와 같은 형태로 만들면 되고 여러명인 경우 줄바꿈을 통해 여러개 입력해 두면 된다.

 

이제 git svn clone 을 수행한다.

위와 같이 svn source code 와 history 들이 git 으로 변환처리 된다.

이후 svn 과의 연결을 끊어준다.

java -Dfile.encoding=utf-8 -jar svn-migration-scripts.jar clean-git --force 

 

svn-migration-script.jar 는 https://www.atlassian.com/git/tutorials/migrating-prepare  에서 다운로드

git svn clone 하게 되면 해당 디렉토리는 다시 독립적인 git 저장소로 초기화 되기 때문에

이렇게 생성된 저장소는 상위 디렉토리의 '.git' 설정을 상속받지 않게 된다.

 

상위 디렉토리로 이동후에 본 디렉토리를 add, commit, push 하면 된다.

cd ../
git add abc/
git commit -m "Integrate full svn history"
git push origin master

 

이렇게 모든 하위 sub project 들을 반복 한다.

 

 

이후 intellij 로 해당 sub project 를 열어 git 을 보면

remote 에 git-svn 이라는 branch 가 보이게 된다. 이 branch 로 rebase 해서 사용하면 된다.

​

git-svn branch?

git-svn branch 가 보이는 현상은 `git-svn` 도구를 사용하여 svn 저장소를 git 저장소로 변환할 때 일반적으로 발생하며 intellij 에서만 보이는 것은 IDE 에서 `.git/config` 파일을 참조하여 표시하기 때문이다.

​

.git/conf 파일을 열어 svn 관련 섹션을 모두 삭제 한다.

 [svn-remote "svn"]

   url = http://your_svn_repo_here

   fetch = :refs/remotes/git-svn

.git/svn 디렉토리를 삭제 한다.

  rm -rf .git/svn

git-svn 브랜치를 삭제 한다.

  git branch -d -r git-svn

 

이후 다시 intellij 를 확인하면 remote 에 git-svn 이 사라지게 된다.

만약 원격 저장소 (ex. gitlab) 에 git-svn 브랜치가 보인다면 아래와 같이 하면 된다.

  git push origin --delete git-svn