こんにちは。テクマトリックスの橘です。
【これからのソースコード管理！チーム開発を加速するGitによる効率的な開発環境】というセミナーを2025年7月15日に開催しました。

本ブログではセッション内で回答しきれなかったものも含め、改めて皆様から頂いた質問について回答をさせていただきます。また、質問文につきましては、基本的に原文のまま掲載させていただきます。

本記事では、私が担当させていただいたセッション「Subversionからの脱却！Git移行で実現する、モダンな開発環境」にて頂いた質問を取り上げさせていただきます。
もう一つのセッション「脱・共有フォルダ！Gitで始める、モダンなソースコード管理」にて頂いた質問については、以下の別記事をご覧ください。

質問1：GitHubのSubversionサポートについて

GitHub公式にて、Subversionサポートの終了が発表され、2024年1月8日以降、SVNクライアントを使用したGitHubの利用ができなくなりました。では、もともとこのSubversionサポートとはどんな機能だったのでしょうか？

GitHubのSubversionサポートとは？

この機能の具体的な内容についてはこちらのGithub公式のページにも記載がありますが、端的に言うと、「GitHubをSubversionライクに利用」することができる機能です。今まで慣れ親しんできたSubversionクライアント（例：TortoiseSVN）を利用したままGitHubに対して、以下のような操作を実施することができました。

• GitHubリポジトリのチェックアウト
• ブランチの作成
• 変更の反映（コミット）
• ブランチの切り替え
  

要するに、リポジトリに対しての基本的な操作を実施することができていたわけですが、現在はこの機能が廃止されているため、Subversionクライアントではなく、Gitクライアントやコマンドラインを利用する必要があります。

もともとGitHubがSubversionサポートを開始した2010年当時は、Gitが今ほど主流ではなくむしろ圧倒的な少数派で、既存のSubversionユーザーを段階的にgitに移行してもらうためにこの機能を開発したようです。しかし、それから状況は一変し、以下のデータが示すように、現在はSubversionが少数派となりGitが支配的なポジションを築いています。

　　　　_{グラフ：Stack Overflowの2022年サーベイ、Version control systemsの結果を元に作成}

GitHub公式によると、2023年1月時点で、Subversionエンドポイント経由のものはわずか0.02%未満、毎月Subversionリクエストが1件以上確認されているリポジトリはわずか5,000件程度とのことです。そのため、利用率の低さから、該当機能は廃止されたと考えられます。

質問2：SubversionからGitへの移行について

Subversionの履歴をGitに移行するには、いくつかのやり方がありますが、ここではgit svnコマンドをご紹介します。

Git標準のgit svnコマンドの利用

git svnはGitに標準で組み込まれているツールであり、SVNからGitへの移行や相互運用が可能です。このツールには、以下のような特徴があります。

• SVNの全履歴（コミット履歴、ブランチ、タグ）をGitに変換可能。
• 細かい制御が可能で、特定のブランチや範囲を選択して移行可能。

ただし、大規模なリポジトリや複雑な構造のプロジェクトでは、移行に時間がかかることがあるようです。より詳細な内容については以下の記事にて説明させて頂いております。

質問3：Gitに対するSubversionの優位点

Subversionの主な優位性は以下の点にありますが、特定の要件がなければGitの利用が推奨される場合がほとんどです。

シンプルな権限管理
Subversionはリポジトリ単位やディレクトリ単位での権限管理が容易です。

大容量ファイルの管理
SubversionはGitに比べて大容量ファイルの管理に適している場合があります。

既存の運用負担
既存の運用やチームのスキルによっては、Subversionの使い慣れた環境を維持する方が、Gitへの移行よりもコストが低い場合があります。

ただし、これらの優位性もGitの進化（LFSの導入など）で縮小しており、多くの場合、Gitへの移行が長期的に見た場合は有益と考えるのが自然です。特にGitHubなどのホスティングサービスでは、プルリクエストによるコードレビュー機能など、Gitの利点を活かした開発プロセスが充実しており、非常に魅力的な選択肢となっています。

以下の記事でもSubversionからGitに移行するべきか判断するうえで、業界ごとのソフトウェア開発の特徴や、 Gitが向いているケース、Subversionが採用されているケースについて解説をしていますので、ぜひご覧ください。

質問4：SubversionとGitの比較(コンフリクト解消)

GitとSVNでは、コンフリクト解消のプロセスは似ていますが、Gitの方が柔軟で効率的な方法を提供しています。

Gitの特徴

• ローカルでの解消: Gitは、ローカル環境でコンフリクトを解消できます。そのため、ネットワーク接続がなくても作業を進められ、効率的に解決できます。
• 強力なツール: Gitにはgit mergeやgit rebaseなどのコマンドが用意されており、コンフリクト解消を効率的にサポートします。

