次の方法で共有

履歴を含めて Subversion (SVN) から Git に移行する方法について説明します

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Subversion (SVN) などの別のバージョン コントロール システムから Git に移行する場合、通常は、履歴を含めずに、リポジトリ コンテンツの最新バージョンのみを移行する "ヒントの移行" を実行することをお勧めします。 ただし、多くのユーザーは、履歴を含めた、より高度な移行を実行したいと考えています。 この記事で提供されるガイダンスでは、履歴を "含めた" 移行について説明します。

Git への SVN の移行は、リポジトリの古さ、作成およびマージされたブランチの数、通常の SVN を使用しているか、SVK のような近いものを使用しているかによって、複雑さが異なる場合があります。

次の場合は単純になります。

  • 新しいリポジトリがある
  • トランク、ブランチ、タグ ディレクトリの標準セットアップがある

次の場合は複雑になる可能性があります。

  • チームが多くの分岐操作とマージ操作を実行している
  • リポジトリが非標準のディレクトリ設定に従っている
  • ディレクトリ セットアップが時間の経過とともに変化している

SVN から Git に移行するには、いくつかの方法があります。 この記事で説明するアプローチは、Git 拡張機能である git-svn の使用に基づいています。これを使用すると、Subversion リポジトリをローカル Git リポジトリにチェックアウトし、その後、ローカル Git リポジトリから Subversion リポジトリに変更をプッシュできます。 これらの手順では、元の SVN リポジトリと同期せずに、Windows 環境で SVN から Git に移行するプロセスの詳細な概要を示します。 結果は、チームの残りの部分と共有するためのベア Git リポジトリになります。

注意

ソース コードを一元化されたバージョン コントロール システムから Git に移行する前に、一元化されたバージョン コントロール システムと分散バージョン コントロール システムの違いをよく理解し、チームの移行を計画してください。 準備が完了したら、移行を開始できます。

SVN から Git に移行するための大まかなワークフローは次のとおりです。

  • 移行環境を準備する
  • ソース SVN リポジトリをローカル Git リポジトリに変換する
  • (省略可能) 開発者が SVN を引き続き使用している間は、ローカル Git リポジトリを SVN リポジトリからの変更と同期する
  • ローカル Git リポジトリを、Azure Repos でホストされているリモート Git リポジトリにプッシュする
  • SVN リポジトリをロックし、残りの変更を SVN リポジトリからローカル Git リポジトリに同期し、最終的な変更を Azure Repos のリモート Git リポジトリにプッシュする
  • 開発者がメイン ソース管理システムとして Git に切り替える

移行環境を準備する

ローカル ワークステーションで移行環境を構成し、次のソフトウェアをインストールします。

また、変換された SVN リポジトリをホストするために組織用の Git リポジトリを作成する必要があります。プロジェクトに新しい Git リポジトリを作成 従うことができます

ソース SVN リポジトリをローカル Git リポジトリに変換する

この手順の目的は、ソース Subversion リポジトリをローカルの "ベア" Git リポジトリに変換することです。 bare Git リポジトリには、変更可能なファイルのローカル作業チェックアウトはありません。代わりに、リポジトリの履歴とリポジトリ自体に関するメタデータのみが含まれます。 これは、Azure Repos などのサービスでホストされているリモート リポジトリを介して Git リポジトリを共有するために推奨される形式です。

ヒント

"ベア" Git リポジトリは構造が異なり、作業ディレクトリがないため、リポジトリへの直接コミットはできません。

ベア Git リポジトリ

すべての Subversion 作成者の一覧を取得する

Subversion は各コミットにユーザー名のみを使用しますが、Git は本名とメール アドレスの両方を保存します。 既定では、git-svn ツールは作成者と電子メールの各フィールドに SVN ユーザー名を一覧表示します。 ただし、SVN ユーザー用のマッピング ファイルを、対応する Git 名と電子メールとともに作成することは可能です。

Subversion ユーザー

Subversion ユーザー

Git ユーザー

Git ユーザー

ローカル Subversion チェックアウトのルートからすべての SVN ユーザーの一覧を抽出するには、次の PowerShell コマンドを実行します。

utf8NoBOMエンコードの結果を得るには、次のコマンドを実行します。

svn.exe log --quiet | ? { $_ -notlike '-*' } | % { "{0} = {0} " -f ($_ -split ' | ')[1] } | Select-Object -Unique | Sort-Object | Out-File 'authors-transform.txt' -Encoding utf8NoBOM

ASCIIエンコードの結果を得るには、次のコマンドを実行します。

svn.exe log --quiet | ? { $_ -notlike '-*' } | % { "{0} = {0} " -f ($_ -split ' | ')[1] } | Select-Object -Unique | Sort-Object | Out-File 'authors-transform.txt' -Encoding ASCII

このコマンドは、すべてのログ メッセージを取得し、ユーザー名を抽出し、重複するユーザー名を排除し、ユーザー名を並べ替え、UTF-8 形式 (または指定したエンコードに応じて ASCII 形式) で authors-transform.txt ファイルに配置します。 その後、ファイル内の各行を編集して、適切な形式の Git ユーザーへの SVN ユーザーのマッピングを作成できます。 たとえば、jamal = jamal <jamal> を jamal = Jamal Hartnett <jamal@fabrikam-fiber.com> にマップできます。

git-svn を使用して Subversion リポジトリを複製する

次のコマンドは、前の手順で作成した authors-transform.txt ファイルを使用して、標準の git-svn 変換を実行します。 お使いのローカル コンピューターの c:\mytempdir フォルダーに Git リポジトリが配置されます。

