No history yet

リポジトリ管理の実践

リポジトリの作成と管理

Gitを使った開発を始めるには、まずリポジトリを用意する必要があります。方法は2つあり、状況に応じて使い分けます。

全く新しいプロジェクトを始める場合は、プロジェクトのディレクトリでgit initコマンドを実行します。これにより、そのディレクトリ内に.gitという隠しディレクトリが作成され、Gitが変更履歴を管理するためのすべての情報がそこに保存されます。これがローカルリポジトリの誕生です。

# 新しいプロジェクト用のディレクトリを作成
mkdir my-new-project
cd my-new-project

# Gitリポジトリとして初期化
git init

一方、すでに存在するプロジェクトに参加する場合はgit cloneを使います。このコマンドは、GitHubなどのリモートサーバー上にある既存のリポジトリを、履歴全体を含めて自分のマシンにコピーします。

# リモートリポジトリをローカルに複製
git clone https://github.com/example/existing-project.git
cd existing-project

git initはゼロからリポジトリを「作る」コマンド、git cloneは既存のリポジトリを「複製する」コマンドです。この違いを理解しておけば、プロジェクトの開始時に迷うことはありません。

不要なファイルを無視する

プロジェクトを進めると、バージョン管理に含めたくないファイルが出てきます。例えば、コンパイルされたファイル、ログファイル、OSが自動生成する設定ファイル(macOSの.DS_Storeなど)です。これらのファイルをGitの管理対象から外すために、.gitignoreファイルを使います。

.gitignoreは、プロジェクトのルートディレクトリに配置するテキストファイルで、追跡を無視したいファイルやディレクトリのパターンを記述します。ワイルドカード(*)も利用でき、特定の拡張子を持つファイルをまとめて無視することも可能です。

# OS固有のファイルを無視
.DS_Store

# ログファイルを無視
*.log

# ビルド成果物を格納するディレクトリを無視
/build/

# 環境変数ファイル(機密情報を含むことが多い)を無視
.env

このファイルを最初に適切に設定しておくことで、git add .のようなコマンドを使っても、不要なファイルが誤ってリポジトリに含まれるのを防げます。チームで開発する場合、全員が同じルールでファイルを無視できるため、履歴をクリーンに保つ上で非常に重要です。多くのフレームワークや言語には、推奨される.gitignoreのテンプレートが存在するので、それを基にカスタマイズするのが効率的です。

変更を記録するサイクル

Gitでの作業は、「変更 → ステージング → コミット」というサイクルを繰り返すのが基本です。ファイルを編集した後、いきなり保存するのではなく、一度「」と呼ばれる場所に送るのが特徴です。

現在のリポジトリの状態を確認するにはgit statusコマンドが役立ちます。このコマンドは、変更されたがまだステージングされていないファイル(Changes not staged for commit)、ステージング済みのファイル(Changes to be committed)、そして追跡されていない新しいファイル(Untracked files)を一覧で表示してくれます。

Lesson image

具体的にどのような変更が加えられたかを知りたい場合はgit diffを使います。引数なしで実行すると、作業ディレクトリ内での未ステージングの変更が表示されます。一方、ステージング済みの変更と前回のコミットとの差分を見たい場合はgit diff --staged(または--cached)を使います。

git diff: 作業ディレクトリ vs ステージングエリア git diff --staged: ステージングエリア vs 最新のコミット

変更内容に問題がなければ、git add <ファイル名>でステージングエリアに追加し、最後にgit commitでリポジトリに記録します。もし間違えてファイルをステージングしてしまった場合は、git reset HEAD <ファイル名>でステージングを取り消すことができます。

意味のある履歴を作る

コミットは単なる作業の保存ではありません。未来の自分や他のチームメンバーが「なぜこの変更が行われたのか」を理解するための重要なドキュメントです。そのため、一つ一つのコミットは、意味のある単位でまとめる「」を心がけるべきです。

例えば、「UIのバグを修正し、新しい機能を追加し、READMEを更新した」という3つの変更を1つのコミットにまとめるのは悪い習慣です。これらはそれぞれ独立したコミットとして記録するべきです。