5.バージョン管理

学習目標

チーム開発で Git が担う役割を説明できる
ローカルリポジトリとリモートリポジトリの違いを説明できる
変更を git add → git commit → git push で記録・共有できる
.gitignore でコミットしないファイルを指定できる
.gitattributes で改行コードをそろえられる
プロジェクトを GitHub に置き、ほかのメンバーと共有できる
コミットメッセージに種別を付けて、履歴を読みやすくできる

本章では、プロジェクトの準備の Spring Boot プロジェクトと MySQL を Git でバージョン管理し、GitHub の共有リポジトリに置いて、各メンバーがクローンできるようにします。

1. Git

1-1. Git の役割

Git は、ファイルの変更履歴を記録し、複数人の変更を 1 つにまとめるバージョン管理システムです。チーム開発で Git が担うのは、次の 3 つです。

各メンバーの変更を 1 つにまとめる
同じ箇所への変更が衝突したときに解消する
「いつ・誰が・何を」変更したかを履歴として残す

1-2. ローカルとリモート

プロジェクトを Git で管理する単位を リポジトリ と呼びます。リポジトリには 2 種類あります。各メンバーの PC にあるリポジトリを ローカルリポジトリ、サーバー上でチームが共有するリポジトリを リモートリポジトリ と呼びます。

各メンバーは、自分のローカルリポジトリで作業し、その変更をリモートリポジトリに送って共有します。GitHub は、リモートリポジトリを保管する Web サービスです。

1-3. 変更の記録と共有

Git は、変更を コミット という単位で記録します。コミットは、ある時点のファイルの状態を記録したものです。

変更を記録し、チームに共有するには、次の 3 つのコマンドを順に使います。

コマンド	内容
`git add`	記録したいファイルを選ぶ
`git commit`	選んだ変更をローカルリポジトリに記録する
`git push`	コミットをリモートリポジトリに送る

git add でファイルを選ぶ段階を ステージング と呼びます。変更したファイルのうち、関係するものだけを選んで 1 つのコミットにまとめられます。

1-4. よく使うコマンド

記録と共有のほかに、日々の作業でよく使うコマンドがあります。

コマンド	内容
`git status`	変更されたファイルと、ステージングしたファイルを確認する
`git diff`	まだコミットしていない変更の内容を確認する
`git log`	コミットの履歴を確認する
`git commit --amend`	直前のコミットのメッセージや内容を修正する
`git restore <ファイル>`	ファイルの変更を取り消す

2. Git の設定ファイル

リポジトリには、コミットすべきでないファイルがあります。また、改行コードの違いで不要な差分が出ることもあります。これらを .gitignore と .gitattributes で整えます。

2-1. .gitignore

.gitignore は、コミットの対象から外すファイルを指定するファイルです。Spring Initializr で作ったプロジェクトのルートに、最初から含まれています。.gitignore に書いたパスは Git が追跡せず、コミットされません。生成された .gitignore には、主に次の行が並びます。

target/
.idea
*.iml
.vscode/

ビルドで生成される target/ や、メンバーごとに異なるエディターの設定は、共有する必要がありません。これらは Initializr が登録済みのため、自分で追記する必要はありません。

application.properties に書かれているのは、プロジェクトの準備のとおり、ローカルだけで使う MySQL の接続情報です。実害がないため、実行環境をチームで共有するための compose.yaml・init.sql とともにコミットします。外部に漏らせない秘密情報を含むファイルは、.gitignore に追記して共有から外します。

2-2. .gitattributes

改行コードには、行末を表す LF と CRLF の 2 種類があります。Windows では、Git が改行を CRLF に変換し、内容を変更していない行まで差分として現れることがあります。

.gitattributes に次の 1 行を書くと、リポジトリに記録する改行コードを LF にそろえられます。.gitattributes は、プロジェクトのルートに自分で作成します。

* text=auto eol=lf

3. リポジトリの共有

