SVN から Git への移行を準備する

アトラシアンの移行スクリプト

Git への移行を急いで行う必要がある場合、アトラシアンの移行スクリプトが適しています。これらのスクリプトには、既存の SVN リポジトリから Git リポジトリへの変換を確実に実行するのに必要なすべてのツールが用意されています。結果として得られるネイティブの Git 履歴により、変換プロセス後に SVN と Git 間の相互運用性の問題に対処する必要はありません。

これらのスクリプトを使用してコードベース全体を Git リポジトリのコレクションに変換するための完全な技術的ウォークスルーを提供しました。このウォークスルーでは、SVN 作成者情報の抽出から非標準の SVN リポジトリ構造の再編成まで、あらゆることを説明します。

SVN Mirror for Stash (現 Bitbucket) プラグイン

SVN Mirror for StashSVN Mirror for Stash は Bitbucket プラグインで、SVN と Git の両方で動作するハイブリッド コードベースを簡単に維持できます。アトラシアンの移行スクリプトとは異なり、SVN Mirror for Stash では、必要に応じて同じプロジェクトで Git と SVN を同時に使用できます。

大規模企業の場合、この折衷案は優れたオプションです。様々なチームが必要に応じてワークフローを移行できるようにすることで、漸進的に Git を導入できます。

Git-SVN とは

Git-SVN ツールは、ローカル側の Git リポジトリとリモート側の SVN リポジトリ間のインターフェイスとして機能します。これにより、開発者はローカルで Git を使用してコードを記述し、コミットを作成してから、これらを svn コミット様式で中央の SVN リポジトリにプッシュできます。これは一時的である必要がありますが、SVN から Git への切り替えについて議論する際に役立ちます。

Git への切り替えを迷っており、完全な移行を決定せずに一部の開発者に Git コマンドを検討させたい場合は、git svn を選択することをお勧めします。これはトレーニング段階にも最適です。突然移行するのではなく、ローカルで Git コマンドを使用することで Git に徐々に慣れることができるため、コラボレーション ワークフローに関する不安がなくなります。

git svn は移行プロセスの一時的な段階でのみ使用すべきです。“バックエンド” の SVN にまだ依存しているため、ブランチ作成や先進的なコラボレーション ワークフローなど、より強力な Git 機能は利用できません。

ロールアウト戦略

コードベースの移行は、Git 導入の一側面にすぎません。そのコードベースの背後にいるユーザーに対して Git を導入する方法についても検討する必要があります。外部コンサルタント、社内の Git 推進派、およびパイロットチームは、開発チームを Git に移行するための主要な３つの戦略です。

外部の Git コンサルタント

Git コンサルタントは基本的にわずかな料金でお客様の移行プロセスを代行できます。これは、時間をかけずにチームに完全に適した Git ワークフローを作成できるという利点があります。また、チームが Git を学習している間、専門的なトレーニング・リソースを利用できます。アトラシアン・パートナーは、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 に移行したときに、これを実際に体験しました。Jira プラグインは、すべて以前は 1 つの 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 でブランチを捨てるだけです。何か役に立つものを構築したら、それを main ブランチにマージするよう求めるプル・リクエストを提出します。

考えられる Git ワークフロー

Git ワークフローを選択する際、チームのニーズを考慮することが重要です。単純なワークフローは開発の速度や柔軟性を最大化でき、一方、複雑なワークフローは進行中の作業の一貫性と管理を強化できます。以下にリストされている一般的なアプローチを修正したり、組み合わせたりすることで、ニーズやチームの様々な役割に合うアプローチを構成できます。例えば、中心的な開発者はフィーチャーブランチを使用し、請負業者はフォークから作業する場合があります。

• 集中化ワークフローは、一般的な SVN プロセスに最も近いワークフローであるため、初めて使用するのに適しています。
• そのアイデアを基にしてフィーチャーブランチワークフローを使用することで、開発者は進行中の作業を分離環境に維持して重要な共有ブランチを保護することができます。フィーチャーブランチは、プルリクエストによる変更を管理するための基礎にもなります。
• Gitflow ワークフローは、フィーチャーブランチを拡張してより秩序立った構造にしたもので、明確なリリースサイクルを持つ大規模なチームにとって最適なオプションです。
• 最後に、最大限の分離環境で変更を管理する必要がある場合や、多くの開発者が１つのリポジトリに関係している場合、フォーク型ワークフローを検討します。

しかし、プロのチームとして Git から最大の利益を得たいと真剣に考えているのであれば、フィーチャーブランチのワークフローを検討すべきです。これは非常に安全で、驚くほど拡張性が高く、アジャイルの典型である真の分散ワークフローです。

チームを Git へ移行することは、困難な作業になる場合もありますが、必ずそうなるとは限りません。この記事では、既存のコードベースの移行、開発チームへの Git の本格展開、およびセキュリティと権限への対応を行うための一般的なオプションをいくつか紹介します。移行プロセスの間、開発者が心得ておくべき最大の課題についても説明します。

開発の規模や、現在取り組んでいる開発に関係なく、企業に分散開発を導入するための確固たる基盤が存在していることが理想です。