1. バージョン管理がない問題: ファイルをコピーするだけがなぜ良くないか
実際の状況から始めましょう。C#。すべて順調ですが、「実験」の段階になると問題が出ます。何かを変更したいけど、動作しているバージョンを壊すのが怖い。どうするか？ もちろん、プロジェクトをコピーします！
結果としてディスク上にこんな傑作が並びます:
MyProject/
├── Main.cs
├── Main_backup.cs
├── Main_final.cs
├── Main_final2.cs
├── Main_tochno_final.cs
├── Main_tochno_tochno_final.cs
心当たりがありますか？ さらに友達がプロジェクトに参加したと想像してみてください。彼もファイルをコピーするのが好きで、ただし自分流にやります。どれが最新で動くバージョンかわかりますか？ 誰が何を変更したかをどうやって知りますか？ 実験が失敗したときにどうやって元に戻しますか？
バージョン管理がない場合:
- 作業中のコードを簡単に失ったり混同したりする。
- 古いバージョンに「ロールバック」することが不可能。
- 二人、三人での共同作業が難しい。
- 混乱と実験への恐怖が生まれる。
まさにこれらの問題を解決するのが、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 |
指定したブランチの変更を現在のブランチに統合します。 |
これらのコマンドは、プロジェクトのコード変更、ブランチ、マージを管理するための基本的なツール群です。どんな規模のプロジェクトでも役立ちます。
sequenceDiagram
participant 作業ディレクトリ
participant ステージング領域（Staging）
participant ローカルリポジトリ
participant リモートリポジトリ
作業ディレクトリ ->> ステージング領域（Staging）: git add (準備)
ステージング領域（Staging) ->> ローカルリポジトリ: git commit (ローカルに保存)
ローカルリポジトリ ->> リモートリポジトリ: git push (サーバーへ送信)
リモートリポジトリ ->> 作業ディレクトリ: git pull (更新を取得)
4. コードが保存される3つの場所
バージョン管理システムを使うと、コードはおおまかに言って3つの場所に保存されます:
1. リモートリポジトリ
これはコードを中央で保存する場所で、通常はGitHub、GitLab、またはBitbucketのようなサービスにホストされます。中央集権的なコード保存と共同作業の基盤を提供します。リモートリポジトリはビルドやテスト、デプロイといった自動化プロセスの統合ポイントにもなります。
2. ローカルリポジトリ
ローカルリポジトリはあなたのコンピュータ上にあるコードの個人コピーです。このリポジトリではネット接続がなくてもすべてのGit操作（コミット、ブランチ、マージ）が可能です。
3. 作業ディレクトリ
作業ディレクトリは現在あなたが作業しているプロジェクトのファイル群を含みます。ここでファイルを見て編集し、新機能追加やバグ修正を行います。
これらのコンポーネントが連携してソースコード管理の強力なインフラを提供し、開発者がプロジェクトの履歴を管理し共同作業することを可能にします。
5. GitHub — あなたのポートフォリオ
GitHub はソースコードホスティングのための主要なウェブプラットフォームで、Gitを使ったバージョン管理を提供します。2008年に設立され、世界中の開発者にとって重要なツールとなりました。
GitHubではユーザーがプロジェクト管理用のリポジトリを作成し、コードの変更を追跡・管理し、他の開発者と協力することができます。現代の開発者にとってGitHubのプロフィールは、採用担当者に見せられる重要なポートフォリオの一部です。
6. GitHubで最初のリポジトリを作る
ステップ1. https://github.com にアクセスして登録します。
ステップ2. 新しいリポジトリを作成するにはNew repositoryボタンをクリックします。
ステップ3. リポジトリの設定を行います:
- リポジトリ名: 意味のある名前を考えます。
- 公開または非公開: 学習プロジェクトなら他の人にも見えるように"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のためのインターフェースはほぼ同一です。つまり一つの環境でGitの使い方を覚えれば、別のIDEでも同じスキルをすぐに活用できます。ここでは一般例としてIntelliJ IDEAを使います。ここで見るものはあなたの好きなIDEでもほぼ同じ見た目と動作になります。
コンピュータでGitを使うには、まずGitをインストールする必要があります。IntelliJ IDEAを使っている場合、システムにGitが見つからないとIDEが自動でインストールを提案することが多いです。その提案には従うことをお勧めします — これが最も簡単な方法です。
現在のプロジェクトを閉じるには File > Close Project を選び、Clone Repository をクリックします。
手動でインストールしたい場合は、公式サイトを使ってください: https://git-scm.com/downloads.
8. 少し歴史: main と master
以前はGitのデフォルトブランチ名はmasterでした。しかし2020年に開発コミュニティと主要プラットフォーム（GitHubを含む）は、より中立的な用語としてmainの使用に移行しました。
これは知っておくべき重要な点で、古い記事やプロジェクトではまだmasterの表記に出会うことがあります。我々の講義と現代のプロジェクトでは主要ブランチは常にmainになります。
mainへの移行について詳しく知りたい場合は、以下のリンクを参照してください:
GO TO FULL VERSION