git svn clone ["SVN repo URL"] --prefix=svn/ --no-metadata --authors-file "authors-transform.txt" --stdlayout c:\mytempdir

注意

--prefix=svn/ が必要なのは、これがないとツールが SVN リビジョンとインポートされたリビジョンを区別できないためです。 SVN 追跡参照は refs/remotes/$prefix/ に配置され、Git 独自のリモート追跡ブランチ レイアウト (refs/remotes/$remote/) と互換性があるため、プレフィックス (末尾にスラッシュ) を設定することをお勧めします。

プレフィックスの設定は、共通リポジトリを共有する複数のプロジェクトを追跡する場合にも便利です。 既定では、プレフィックスは origin/ に設定されています。

標準のトランク、ブランチ、タグのレイアウトを使用している場合は、 --stdlayout配置します。 ただし、何か違うものがある場合は、--trunk、--branches、--tags を渡して何が何かを見つける必要があります。 たとえば、リポジトリ構造が trunk/companydir で、それをトランクではなく分岐させた場合は、--trunk=trunk/companydir --branches=branches が必要になる場合があります。

git svn clone ["SVN repo URL"] --prefix=svn/ --no-metadata --trunk=/trunk --branches=/branches --tags=/tags  --authors-file "authors-transform.txt" c:\mytempdir

注意

このコマンドは、SVN リポジトリのサイズによっては数分から数時間かかる場合があります。 完了すると、リポジトリの Git チェックアウトが行われます。

バージョン コントロール固有の構成を変換する

SVN リポジトリで svn:ignore プロパティが使用されていた場合は、次を使用して .gitignore ファイルに変換できます。

cd c:\mytempdir
git svn show-ignore --id=origin/trunk > .gitignore
git add .gitignore
git commit -m 'Convert svn:ignore properties to .gitignore.'

ヒント

.gitignore の詳細を読む: Git でファイルの変更を無視する

リポジトリをベア Git リポジトリにプッシュする

この手順では、ベア リポジトリを作成し、その既定のブランチを SVN のトランク ブランチ名と一致させます。

  1. ベア Git リポジトリを作成する

    git init --bare c:\new-bare.git
cd c:\new-bare.git
git symbolic-ref HEAD refs/heads/svn/trunk

  2. ローカル Git リポジトリを新しいベア Git リポジトリにプッシュする

    cd c:\mytempdir 
git remote add bare c:\new-bare.git 
git config remote.bare.push refs/remotes/*:refs/heads/* 
git push bare

  3. trunk ブランチの名前を main に変更します。 メイン開発ブランチは、"trunk" という名前になります。これは、Subversion での名前と一致します。 次を使用して、名前を Git の標準の main ブランチに変更します。

    cd c:\new-bare.git
git branch -m svn/trunk main

  4. ブランチとタグをクリーンアップする git-svn は、すべての Subversions タグを Git の "tags/name" という形式の非常に短いブランチにします。 これらのブランチをすべて実際の Git タグに変換するか、削除します。

SVN タグを Git タグに移行する

cd c:\new-bare.git
git for-each-ref --format='%(refname)' refs/heads/svn/tags | % { $_.Replace('refs/heads/svn/tags/','') } | % { git tag $_ "refs/heads/svn/tags/$_"; git branch -D "svn/tags/$_" }

高度な移行

すべての SVN ブランチを適切な Git ブランチとして作成する

すべての SVN ブランチを適切な Git ブランチとして作成するのは簡単ですが、続行する前に次の点を評価することをお勧めします。

  • 機能ブランチがある場合: それらがトランクに統合されるまで待ってから移行することはできますか?

  • リリース ブランチがある場合: サービスのために SVN を維持することは意味がありますか? 機能ブランチを移行する場合、Git からブランチにサービスを提供する準備はできていますか?

それでも既存のブランチを移行する場合は、次の PowerShell コマンドを実行します。

git for-each-ref --format='%(refname)' refs/remotes | % { $_.Replace('refs/remotes/','') } | % { git branch "$_" "refs/remotes/$_"; git branch -r -d "$_"; }

注意

このコマンドは、SVN リポジトリのサイズによっては数分から数時間かかる場合があります。 完了すると、リポジトリの Git チェックアウトが行われます。

特定のリビジョンのみを移行する

指定しない場合、git-svn clone は最初のコミット (r1) からすべてのリビジョンを HEAD に移行します。 特定のリビジョン セットのみを移行する必要がある場合は、git-svn clone のコマンドに -r オプションを追加する必要があります。

たとえば、rev 100 から HEAD に移行する必要がある場合、コマンドは次のようになります。

git svn clone ["SVN repo URL"] --prefix=svn/ --no-metadata --authors-file "authors-transform.txt" --stdlayout c:\mytempdir -r100:HEAD

ワークフローを更新する

一元化されたバージョン コントロール システムから Git への移行は、単なるコードの移行だけではありません。 チームには、Git が既存のバージョン コントロール システムとどのように異なるのか、またそれらの違いが日常業務にどのように影響するかを理解するためのトレーニングが必要です。 詳細については、こちらを参照してください。

参照情報

著者: Hosam Kamel、William H. Salazar | この記事の出典を見つけて ALM と接続してください | DevOps Rangers Branching guidance

(c) 2017 Microsoft Corporation. All rights reserved. このドキュメントは、"現状のまま" 提供されます。URL およびその他のインターネット Web サイトの参照を含む、このドキュメントの情報および見解は、予告なしに変更することがあります。 このドキュメントの使用上のリスクは、すべてユーザーが負うものとします。

このドキュメントは、マイクロソフト製品に含まれる知的財産に対していかなる法的権利も付与しません。 内部での参照を目的とする場合、このドキュメントをコピーして使用できます。