다음을 통해 공유

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

  • 아티클

중앙 집중식 버전 제어에서 Git으로 팀을 마이그레이션하려면 새 명령을 학습하는 것 이상이 필요합니다. 분산 개발을 지원하기 위해 Git은 파일 기록 및 분기 정보를 중앙 집중식 버전 제어 시스템과 다르게 저장합니다. 중앙 집중식 버전 제어 시스템에서 Git으로의 성공적인 마이그레이션을 계획하고 구현하려면 이러한 기본적인 차이점을 이해해야 합니다.

Microsoft는 중앙 집중식 버전 제어 시스템에서 Git으로 많은 내부 팀과 고객을 마이그레이션하는 데 도움을 주었습니다. 이 환경은 지속적으로 성공하는 사례를 기반으로 다음 지침을 생성했습니다.

성공적인 마이그레이션 단계

성공적인 마이그레이션을 위해 팀은 다음을 수행해야 합니다.

  • 현재 도구 및 프로세스를 평가합니다.
  • Git 분기 전략을 선택합니다.
  • 기록을 마이그레이션할지 여부와 방법을 결정합니다.
  • 이전 버전 제어 시스템을 유지 관리합니다.
  • 소스 제어에서 이진 파일, 실행 파일 및 도구를 제거합니다.
  • Git 개념 및 사례에서 팀을 학습시킵니다.
  • Git으로 마이그레이션을 테스트합니다.

현재 도구 및 프로세스 평가

버전 제어 시스템을 변경하면 새 도구 및 사례를 사용하여 개발 워크플로가 자연스럽게 중단됩니다. 이러한 중단은 DevOps 프로세스의 다른 측면을 개선할 수 있는 기회가 될 수 있습니다.

팀은 새 시스템으로 마이그레이션할 때 다음 사례를 채택하는 것을 고려해야 합니다.

Git 분기 전략 선택

코드를 마이그레이션하기 전에 팀은 분기 전략을 선택해야 합니다.

Git에서 단기 토픽 분기를 사용하면 개발자가 기본 분기 가까이에서 작업하고 신속하게 통합하여 병합 문제를 방지할 수 있습니다. 두 가지 일반적인 토픽 분기 전략은 GitFlow 와 더 간단한 변형인 GitHub Flow입니다.

Git은 통합이 어려워질 때까지 병합을 지연하는 경향이 있는 수명이 긴 격리된 기능 분기 권장하지 않습니다. 팀은 기능 플래그와 같은 최신 CD 기술을 사용하여 코드를 기본 분기에 신속하게 통합할 수 있지만 완료될 때까지 진행 중인 기능을 사용자에게 숨겨 둘 수 있습니다.

현재 수명이 긴 기능 분기 전략을 사용하는 팀은 Git으로 마이그레이션하기 전에 기능 플래그를 채택할 수 있습니다. 기능 플래그를 사용하면 마이그레이션할 분기 수를 최소화하여 마이그레이션을 간소화할 수 있습니다. 기능 분기 또는 기능 플래그를 사용하든 팀은 레거시 분기와 새 Git 분기 간의 매핑을 문서화해야 하므로 모든 사람이 새 작업을 커밋할 위치를 이해해야 합니다.

기록을 마이그레이션할지 여부를 결정합니다.

팀은 기존 소스 코드 기록을 Git으로 마이그레이션하려고 할 수 있습니다. 여러 도구는 중앙 집중식 도구에서 Git으로 모든 분기의 전체 기록을 마이그레이션해야 합니다. Git 커밋은 이전 버전 제어 도구에서 사용한 변경 집합 또는 검사 모델에 상대적으로 잘 매핑되는 것처럼 보입니다.

그러나 이 매핑에는 몇 가지 심각한 제한 사항이 있습니다.

  • 대부분의 중앙 집중식 버전 제어 시스템에서 분기는 리포지토리에 폴더로 존재합니다. 예를 들어 기본 분기는 /트렁크라는 폴더일 수 있으며 다른 분기는 /branch/one 및 /branch/2와 같은 폴더입니다. Git 리포지토리에서 분기는 전체 리포지토리를 포함하므로 1:1 번역이 어렵습니다.

  • 일부 버전 제어 시스템에서 태그 또는 레이블 은 트리의 다양한 파일, 심지어 다른 버전의 파일을 포함할 수 있는 컬렉션입니다. Git에서 태그는 특정 시점에 전체 리포지토리의 스냅샷. 태그는 리포지토리의 하위 집합을 나타내거나 다른 버전의 파일을 결합할 수 없습니다.

  • 대부분의 버전 제어 시스템은 이름 바꾸기, 삭제 취소 및 롤백과 같은 세분화된 변경 형식을 포함하여 버전 간에 파일이 변경되는 방식에 대한 세부 정보를 저장합니다. Git은 버전을 전체 리포지토리의 스냅샷 저장하고 파일 변경 방식에 대한 메타데이터를 사용할 수 없습니다.

