Git（バージョン管理）とは
Gitとは、プログラムのソースコードなどのファイルについて、「いつ、誰が、何を、なぜ変えたか」という変更履歴を記録し、過去の状態に戻したり、複数人が同時に別々の作業を進めて後で合わせたりできるようにする、バージョン管理のためのソフトウェアです。
平易に言えば「ファイルの変更をすべて記録してくれる、高機能なタイムマシン付きの保管庫」です。「最終版」「最終版_修正」「最終版_本当の最終」といったファイル名で管理する必要がなくなり、どの時点の状態にも戻れます。
「ギット」と読みます。もともとはLinuxというOSの開発のために作られたもので、現在ではソフトウェア開発のほぼ標準の道具になっています。
仕組み・ポイント
Gitを理解するうえで押さえておきたい用語は次のとおりです。
| 用語 | 意味 |
|---|---|
| リポジトリ | ファイルと変更履歴をまとめて保管する場所 |
| コミット | 変更をひとまとまりとして記録すること。メッセージで理由を残す |
| ブランチ | 本流から分かれて、別の作業を並行して進めるための枝 |
| マージ | 別のブランチで行った変更を本流に合流させること |
| プルリクエスト（マージリクエスト） | 変更を本流に合流させる前に、他の人に確認を依頼する仕組み |
Gitは「分散型」と呼ばれ、開発者一人ひとりのパソコンに履歴を含むリポジトリの完全な複製を持ちます。そのうえで、チームで共有するための中央のリポジトリをインターネット上に置くのが一般的です。
よく混同されるのが、GitとGitHubの違いです。Gitは履歴管理の仕組みそのもので、GitHub、GitLab、Bitbucketなどは、Gitのリポジトリをインターネット上で共有・管理するためのサービスです。これらのサービスには、コードレビュー、課題管理、テストやデプロイの自動実行といった、チーム開発を支える機能が備わっています。
実務での使い方・具体例
ある会社が開発会社にWebサービスの開発を依頼している場面を考えます。複数の開発者が、新機能の追加と不具合の修正を同時に進めています。
Gitを使った典型的な進め方は次のとおりです。
- 開発者は作業ごとにブランチを作る（例：「予約キャンセル機能の追加」）
- 作業の区切りごとにコミットし、変更の理由を書き残す
- 作業が終わったらプルリクエストを出し、別の開発者が内容を確認する
- 自動テストに通り、確認が済んだら本流にマージする
- 本流の内容をデプロイして各環境に反映する
ブランチを使えば、たとえば「来月公開予定の大きな機能」を開発している最中に本番で緊急の不具合が見つかっても、本流から別のブランチを切って修正だけを先に反映できます。作業途中の機能が誤って公開される心配はありません。
不具合が見つかったときは、履歴をたどって「どの変更から問題が起きたか」を特定できます。必要なら、その変更だけを取り消すこともできます。
発注側が押さえておきたいこと
発注側にとってGitは、開発の透明性と資産の保全に直結します。次の点を契約や開発開始時に確認しておくと安心です。
- リポジトリは誰のアカウントで作るか（発注側の組織で持つのが望ましい場合が多い）
- 発注側の担当者もリポジトリを閲覧できるか
- 開発会社が替わったときに、履歴ごと引き継げるか
- コミットのメッセージやプルリクエストに、変更の理由が残される運用か
リポジトリが開発会社の個人アカウントにしかない状態だと、契約終了時にソースコードの受け渡しで困ることがあります。権利の帰属と合わせて、保管場所も最初に決めておきます。
よくある誤解と注意点
- Gitはエンジニアだけのもの、ではない：仕様書やインフラの設定（IaC）、ドキュメントの管理にも使えます。発注側が閲覧できるだけでも、進捗や変更の把握に役立ちます。
- パスワードや秘密鍵をコミットしてしまう：一度コミットした情報は履歴に残り、削除しても過去の記録から読めることがあります。秘密情報はリポジトリに入れない運用を徹底します。
- ブランチが乱立する：長期間マージされないブランチが増えると、合流時の衝突が大きくなります。小さな単位で頻繁に合流させます。
- バックアップの代わりにはならない：リポジトリを置くサービスにもアカウント停止や誤削除のリスクはあります。重要なリポジトリは別の場所にも複製しておくと安心です。
関連用語
- コードレビュー：プルリクエストを通じて変更を確認する活動
- デプロイ：Gitで管理したコードを環境に反映する作業
- ソースコード：Gitで管理される主な対象
- テスト自動化：コミットやプルリクエストのたびにテストを自動で実行する仕組み
- 実践記事：ソースコードの著作権は誰のものか：納品物と権利帰属の決め方
Otsumuに相談できること
開発会社に任せきりで、ソースコードの所在や変更履歴が見えない状態を改善したい、内製化に向けて開発の進め方を整えたい、といったご相談に対応しています。リポジトリの管理方法から、レビューとデプロイの流れまで、チームの規模に合わせて設計します。詳しくはシステム開発をご覧ください。
30分の無料相談で、現在の開発体制を伺います。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01