女性向けエンジニアスクール
3秒でわかる
ファイルの変更履歴を記録し、過去の状態へ戻したり複数人の編集を安全に合流させたりできる分散型のバージョン管理ツール。開発の基本装備です。
30秒図解
もう少し詳しく
どういうものか
Git は、ファイルの変更履歴を記録するバージョン管理ツールです。区切りのよいところで commit すると、その時点のプロジェクト全体の状態が履歴として保存され、いつでもそこへ戻せます。分散型と呼ばれるのは、履歴の全体が各自の手元に丸ごと複製されるからで、中央のサーバーに接続できなくても履歴を見たりコミットしたりできます。
基本の流れは3段階です。編集する場所であるワーキングツリー、記録する分を選ぶステージ、確定した履歴が積まれるリポジトリの順に進みます。
なぜ必要か
main_最終_v2_修正版.js のようなファイル名で履歴を管理すると、どれが最新か分からなくなり、どこを変えたのかも追えません。Git は各コミットに変更内容と説明文と日時と作者を残すので、「この行はいつ誰がなぜ変えたのか」を後から調べられます。
もうひとつの大きな利点がブランチです。作業ごとに履歴を枝分かれさせられるので、新機能を作りかけたまま緊急の不具合修正へ切り替え、終わったら戻る、という進め方ができます。同じファイルを複数人が同時に触っても、Git が差分を照合して合流させます。
具体例
git init # このフォルダを管理下に置く
git add index.html style.css # 記録する分を選ぶ
git commit -m "トップページの見出しを追加"
git switch -c feature/login # 作業用のブランチを作って移る
git switch main # 元に戻る
git <a href="/glossary/merge" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">merge</a> feature/login # 作業内容を合流させる
git log --oneline -5 # 直近5件の履歴を見る
git diff HEAD~1 # 1つ前のコミットとの差分コミットメッセージは、何をしたかが1行で分かる文にします。修正 だけでは、後から履歴を眺めても何も思い出せません。
つまずきやすいところ
コミットの粒度が最初の関門です。1日分の作業をまとめて1コミットにすると、後から一部だけ取り消せません。逆に1行ごとに区切ると履歴が読めなくなります。「この変更だけを取り消したくなるか」を基準に区切ると、ちょうどよい大きさになります。
コンフリクトを怖がって放置するのも典型的な失敗です。同じ行を両側で変えたときに Git が判断を保留し、<<<<<<< の印を残して人に選ばせます。これは異常ではなく仕様です。長く分岐させておくほど衝突は増えるので、こまめに合流させる方が楽になります。
.gitignore を作らずに始めると、node_modules や .env まで記録されます。とくに認証情報を一度コミットすると、後で消しても履歴に残り続けます。最初に除外設定を書きます。
似た用語との違い
Git はツールそのもので、GitHub はその履歴を預けて共同作業するためのサービスです。Git はインターネットに接続していなくても使えます。