이러한 차이는 전체 기록 마이그레이션이 기껏해야 손실되고 오해의 소지가 있음을 의미합니다. 손실, 관련 노력 및 사용 기록의 상대적 희귀성을 감안할 때 대부분의 팀은 기록을 가져오지 않는 것이 좋습니다. 대신 팀은 팁 마이그레이션을 수행해야 하며, 최신 분기 버전의 스냅샷 Git으로만 가져와야 합니다. 대부분의 팀의 경우 프로세스 개선과 같이 투자 수익률이 높은 마이그레이션 영역에서 시간을 가장 잘 소비합니다.

이전 버전 제어 시스템 유지 관리

마이그레이션 중 및 마이그레이션 후에도 개발자는 여전히 이전 버전 제어 기록에 액세스해야 할 수 있습니다. 이전 버전 제어 기록은 시간이 지남에 따라 관련성이 낮아지지만 참조할 수 있어야 합니다. 규제가 높은 환경에는 버전 제어 기록에 대한 특정 법률 및 감사 요구 사항이 있을 수 있습니다.

특히 팁 마이그레이션만 수행하는 팀의 경우 이전 시스템을 무기한으로 기본 것이 좋습니다. 마이그레이션한 후 이전 버전 제어 시스템을 읽기 전용으로 설정합니다.

대규모 개발 팀과 규제된 환경은 이전 버전 제어 시스템을 가리키는 이동 경로를 Git에 배치할 수 있습니다. 간단한 예는 팁 마이그레이션 전에 Git 리포지토리의 루트에서 이전 버전 제어 서버의 URL을 가리키는 첫 번째 커밋으로 추가된 텍스트 파일입니다. 여러 분기가 마이그레이션되는 경우 각 분기의 텍스트 파일은 분기가 이전 시스템에서 마이그레이션되는 방법을 설명해야 합니다. 이동 경로는 마이그레이션된 후 프로젝트 작업을 시작하고 이전 버전 제어 시스템에 익숙하지 않은 개발자에게도 유용합니다.

이진 파일 및 도구 제거

Git의 스토리지 모델은 압축 가능하고 압축성이 뛰어난 텍스트 파일 및 소스 코드의 버전 관리에 최적화되어 있습니다. 이진 파일은 일반적으로 크며 리포지토리에 추가되면 리포지토리 기록 및 이후의 모든 클론에서 다시 기본. Git에서 기록을 저장하는 방식 때문에 개발자는 리포지토리, 특히 매우 크거나 자주 변경되는 이진 파일에 이진 파일을 추가하지 않아야 합니다. Git으로 마이그레이션하면 코드베이스에서 이러한 이진 파일을 제거할 수 있습니다.

또한 리포지토리에서 라이브러리, 도구 및 빌드 출력을 제외하는 것이 좋습니다. 대신 NuGet과 같은 패키지 관리 시스템을 사용하여 종속성을 관리합니다.

아이콘 및 아트워크와 같은 자산은 특정 버전의 소스 코드와 일치해야 할 수 있습니다. 아이콘과 같이 자주 변경되지 않는 작은 자산은 기록이 부풀어 오르지 않으며 리포지토리에 직접 포함할 수 있습니다. 대용량 또는 자주 변경되는 자산을 저장하려면 Git LFS(큰 파일 스토리지) 확장을 사용합니다. GitHub에서 대용량 파일을 관리하는 방법에 대한 자세한 내용은 대용량 파일 관리를 참조하세요. Azure Repos의 경우 Git에 대용량 파일 관리 및 저장을 참조하세요.

교육 제공

Git으로 마이그레이션할 때 가장 큰 과제 중 하나는 개발자가 Git에서 변경 내용을 저장하는 방법과 커밋이 개발 기록을 형성하는 방법을 이해하는 데 도움이 되는 것입니다. 이전 명령을 Git 명령에 매핑하는 치트 시트를 준비하는 것만으로는 충분하지 않습니다. 개발자는 중앙 집중식 선형 모델 측면에서 버전 제어 기록에 대해 생각하지 말고 Git의 기록 모델 및 커밋 그래프를 이해해야 합니다.

