モバイル開発におけるGitとバージョン管理：概要、基本コマンド、仕組み

バージョン管理とGit：とは？

Gitは、2005年にリーナス・トーバルズがLinuxカーネル開発用に作成した分散バージョン管理システム（VCS）です。集中型システム（SVN、CVS）とは異なり、Gitは各開発者のコンピュータにプロジェクト履歴の完全なコピーを保存します。つまり、インターネット接続がなくてもコミット、履歴の参照、ブランチの作成が可能です。

Gitはスナップショットで動作します — 各コミットは保存時の全プロジェクトファイルの状態を保存します。ファイルが変更されていない場合、Gitは以前のバージョンへの参照を作成し、容量を節約します。GitHubの分析（2025年）によると、平均的なリポジトリには1,200のコミットと15のブランチが含まれています。

IT Sectrでは、2017年からすべてのプロジェクトでGitを使用しています。私たちの経験では、初日から適切なGit設定を行うことで、マージと競合解決にかかるチームの時間を最大30%節約できます。Gitは事実上の標準となっており、すべての最新IDE（Android Studio、Xcode、VS Code）とCI/CDシステムでサポートされています。

# Gitの基本設定
git config --global user.name "あなたの名前"
git config --global user.email "your@email.com"

# 新しいリポジトリの作成
git init my-project
cd my-project

# ファイルの追加とコミット
git add README.md
git commit -m "Initial commit"

# リモートリポジトリでの作業
git remote add origin https://github.com/user/my-project.git
git push -u origin main

上記のコードは、リポジトリの初期化、最初のコミット、リモートサーバーへの公開という基本シーケンスを示しています。git initコマンドは、プロジェクト全体の履歴を保存する隠しフォルダ.gitを作成します。各git commitは、いつでも戻ることができる復元ポイントを作成します。

基本概念：Repository、Branch、Commit

3つの基本概念 — Repository、Branch、Commit — を理解することは、あらゆるバージョン管理システムで作業するために不可欠です。リポジトリはプロジェクト全体のコンテナです。Commitはファイルの保存された状態です。Branchは開発の独立したラインです。

Repository（リポジトリ）はローカル（自分のコンピュータ上）またはリモート（GitHub、GitLabサーバー上）にあります。各開発者はリモートリポジトリを自分のマシンにクローンし、ローカルコピーで作業します。変更はpush（送信）とpull（取得）を介して同期されます。分散バージョン管理では、各開発者が履歴の完全なコピーを保存します。

Branch（ブランチ）はコミットの1つを指すポインタです。ブランチにより並行開発が可能になります：ある開発者は新機能（feature branch）に取り組み、別の開発者はバグ修正（hotfix branch）、3人目はリリース準備（release branch）を行います。GitLab Flow（2025年）によると、平均的なプロジェクトでは同時に3〜5のアクティブブランチがあります。

Commit（コミット）は変更の単位です。各コミットには、一意のハッシュ（SHA-1）、メッセージ、作成者、タイムスタンプが含まれます。良い習慣は、説明的なメッセージとともに小さな意味のあるコミットを行うことです — これによりコードレビューと変更のロールバックが簡素化されます。コミットによるバージョン管理は、プロジェクトの完全な履歴を提供します。

Feature Branch

Feature Branch（フィーチャーブランチ）は、特定のタスクを開発するためにdevelopまたはmainから作成される一時的なブランチです。作業完了後、ブランチはPull Requestを介してマージされ、削除されます。このプラクティスにより、メインのコードベースの安定性を損なうことなく変更を分離できます。

典型的なワークフロー：ブランチfeature/add-loginを作成 → 複数コミット → Pull Requestを作成 → コードレビューを通過 → developにマージ。IT Sectrではまさにこのアプローチを使用しています：各Jiraタスクは個別のフィーチャーブランチに対応します。これにより、変更の追跡と必要に応じたロールバックが容易になります。

Rebase vs Merge

Mergeは2つのブランチを結合するマージコミットを作成します。並行開発ラインを含む完全な履歴を保持します。Rebaseは履歴を書き換えます：一方のブランチからコミットを取得し、他方のブランチの上に「再適用」して、直線的な履歴を作成します。

Mergeは、時系列が重要な公開ブランチや大規模チームに適しています。Rebaseは、PRを作成する前の個人のフィーチャーブランチに便利です — 履歴をよりクリーンで理解しやすくします。ただし、rebaseは他の開発者が作業しているブランチには決して適用すべきではありません。履歴を書き換えるためです。

# フィーチャーブランチの作成と切り替え
git checkout -b feature/add-login main

# ブランチでの作業
git add login-screen/
git commit -m "Add login screen layout"

