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

Git にする理由では、Git を利用してチームをアジャイル化する多くの方法について説明しました。切り替えを決定したら、次のステップは既存の開発ワークフローを Git に移行する方法を検討します。

このページでは、SVN から Git へチームを移行する間に遭遇する最大の課題をいくつか説明します。移行プロセスの間、心に留めておくべき最も重要なことは、Git は SVN ではないということです。Git の最大の可能性を実現するには、バージョン管理に関する新しい考え方を進んで取り入れるよう最大限努力することです。

管理者向け

Git は、チームの規模に応じて、期間に関係なく導入できます。このセクションでは、Git、および SVN から Git へのリポジトリの移行に関して、技術マネージャーが従業員に研修を行う際の主な考慮事項についていくつか説明します。

基本的な Git コマンド

以前、Git は容易に習得できると評判でした。その一方で、Git の保守担当者は、適切なデフォルト値や文脈に応じたヘルプメッセージなど、新しい改善を絶え間なくリリースして新人研修プロセスの快適性を高めてきました。

アトラシアンには、自分のペースで総合的に学べる Git チュートリアルに加えて、Web セミナーやライブトレーニングセッションも用意されています。これらが一体となって、Git を使い始めるために必要なすべてのトレーニングオプションをチームに提供しています。Git を使い始めるためのいくつかの基本的な Git コマンドのリストを以下に示します。

Git のタスク	メモ	Git コマンド
Git に自分の情報を設定する	コミットで使用する作成者名とメールアドレス設定します。Git は、user.name から一部の文字 (末尾のピリオドなど) を取り除きます。	git config --global user.name "Sam Smith" git config --global user.email sam@example.com
新しいローカルリポジトリを作成する		git init
リポジトリをチェックアウトする	ローカルリポジトリの作業コピーを作成する	git clone /path/to/repository
	リモートサーバーの場合は、以下を使用します。	git clone username@host:/path/to/repository
ファイルを追加する	ステージング (インデックス) に1つ以上のファイルを追加します。	git add *
コミット	ヘッドに変更をコミットします (リモートリポジトリにはまだコミットしません)。	git commit -m "Commit message"
	git add で追加したファイルをコミットし、それ以降変更したファイルもコミットします。	git commit -a
プッシュ	リモートリポジトリのマスターブランチに変更を送信します。	git push origin main
状況	変更したファイルおよび追加またはコミットするためにまだ必要なファイルをリストします。	git status
リモートリポジトリに接続	ローカルリポジトリをリモートサーバーにまだ接続していない場合は、サーバーを追加して変更をプッシュできるようにします。	git remote add origin
	現在設定済みのリモートリポジトリをすべてリストします。	git remote -v
ブランチ	新しいブランチを作成してそれに切り替えます。	git checkout -b
	１つのブランチから別のブランチに切り替えます。	git checkout
	ご使用のリポジトリ内のすべてのブランチをリストし、ユーザーの現在のブランチも示します。	git branch
	フィーチャーブランチを削除します。	git branch -d
	ブランチをリモートリポジトリにプッシュすると、他のユーザーがそのブランチを使用できるようになります。	git push origin
	すべてのブランチをご使用のリモートリポジトリにプッシュします。	git push --all origin
	ご使用のリモートリポジトリにあるブランチを削除します。	git push origin :
リモートリポジトリから更新する	リモートサーバー上の変更をフェッチして作業ディレクトリにマージします。	git pull
	別のブランチをアクティブなブランチにマージします。	git merge
	マージのすべての競合を表示します。ベースファイルに対する競合を表示します。マージする前に変更をプレビューします。	git diff git diff --base git diff
	競合を手動で解決した後、変更済みファイルにマークを付けます。	git add
タグ	タグを使用して、リリースなどの重要な変更セットにマークを付けることができます。	git tag 1.0.0
	CommitId は、変更セット ID の先頭の文字で最長 10 文字まで可能ですが、一意にする必要があります。次のコマンドを使用して ID を取得します。	git log
	すべてのタグをリモートリポジトリにプッシュします。	git push --tags origin
ローカル側の変更の取り消し	間違った場合に、作業ツリー内の変更をヘッドの最後のコンテンツで置き換えます。すでにインデックスおよび新規ファイルに追加された変更は保持されます。	git checkout --
	または、すべてのローカル側の変更を取り消してコミットするには、最新の履歴をサーバーからフェッチしてローカルの main ブランチがその履歴をポイントするようにします。次のコマンドを使用します。	git fetch origin git reset --hard origin/main
検索	作業ディレクトリで foo() を検索します。	git grep "foo()"

Git 移行ツール

SVN から Git への既存プロジェクトの移行を支援するツールはたくさんありますが、どのツールを利用するか決める前に、コードを移行する方法を考える必要があります。選択肢は次のとおりです。

全コードベースを Git に移行して SVN の使用を完全に停止する。
既存のプロジェクトは Git に移行せず、すべての新規プロジェクトに Git を使用する。
一部のプロジェクトを Git に移行するが、その他のプロジェクトでは引き続き SVN を使用する。
同じプロジェクトで同時に SVN および Git を使用する。

Git へ完全移行することで開発ワークフローの複雑さが緩和されるため、これは望ましいオプションです。ただし、多くの開発チームが存在し、非常に多くのプロジェクトが稼働する可能性が高い大規模な企業では、これは必ずしも可能ではありません。そのような場合は、併用するほうが安全です。

移行ツールの選択は、上記のどの計画を選択するかにより、大きく異なります。以下に 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 とプロジェクトの依存関係」という有益な記事に記載されています。

開発者向け

あらゆる開発者のためのリポジトリ

開発者として調整が必要な最大の変更は、配布という 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 の本格展開、およびセキュリティと権限への対応を行うための一般的なオプションをいくつか紹介します。移行プロセスの間、開発者が心得ておくべき最大の課題についても説明します。

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