사람 다양한 방법으로 학습하므로 여러 가지 유형의 교육 자료를 제공해야 합니다. 전문가 강사를 사용한 라이브 랩 기반 교육은 어떤 사람들에게는 잘 작동합니다. Pro Git 책은 온라인에서 무료로 제공되는 훌륭한 출발점입니다.

사용 가능한 무료 실습 교육 과정은 다음과 같습니다.

조직은 팀의 Git 전문가를 식별하고, 다른 사용자를 도울 수 있도록 권한을 부여하고, 다른 팀 구성원에게 질문을 하도록 장려해야 합니다.

마이그레이션 테스트

팀이 프로세스를 업데이트하고, 코드를 분석하고, 멤버를 학습하면 소스 코드를 마이그레이션해야 합니다. 팁 마이그레이션을 수행하든, 기록을 마이그레이션하든 테스트 리포지토리로 하나 이상의 테스트 마이그레이션을 수행하는 것이 중요합니다. 최종 마이그레이션을 수행하려면 다음을 확인합니다.

  • 모든 코드 파일이 마이그레이션합니다.
  • 모든 분기를 사용할 수 있습니다.
  • 리포지토리에 길 잃은 이진 파일이 없습니다.
  • 사용자에게는 페치 및 푸시에 대한 적절한 권한이 있습니다.
  • 빌드가 성공하고 모든 테스트가 통과합니다.

코드 마이그레이션

작업 외 시간에 최종 마이그레이션을 수행합니다. 이상적으로는 자연스러운 가동 중지 시간이 있을 때 중요 시점 간에 수행합니다. 스프린트가 끝날 때 마이그레이션하면 개발자가 작업을 완료하는 동안 문제가 발생할 수 있습니다. 아무도 검사 필요가 없는 주말에 마이그레이션해 보세요.

이전 버전 제어 시스템에서 Git으로의 굳은 컷오버를 계획합니다. 여러 시스템을 병렬로 운영하려고 하면 개발자가 검사 위치 또는 방법을 모를 수 있습니다. 혼동을 방지하려면 이전 버전 제어 시스템을 읽기 전용으로 설정합니다. 이 보호 기능이 없으면 임시 변경을 포함하는 두 번째 마이그레이션이 필요할 수 있습니다.

실제 마이그레이션 프로세스는 마이그레이션하는 시스템에 따라 달라집니다. Team Foundation 버전 제어 마이그레이션하는 방법에 대한 자세한 내용은 TFVC에서 Git으로 마이그레이션을 참조하세요.

마이그레이션 검사 목록

팀 워크플로:

  • 빌드를 실행하는 방법을 결정합니다.
  • 테스트 실행 시기를 결정합니다.
  • 릴리스 관리 프로세스를 개발합니다.
  • 끌어오기 요청으로 코드 검토를 이동합니다.

분기 전략:

  • Git 분기 전략을 선택합니다.
  • 분기 전략, 선택한 이유 및 레거시 분기가 매핑되는 방식을 문서화합니다.

기록:

  • 레거시 버전 제어를 계속 실행할 기간을 결정합니다.
  • 마이그레이션해야 하는 분기를 식별합니다.
  • 필요한 경우 엔지니어가 레거시 시스템으로 돌아갈 수 있도록 이동 경로를 만듭니다.

이진 파일 및 도구:

  • 리포지토리에서 제거할 이진 파일과 변환할 수 없는 파일을 식별합니다.
  • Git-LFS와 같은 대용량 파일에 대한 접근 방식을 결정합니다.
  • NuGet과 같은 도구 및 라이브러리를 제공하는 방법을 결정합니다.

교육:

  • 학습 자료를 식별합니다.
  • 교육 이벤트, 서면 자료 및 비디오를 계획합니다.
  • 로컬 Git 전문가 역할을 할 팀의 구성원을 식별합니다.

코드 마이그레이션:

  • 마이그레이션이 원활하게 진행되도록 여러 번의 테스트 실행을 수행합니다.
  • 중단 시간을 식별하고 통신합니다.
  • 새 Git 리포지토리를 만듭니다.
  • 이전 시스템을 읽기 전용으로 설정합니다.
  • 먼저 기본 분기를 마이그레이션한 다음 필요한 다른 분기를 마이그레이션합니다.

다음 단계