# PR前に最新のmainにRebase
git checkout main && git pull
git checkout feature/add-login
git rebase main

# リモートリポジトリにPush
git push origin feature/add-login

この例は典型的なワークフローを示しています：mainからフィーチャーブランチを作成、複数コミット、レビューに送る前にクリーンな直線履歴を得るためにrebase。このアプローチはマージ競合を最小限に抑えます。

Git Flow vs Trunk-Based Development

Git FlowとTrunk-Based Developmentは、チームがGitでの作業をどのように編成するかを決定する2つの主要なバージョン管理戦略です。選択は、チームサイズ、リリース頻度、安定性要件によって異なります。

Git Flowは、複数の永続ブランチを持つ厳格なモデルです：main（リリースコード）、develop（現在の開発）、feature/*（新機能）、release/*（リリース準備）、hotfix/*（緊急修正）。このモデルは、明確なリリースサイクルを持つプロジェクト（バージョン1.0、2.0などのモバイルアプリ）に適しています。

Trunk-Based Developmentは、単一のメインブランチ（trunk/main）を持つアプローチで、すべての開発者が1日に複数回変更をマージします。不完全な機能を隠すためにフィーチャーフラグが使用されます。このアプローチは、デリバリー速度が重要なWeb開発やスタートアップで人気があります。

Git Flow

Git Flowは、2010年にVincent Driessenによって提案され、今でも最も人気のあるモデルの1つです。その主な利点は、ライフサイクル段階によるコードの厳格な分離です。mainブランチにはリリースコードのみが含まれ、developには現在の開発が含まれ、フィーチャーブランチは新機能を互いに分離します。

hotfixブランチは緊急修正のためにmainから作成され、マージ後にmainとdevelopの両方にマージされます。Releaseブランチは、チームがリリースの準備ができたときにdevelopから作成されます。バグ修正とメタデータ（バージョン、ビルド）のみが追加されます。リリース後、releaseブランチはmainとdevelopにマージされます。JetBrainsの調査（2024年）によると、チームの37%がGit Flowを使用しています。このバージョン管理モデルは、固定リリースのプロジェクトの標準であり続けています。

# Git Flowの例：リリース作業の開始
git checkout -b release/1.2.0 develop

# releaseブランチでのバグ修正
git commit -m "Fix login button crash"

# リリース完了 — mainとdevelopにマージ
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# releaseブランチの削除
git branch -d release/1.2.0

コードはreleaseブランチの作成、安定化、メインブランチへのマージを示しています。--no-ffフラグはマージコミットを保証し、変更がreleaseブランチから来たという情報を保持します。

Pull Requestとコードレビュー

Pull Request（PR）は、開発者が自分のブランチからメインブランチに変更を提案するメカニズムです。PRはチームワークにおけるバージョン管理の重要な要素です — 単なるコードマージの方法ではなく、議論、レビュー、品質チェックのプロセスです。GitLabでは同様のメカニズムをMerge Request（MR）と呼びますが、本質は同じです：チームに変更を通知し、承認を得ることです。

良いPRは小規模（300行まで）で、単一のタスクに集中し、何をなぜ行ったかの説明を含むべきです。Googleの調査（2025年）によると、400行を超えるPRはレビューに2倍の時間がかかり、バグ発見確率が30%低下します。コードレビューは、マージ前に別の開発者がコードをチェックすることです。

IT Sectrでは、すべてのPRに対して必須のコードレビューを実践しています。これによりコード品質が向上するだけでなく、チーム内での知識共有にも役立ちます。コードレビューでは以下をチェックします：コードがアーキテクチャ原則に従っているか、バグがないか、十分なテストがあるか、変数名が適切か。すべてのコメントはマージまでPRで議論されます。

プラットフォーム：GitHub、GitLab、Bitbucket

Gitはプロトコルですが、コラボレーションにはWebインターフェース、アクセス管理、CI/CD、レビューツールを提供するバージョン管理プラットフォームが必要です。市場では3つのプラットフォームが支配的です：GitHub、GitLab、Bitbucket。

GitHubは5600万人以上の開発者を抱える最大のプラットフォームです。Microsoftが所有し、Actions（CI/CD）、Pages（ホスティング）、Discussions、Copilotを提供しています。無料プランでは3人までのチーム向けに無制限のプライベートリポジトリが含まれます。GitHubはオープンソースコミュニティで人気です。

GitLabは、統合CI/CD、コンテナレジストリ、インフラ管理を備えた完全なDevOpsプラットフォームです。GitLabとは異なり、GitLabは自社サーバーにインストールできます（Self-Managed）。AtlassianのBitbucketはJiraやConfluenceと緊密に統合されており、既にAtlassianエコシステムを使用しているチームに適しています。