SVNの特徴

• サーバーとのやり取り: SVNでは、コンフリクト解消のためにサーバーとやり取りする必要があるため、ネットワーク接続が必須です。
• シンプルな機能: SVNは、コンフリクト解消の機能がシンプルなため、複雑なコンフリクトが発生した場合、解決に時間がかかる場合があります。

表にまとめると以下のようなイメージです。

例えば、複数の開発者が同時に同じファイルを変更した場合、Gitではローカルでコンフリクトを解消し、解決後にプッシュできます。一方、SVNでは、サーバーとやり取りしながらコンフリクトを解消する必要があるため、ネットワーク接続が必須です。また、複雑なコンフリクトが発生した場合、SVNでは解決に時間がかかる場合があります。

従って、Gitは、ローカルでの迅速な作業と柔軟な機能により、SVNよりも効率的にコンフリクトを解消することができると言えます。

質問5：Gitのチェリーピックについて

Gitには、あるブランチのコミットを別のブランチに適用するチェリーピック（cherry-pick）という機能があります。
チェリーピックを使うと、複数のコミットから必要なものだけを選び、リモートリポジトリに反映させることができます。

git cherry-pickの使用方法
特定のコミットを作業ブランチに適用します。コミットIDはgit log等で確認します。

git cherry-pick <コミットID>

複数のコミットをチェリーピックする場合は、コミットIDをスペースで区切って指定できます。

git cherry-pick <コミットID1> <コミットID2>

未選択の内容も後から選択してプッシュ可能か？
可能です。Gitではコミット単位で操作できるため、未プッシュの内容を後から選択的にプッシュできます。たとえば、特定のコミットだけを別のブランチにチェリーピックして、そのブランチをプッシュすることもできます。
質問6への回答にてプルリクエストを絡めたチェリーピックの手順についても解説をしていますので、そちらもご覧ください。

最終的に選択しなかった内容はローカルに保持されるか？
はい、選択しなかったコミットや変更はローカルに保持されます。Gitはローカルでの履歴管理が可能なため、未プッシュの内容がそのまま残ります。

ローカルの未選択内容を任意で削除可能か？
任意で削除可能です。不要なコミットや変更は以下の方法で削除できます。

• 特定のコミットを削除：git revert <コミットID>
• ブランチごと削除（不要な作業ブランチの場合）：git branch -d <ブランチ名>

ブランチを別に作成しておく必要があるか？
必要に応じてブランチを分けることをおすすめします。たとえば、未選択の内容を整理したり、他の作業と混在させないために以下のようにブランチを活用できます。

• 作業ごとにブランチを分けることで、特定のコミットをプッシュしたり、残りを保持したりする操作が簡単になります。
• チェリーピックやリベースを利用して、必要なコミットだけを別のブランチに反映することも可能です。

この方法により、安全かつ効率的に変更内容を管理できます。

未選択のコミット内容を含むブランチを削除した場合、コミット情報も失われるか？
ローカルリポジトリにしか存在していないコミットを含むブランチを削除した場合は、 基本的にはそのコミット情報も削除されます。ただし、Gitでは、削除したブランチのコミット情報は一時的にログに記録されるため、git reflogを使用して履歴を確認し、削除したブランチのコミットに再度アクセスすることが可能です。

git reflog使用例
git reflogコマンドで、ログを表示し、該当のブランチの最新コミットのログ番号を確認します。
ログ番号を指定し、ブランチを復元します。

git reflog
git branch ブランチ名 HEAD@{ログ番号}

ただし、reflogは一定期間（通常90日）後に自動でクリアされるため、長期間経過すると履歴にはアクセス不能になり、コミット情報は永久に失われることになります。

質問6：チェリーピックとプルリクエストについて

mainブランチに対して直接チェリーピックをすることは可能ですが、その場合プルリクエストを通さずに変更がmainにマージされてしまい、レビューや履歴管理が難しくなるため推奨されません。以下の様な手順で、プルリクエストと組み合わせることによって安全かつ効率的にチェリーピックを行うことができます。

mainブランチを最新の状態に更新
まず、mainブランチをリモートリポジトリから最新の状態に更新します。

git checkout main
git pull origin main

チェリーピック用の一時ブランチを作成
mainブランチから新しい一時ブランチを作成します。ここでは、cherry-pick-branchという名前のブランチを作成しています。

git checkout -b cherry-pick-branch

必要なコミットをチェリーピック
特定のコミットを一時ブランチに適用します。コミットIDはgit log等で確認します。