設定ファイルを整えたあと、プロジェクトを GitHub の共有リポジトリに置きます。最初のメンバーがリポジトリを作成し、ほかのメンバーがクローンします。

3-1. 事前準備

GitHub とやり取りする前に、各メンバーが自分の PC で一度だけ準備します。

1 つは、名前とメールアドレスの設定です。コミットには作成者の名前とメールアドレスが記録されるため、Git に設定します。

git config --global user.name "山田太郎"
git config --global user.email "yamada@example.com"

--global を付けた設定は、その PC のすべてのリポジトリで使われます。プロジェクトのファイルではないため、コミットには含まれません。

もう 1 つは、GitHub へのログインです。GitHub の公式ツール GitHub CLI（gh）を使い、画面の案内に従ってサインインします。

gh auth login

3-2. 最初のコミットとプッシュ

プロジェクトの準備でプロジェクトを作成したメンバーが、Git の管理を始め、GitHub に送ります。

プロジェクトをコミットする

プロジェクトのルートで Git の管理を始め、最初のコミットを作ります。
Terminal window
```
git init
git add .
git commit -m "プロジェクトの雛形を追加"
git branch -M main
```
git add . で、.gitignore に書いたパスを除く全ファイルを選び、git commit で記録します。git branch -M main は、最初のブランチ名を main に変更します（ブランチはブランチとプルリクエストで扱います）。
GitHub に作成してプッシュする

gh を使うと、GitHub のリポジトリ作成からプッシュまでを 1 つのコマンドで行えます。
Terminal window
```
gh repo create --private --source=. --push
```
このコマンドは、--private で非公開のリポジトリを GitHub に作成し、--source=. で現在のフォルダーのローカルリポジトリにリモート origin を登録し、--push で main をプッシュします。リポジトリ名にはフォルダー名が使われます。origin は、リモートを指す既定の名前です。

作成したリポジトリは非公開のため、このままではほかのメンバーがアクセスできません。作成者は、GitHub のリポジトリの Settings → Collaborators から、チームのメンバーを コラボレーター（collaborator）として追加します。追加されたメンバーだけが、クローンとプッシュを行えます。

3-3. コミットメッセージ

コミットには、その変更を要約したメッセージを付けます。1 つのコミットは 1 つのまとまった変更にとどめ、区切りごとにコミットします。変更が大きすぎると、1 つのコミットに複数の目的が混ざり、履歴から意図を読み取れなくなります。

チームでは、メッセージの先頭に変更の種別を付ける書き方が広く使われます。

種別: 変更内容の要約

feat: 質問の投稿機能を追加
fix: 投票が二重に登録される不具合を修正
chore: .gitattributes を追加

主な種別は、次のとおりです。

種別	使う場面
feat	機能を追加する
fix	不具合を修正する
docs	ドキュメントを変更する
refactor	動作を変えずにコードを整理する
chore	設定など、機能以外を変更する

種別をそろえると、誰が書いても表記が統一され、履歴から変更の種類を見分けられます。

3-4. クローン

ほかのメンバーは、自分の PC でこのプロジェクトを開発するために、GitHub の共有リポジトリを複製します。この操作を クローン と呼びます。

クローンに使う URL は、GitHub のリポジトリページの Code ボタンから取得します。次のコマンドを実行すると、現在のフォルダーの中に、リポジトリ名のフォルダーが作られます。

git clone <リモートリポジトリの URL>

作られたフォルダーには、compose.yaml や init.sql を含むプロジェクト一式が、コミット履歴とともに複製されます。このフォルダーを VS Code で開いて作業します。

クローンしたメンバーも、コミットやプッシュには事前準備が必要です。プロジェクトを動かすには、プロジェクトの準備の README に従って MySQL を起動し、アプリケーションを Run で起動します。

クローンを終えると、チーム全員が同じプロジェクトで作業を始められます。main を安定させたまま並行して開発する方法は、ブランチとプルリクエストで扱います。