実務で Git を使う上で、最低限ここだけ抑えておけば困らないという部分に絞って解説します。
Git の基本と実務でのイメージ
Git を使う上で重要な概念を説明します。
リポジトリ (Repository)
プロジェクトのファイルや変更履歴をまとめて保管する場所です。
- ローカルリポジトリ: あなたのPC内にあるリポジトリ (個人用)
- リモートリポジトリ: ネットワーク上 (GitHub, GitLabなど) にあるリポジトリ (チーム共有用)
コミット (Commit)
ファイルの状態を記録する「スナップショット」です。
- 変更内容をまとめてコミットすることで、後から変更履歴を追跡できます。
- 各コミットには、変更理由を記述する「コミットメッセージ」を付与します (重要！)
ブランチ (Branch)
開発の流れを分岐させる機能です。
- main (または master) ブランチ: 製品版としてリリースする安定版のコードを管理する (基幹となるブランチ)
- feature ブランチ: 新機能開発や機能修正など、目的ごとに作成するブランチ
- ブランチを分けることで、複数人が同時に開発を進めやすくなります。
- merge (マージ): feature ブランチで行った変更を main ブランチなどに取り込む操作
ワークツリー (作業ディレクトリ)
実際にファイルを編集する場所 (PC上のフォルダ)
- ローカルリポジトリと紐づいています。
実務でのイメージ
チームで開発する場合、リモートリポジトリ (GitHubなど) を共有します。
- リモートリポジトリをローカルリポジトリにコピー (clone)
- feature ブランチ を作成して、新機能開発や修正を行う
- 変更をコミットしてローカルリポジトリに記録
- リモートリポジトリにコミットを反映 (push)
- Pull Request (プルリクエスト) を作成して、チームメンバーにレビューを依頼
- レビュー後、main ブランチ に merge (マージ) して変更を統合
Git の基本操作 (コマンド)
実務でよく使う Git コマンドを、具体的な操作手順と合わせて解説します。
1. リポジトリの準備
新規リポジトリ作成 (git init)
mkdir my-project
cd my-project
git init
-
git initを実行したディレクトリが Git リポジトリになります。 -
.gitという隠しフォルダが作成され、変更履歴などの情報が保存されます。
リモートリポジトリからコピー (git clone)
git clone <リモートリポジトリのURL>
cd my-project
- GitHubなどのリモートリポジトリから、コードをローカルPCにコピーします。
- 実務では
cloneから始めるケースがほとんどです。
2. ファイルの変更を記録 (add, commit)
# ファイルを編集 (例: index.html を編集)
vi index.html
# 変更したファイルを Git の管理対象に追加 (ステージング)
git add index.html
# コミットとして変更履歴を確定
git commit -m "feat: トップページにヘッダーを追加"
-
git add <ファイル名>: 変更をステージングエリアに追加します。「コミット対象だよ」と Git に伝える操作です。 -
git add .とすると、カレントディレクトリ以下の全ての変更をステージングできます。 -
git commit -m "コミットメッセージ": ステージングされた変更をコミットとして記録します。-
-m "コミットメッセージ"は必須です。変更内容がわかるように具体的に記述しましょう。 - コミットメッセージの書き方は後述します (ベストプラクティス)
-
3. ブランチ操作 (branch, checkout)
# ブランチの一覧を表示
git branch
# 新しいブランチを作成 (例: feature/header)
git branch feature/header
# ブランチを切り替え (feature/header ブランチに移動)
git checkout feature/header
# ブランチ作成と切り替えを同時に行う (checkout -b)
git checkout -b feature/login-form
-
git branch: ブランチの一覧を表示します。*がついているブランチが現在作業中のブランチです。 -
git branch <ブランチ名>: 新しいブランチを作成します。 -
git checkout <ブランチ名>: 指定したブランチに切り替えます (作業ブランチを変更)。 -
git checkout -b <ブランチ名>: ブランチ作成と同時に切り替えを行います。
4. リモートリポジトリとの連携 (pull, push)
# リモートリポジトリの変更をローカルに取り込む
git pull origin main # main ブランチの変更を取り込む場合
# ローカルの変更をリモートリポジトリに反映
git push origin feature/header # feature/header ブランチをpushする場合
-
git pull origin <ブランチ名>: リモートリポジトリの変更をローカルリポジトリに取り込み (ダウンロード)、現在のブランチにマージします。-
originは通常、リモートリポジトリの名前です。 -
git pullは実務で頻繁に使います。作業前に必ず実行して、リモートの最新状態を取得しましょう。
-
-
git push origin <ブランチ名>: ローカルリポジトリの変更をリモートリポジトリに反映 (アップロード) します。- 自分が作成したブランチ (feature ブランチなど) をリモートリポジトリに公開する場合などに使います。
5. 変更履歴の確認 (status, log)
# ファイルの状態を確認
git status
# コミット履歴を表示
git log
-
git status: ワークツリーの状態を表示します。- 変更されたファイル、ステージングされているファイル、コミットされていない変更などを確認できます。
-
git statusは迷ったらとりあえず実行すると良いでしょう。現在の状況を把握できます。
-
git log: コミット履歴を表示します。- 過去のコミットメッセージや変更内容を確認できます。
-
git log --onelineとすると、コミット履歴を一行で簡潔に表示できます。
6. コンフリクトの解消 (merge)
# ブランチをマージ (例: feature/header ブランチを main ブランチにマージ)
git checkout main
git merge feature/header
-
git merge <ブランチ名>: 指定したブランチの変更を現在のブランチにマージします。 - コンフリクト (conflict): マージ時に、同じファイルの同じ箇所が異なる内容に変更されている場合に発生します。
- コンフリクトが発生した場合は、手動でファイルを修正し、不要な記述を削除してから再度コミットします。
- コンフリクト解消後のコミットは、
git addとgit commitを実行します。
Git ベストプラクティス
Git を効率よく、チームで円滑に使うためのベストプラクティスを紹介します。
コミットは頻繁に、小さくまとめる
- 機能単位、修正単位など、意味のあるまとまりでコミットしましょう。
- 細かくコミットすることで、変更履歴が追いやすくなり、問題発生時の切り戻し (
revert) も容易になります。 - 「とりあえず動いたからまとめてコミット」はNG。
コミットメッセージをしっかり書く
- 「何を変更したのか」「なぜ変更したのか」 を明確に記述しましょう。
- 英語での記述が推奨されています (国際的な標準)
- コミットメッセージのテンプレートや書き方のルールをチームで統一すると、より分かりやすくなります。
例:
feat: ユーザーログイン機能を実装
ログインフォームを追加し、認証処理を実装しました。
セッション管理の仕組みも導入。
refs #123 (Issue #123 に関連するコミットであることを示す)
コミットメッセージのprefix (接頭辞) の例:
-
feat:新機能 -
fix:バグ修正 -
docs:ドキュメント変更 -
style:コードスタイル (インデント、フォーマットなど) の修正 (ロジック変更なし) -
refactor:リファクタリング (コードの内部構造の変更。機能変更なし) -
test:テストコードの追加、修正 -
chore:ビルド、設定ファイル、その他雑務
日本語でのコミットメッセージ例
feat: S3バケットをログ保存用に追加
- ログ保存用の S3 バケット "my-logs-bucket" を作成
- CloudFront ログ出力用のバケットポリシーを設定
- 90日後にログを削除するライフサイクルルールを追加
ブランチ戦略を決める
代表的なブランチ戦略:
-
Gitflow
-
GitHub Flow
-
GitLab Flow
-
プロジェクトやチーム規模に合わせて、適切なブランチ運用ルールを決めましょう。
-
最初はシンプルな運用から始めるのがおすすめです (例: GitHub Flow)。
-
feature ブランチ を積極的に活用し、main ブランチ は常に安定版を保つようにしましょう。
Pull Request (プルリクエスト) を活用する
- 変更を main ブランチ に取り込む前に、必ず Pull Request を作成しましょう。
- Pull Request は、コードレビュー、変更内容の議論、CI (継続的インテグレーション) の実行 などを行う場として活用します。
- 品質向上、知識共有、チームコミュニケーション に繋がります。
.gitignore を設定する
- Git の管理対象から除外するファイル、フォルダ を
.gitignoreファイルに記述します。
例:
node_modules/
*.log
tmp/
secrets.env
-
.gitignoreを適切に設定することで、リポジトリを綺麗に保ち、不要なファイルをコミットしてしまう事故を防ぎます。 -
.gitignoreの設定は、プロジェクト作成時に最初に行うべき作業の一つです。
定期的に git pull する
- 作業開始前、作業中も定期的に
git pullして、リモートリポジトリの最新の変更を取り込みましょう。 -
git pullしないまま作業を続けると、コンフリクトが発生しやすくなります。