git cherry-pick <コミットID>

チェリーピック内容を確認
チェリーピックした内容を確認し、コンフリクトが発生している場合は解消します。

git status

リモートリポジトリにプッシュ
一時ブランチをリモートリポジトリにプッシュします。

git push origin cherry-pick-branch

プルリクエストを作成
プルリクエストを作成し、レビュー後にmainブランチにマージします。

一時ブランチの削除
プルリクエストがマージされたら、一時ブランチを削除して整理します。

git branch -d cherry-pick-branch
git push origin --delete cherry-pick-branch

なぜこの方法が適切なのか？

• 安全性：チェリーピックの内容を確認しながら進められるため、mainブランチに直接変更を加えるリスクを最小限にできます。
• コラボレーション：プルリクエストを利用することで、チームメンバーと変更内容を共有し、レビューを実施できます。これにより、コードの品質向上と、開発チーム全体の理解促進に役立ちます。
• 履歴の管理：プルリクエストを通して チェリーピック を行うことで、main ブランチの履歴をシンプルかつ整然と保つことができます。これにより、開発履歴を追跡しやすくなり、コードの変更点などを容易に把握できます。

チェリーピックを行う際には、必ず一時ブランチを作成してから作業を進めることをおすすめします。この方法により、安全性を確保しつつ、チームでのコラボレーションやレビューを効率的に行うことができます。

質問7：プルリクエスト依頼時などの事前確認

目視確認も重要ですが、効率的にコンフリクトや修正漏れを防ぐには、以下のような機能を活用することをおすすめします。

1. 自分のブランチを最新のmainやdevelopにリベースまたはマージ

プルリクエストを作成する前に、自分の作業ブランチを最新のmainやdevelopブランチにリベース（またはマージ）することで、コンフリクトを事前に検出できます。

• リベース（git rebase）
  リベースでは、自分のコミットを最新のmainブランチの履歴に「付け替える」操作を行います。これにより、履歴が直線的に整理され、コンフリクトが解消しやすくなります。
  ただし、リモートリポジトリにプッシュ済みのブランチでリベースをするとコミット履歴が複雑になってしまう（親コミットが変わってしまう）ため、未プッシュのブランチで実施する方がおすすめです。

git checkout feature-branch
git fetch origin
git rebase origin/main

• マージ（git merge）
  マージでは、mainブランチの変更を自分のブランチに統合します。リベースに比べて履歴が直線的にはならないため、複雑になりやすいですが、作業内容をそのまま保持したい場合に有効です。

git checkout feature-branch
git fetch origin
git merge origin/main

どちらの方法を使う場合でも、ローカルでコンフリクトが発生すれば、プルリクエストを作成する前に解消できるため、作業がスムーズになります。

2. プラットフォームのコンフリクト自動検出機能を活用

GitHubやGitLabなどのプラットフォームでは、プルリクエスト作成時にコンフリクトの有無を自動的にチェックしてくれる機能があります。

• GitHubの場合:
  プルリクエスト画面で「No conflicts with base branch」と表示される場合、コンフリクトがないことが確認できます。逆に、コンフリクトがある場合は警告が表示され、解消が求められます。

• GitLabの場合:
  プルリクエスト作成時にマージが可能かどうかや、コンフリクトがあるかどうかを自動検出して通知します。コンフリクトがある場合、「Merge blocked: merge conflicts must be resolved.」と表示されます。

これらの機能を利用することで、目視確認だけに頼らず、自動的にコンフリクトを検出できるため、作業の効率化に繋がります。

まとめ

今回はセミナー内でいただいた以下の質問について回答させていただきました。

• 質問1：GitHubのSubversionサポートについて
• 質問2：SubversionからGitへの移行について
• 質問3：Gitに対するSubversionの優位点
• 質問4：SubversionとGitの比較(コンフリクト解消)
• 質問5：Gitのチェリーピックについて
• 質問6：チェリーピックとプルリクエストについて
• 質問7：プルリクエスト依頼時などの事前確認

本ウェビナーの資料ダウンロードは、こちらのページより可能です。

テクマトリックスでは環境構築からトレーニングまでGitの導入支援が可能です。
お客様のご要望や開発プロセスをヒアリングしたうえで、Gitを用いたソフトウェア構成管理（バージョン管理）の環境構築・移行を行います。また、運用のコンサルティング、トレーニングなども実施しています。
特に、Gitの適切な運用方法や、問題が発生した際の対処法などについての教育は、開発の効率化と安全性向上に大いに寄与します。どのような運用が最適か迷ったり、Gitの使い方についての疑問がある場合は、お気軽にご相談ください。

詳細については、次のボタンより参照ください。