1. バージョン管理なしの問題: ファイルを単にコピーするのが悪手である理由
まずは身近な状況から始めましょう。あなたが自分の Java プロジェクトに取り組んでいるとします。すべて順調ですが、「実験」の瞬間がやって来ます。何かを変更したいが、動く版を壊すのが怖い。どうしますか？ もちろん、プロジェクトをコピーします！
その結果、ディスク上にはこんな「傑作」たちが並びます:
MyProject/
├── Main.java
├── Main_backup.java
├── Main_final.java
├── Main_final2.java
├── Main_tochno_final.java
├── Main_tochno_tochno_final.java
見覚えがありますか？ さらに、友人がプロジェクトに参加したと想像してください。彼もまたファイルをコピーするのが好き — しかも独自のやり方で。どれが最新で動作する版なのか？ 誰が何を変更したのか？ 実験が失敗したらどうやって元に戻すのか？
バージョン管理がないと:
- 動くコードを簡単に失ったり取り違えたりする。
- 以前のバージョンに戻せない。
- 2〜3人での共同作業が難しい。
- 混沌として実験が怖くなる。
こうした問題を解決するのがバージョン管理システム — たとえば Git — です。
2. なぜ開発者に Git が必要なのか？
Git は強力なバージョン管理システムで、ソフトウェア開発中のソースコードの変更を追跡するために使用されます。ファイルのさまざまなバージョンを保存し、複数人が同じプロジェクトで協調できるようにします。
Git の基本概念:
リポジトリ
リポジトリ（通称「repo」）とは、プロジェクトの全履歴、すなわちすべての変更とファイルのバージョンが保存される場所です。
コミット
commit はプロジェクトの保存状態です。各コミットには、プロジェクトにどのような変更が、誰によって、いつ加えられたかの情報が含まれます。コミットが履歴を形成し、過去の任意のバージョンに戻ることができます。
gitGraph
commit id: "1"
commit id: "2"
commit id: "3"
commit id: "4"
commit id: "5"
commit id: "6"
各コミットは前の状態に続くプロジェクトの「スナップショット」で、連続した変更履歴を形成します。
ブランチ
branch は独立した開発ラインです。デフォルトで Git は main ブランチを作成します。新機能や修正のために新しいブランチを作成し、作業完了後にそれらをメインブランチへ統合できます。
gitGraph
commit id: "1"
commit id: "2"
branch develop
commit id: "3"
commit id: "4"
commit id: "5"
checkout main
commit id: "6"
commit id: "7"
merge develop
commit id: "8"
commit id: "9"
メインブランチ main から並行開発用に develop ブランチが「枝分かれ」します。作業が終わったら、develop の変更を main に統合（マージ）します。
3. 基本的な Git コマンド（内部で起きていること）
以下はターミナルで Git を扱うための基本コマンド一覧です。どの操作もこれらのコマンドが土台になっていることを理解するのが重要です。しかし、私たちは GUI アプローチを採り、IntelliJ IDEA の使いやすいグラフィカルインターフェイスでこれらの操作を実行する方法を学びます。これらのコマンドは「内部で何が起きているか」として捉えてください。
| コマンド | 説明 |
|---|---|
git init |
現在のディレクトリに新しい Git リポジトリを初期化する。 |
git clone |
URL からリポジトリを新しいディレクトリにクローンする。 |
git add |
ファイルを次のコミットに向けてインデックス（ステージ）に追加する。 |
git commit |
準備済みの変更をリポジトリに確定する。 |
git push |
ローカルリポジトリの変更をリモートへ送信する。 |
git pull |
現在のブランチをリモートの最新状態で更新する。 |
git branch |
ブランチの表示・作成・削除を行う。 |
git merge |
指定したブランチの変更を現在のブランチに統合する。 |
これらのコマンドは Git 作業の基本ツールであり、あらゆる規模のプロジェクトでコード変更、ブランチ、マージを管理するのに役立ちます。
sequenceDiagram
participant 作業ディレクトリ
participant ステージング領域 (Staging)
participant ローカルリポジトリ
participant リモートリポジトリ
作業ディレクトリ ->> ステージング領域 (Staging): git add (ステージング)
ステージング領域 (Staging) ->> ローカルリポジトリ: git commit (ローカルに保存)
ローカルリポジトリ ->> リモートリポジトリ: git push (サーバーへ送信)
リモートリポジトリ ->> 作業ディレクトリ: git pull (更新を取得)
4. コードが保存される3つの場所
バージョン管理システムを利用すると、あなたのコードは大まかにいって3つの場所に保存されます。
1. リモートリポジトリ
これは GitHub、GitLab、Bitbucket のようなサービス上にある中央の保管場所です。コードの集中保管を提供し、コラボレーションの基盤になります。CI/CD によるビルド、テスト、デプロイなどの自動化の統合ポイントとしても機能します。
2. ローカルリポジトリ
ローカルリポジトリはあなたのコンピュータ上にある個人用のコードコピーです。インターネット接続がなくても、ここで Git のすべての操作（コミット、ブランチ、マージ）を実行できます。
3. 作業ディレクトリ
あなたのコンピュータ上の作業ディレクトリには、現在取り組んでいるプロジェクトの最新ファイルが含まれます。ここでファイルを見たり変更したり、新機能を追加したりバグを修正したりします。
これらの要素が連携して強力なソースコード管理基盤を提供し、開発者はプロジェクトの履歴を管理しつつ協力して作業できます。
5. GitHub はあなたのポートフォリオ
GitHub は、Git を使ったソースコードホスティングのための代表的な Web プラットフォームです。2008 年に創設され、世界中の開発者にとって欠かせないツールとなりました。
GitHub ではリポジトリを作成してプロジェクトを管理し、コードの変更を管理・追跡し、他の開発者と協力できます。現代の開発者にとって、GitHub のプロフィールは潜在的な雇用主に見せられるポートフォリオの重要な一部です。
6. GitHub で最初のリポジトリを作成する
手順 1. https://github.com にアクセスして登録します。
手順 2. New repository ボタンを押して新しいリポジトリを作成します。
手順 3. リポジトリのパラメータを設定します:
- リポジトリ名: 意味のある名前にしましょう。
- Public か Private か: 学習用プロジェクトには他の人が見られるよう「Public」を推奨します。
- Add a README file: 必ずチェックを入れてください。README はプロジェクトの「顔」です。
- Add .gitignore: ドロップダウンから使用言語のテンプレートを選びます。
- Choose a license: 省略可。
Create repositoryをクリック。
手順 4. おめでとうございます。最初のリモートリポジトリが作成されました！
7. Git のインストールと設定
Git の基礎はコンソールコマンドでも学べますが、日々の業務では開発者の 99% が IDE に組み込まれた便利なツールを使います。私たちの目標は、プロが実際に行っている方法で作業できるようにあなたを導くことです。
JetBrains の最新 IDE — たとえば Java/Kotlin 向けの IntelliJ IDEA、C# 向けの Rider、Python 向けの PyCharm — における Git の UI はほぼ共通です。つまり、一つの環境で Git を習得すれば、他の環境でも容易に応用できます。そこで本講義では汎用的な例として IntelliJ IDEA を使用します。ここで見る内容は、お気に入りの IDE でもほぼ同じように見え、同じように動作します。
PC で Git を使うには、まず Git をインストールする必要があります。IntelliJ IDEA を使用している場合、システムに Git が見つからなければ自動インストールを提案してくれるはずです。これは最も簡単なので、承認することをお勧めします。
現在のプロジェクトを File > Close Project で閉じ、Clone Repository をクリックしてください。
手動でインストールしたい場合は、公式サイトをご利用ください: https://git-scm.com/downloads。
8. 少し歴史: main vs master
かつて Git のデフォルトブランチは master と呼ばれていました。しかし 2020 年、開発者コミュニティと GitHub を含む主要プラットフォームは、より中立的な用語である main へ移行しました。
これは知っておくとよいでしょう。古い記事やプロジェクトでは、いまだに master ブランチへの言及に出会うことがあります。本講義および現代のプロジェクトでは、常にメインブランチは main です。
main への移行についての詳細は次のリンクを参照してください:
GO TO FULL VERSION