Git
Git とは
Git は、ソースコードの変更履歴を管理する 分散型バージョン管理システム である。2005 年に Linux カーネルの開発者である Linus Torvalds によって開発された。バージョン管理とは、「いつ・誰が・どのファイルを・どのように変更したか」を記録し、過去の状態への復元や変更の追跡を可能にする仕組みのことである。
現在のソフトウェア開発において Git は事実上の標準であり、GitHub・GitLab・Backlog Git といったホスティングサービスと組み合わせてチーム開発に使われている。
なぜ SIer で重要か
SIer のプロジェクトでは、数人〜数十人のチームで同じソースコードを同時に編集する。バージョン管理がなければ「誰かの変更を上書きしてしまった」「どの時点のコードが本番環境にデプロイされたかわからない」といった事故が起きる。Git はこうした問題を防ぎ、チーム開発を安全に進めるための基盤である。
プロジェクトに参加したらまず git clone でソースコードを取得するところから始まるため、Git の基本操作は新入社員が最初に身につけるべきスキルの一つである。
基本概念
リポジトリ・コミット・ブランチ・マージ
| 用語 | 説明 |
|---|---|
| リポジトリ(Repository) | ファイルの変更履歴をすべて保存する場所。ローカルとリモートの 2 種類がある |
| コミット(Commit) | ファイルの変更内容をリポジトリに記録する操作。スナップショットとして保存される |
| ブランチ(Branch) | 開発の流れを分岐させる仕組み。本線に影響を与えずに作業できる |
| マージ(Merge) | 分岐したブランチの変更を別のブランチに統合する操作 |
Git のワークフロー
Git では、ファイルの変更が以下の 4 つの場所を順に移動する。
┌──────────────┐ git add ┌──────────────┐ git commit ┌──────────────────┐ git push ┌──────────────────┐
│ 作業ディレクトリ │ ──────────→ │ ステージング │ ────────────→ │ ローカルリポジトリ │ ──────────→ │ リモートリポジトリ │
│ (Working Dir) │ │ (Staging) │ │ (Local Repo) │ │ (Remote Repo) │
└──────────────┘ └──────────────┘ └──────────────────┘ └──────────────────┘
← ──────────
git pull
- 作業ディレクトリ --- ファイルを編集する場所
- ステージング --- コミット対象として選択されたファイルの一時置き場(
git addで追加) - ローカルリポジトリ --- 自分の PC 上の履歴データベース(
git commitで記録) - リモートリポジトリ --- GitHub 等のサーバー上の共有リポジトリ(
git pushで送信、git pullで取得)
基本操作
| コマンド | 説明 |
|---|---|
git init | 新しいリポジトリを作成する |
git clone <URL> | リモートリポジトリをローカルに複製する |
git add <ファイル> | 変更をステージングに追加する |
git commit -m "メッセージ" | ステージングの内容をコミットする |
git push | ローカルのコミットをリモートに送信する |
git pull | リモートの変更をローカルに取り込む |
git branch <ブランチ名> | 新しいブランチを作成する |
git merge <ブランチ名> | 指定ブランチの変更を現在のブランチに統合する |
git log | コミット履歴を表示する |
git diff | ファイルの変更差分を表示する |
ブランチ戦略の基礎
チーム開発では、ブランチを使って作業を分離し、レビュー後に統合するのが一般的である。基本的な戦略は以下の通りである。
main(本番用)
└── develop(開発用)
├── feature/login(機能A の開発)
├── feature/search(機能B の開発)
└── feature/report(機能C の開発)
- main ブランチ --- 本番環境にデプロイされるコード。直接コミットせず、develop からのマージのみ受け付ける
- develop ブランチ --- 開発中の最新コードが集まるブランチ
- feature ブランチ --- 各機能の開発を行うブランチ。作業完了後に develop へマージする
SIer での使われ方
SVN(Subversion)との併存
SIer の現場では、Git だけでなく SVN(Subversion) も現役で使われている。SVN は 2000 年に登場した 集中型バージョン管理システム で、サーバー上の 1 つのリポジトリを全員が直接操作する方式である。
| 観点 | Git(分散型) | SVN(集中型) |
|---|---|---|
| リポジトリの構成 | 各開発者がローカルに完全なリポジトリを持つ | サーバー上に 1 つのリポジトリ |
| オフライン作業 | ローカルでコミット・履歴参照が可能 | サーバー接続が必須 |
| ブランチ操作 | 高速で軽量 | 比較的重い |
| 学習コスト | やや高い(ステージング等の概念) | 低い(操作がシンプル) |
| SIer での普及度 | 増加傾向 | レガシー案件で根強い |
SVN が残っている理由
- レガシーシステムの保守: 長年 SVN で管理してきた大規模プロジェクトでは、移行のリスクとコストが大きい
- 移行コスト: リポジトリの移行作業に加え、CI/CD パイプラインや運用手順書の改訂も必要
- 学習コスト: チームメンバー全員が Git を習得する必要があり、教育コストがかかる
Git への移行の流れ
近年は GitHub、GitLab、Backlog Git の普及により、新規プロジェクトでは Git を採用するケースが増えている。既存プロジェクトでも段階的に SVN から Git への移行を進める現場が多い。
まとめ
- Git はソースコードの変更履歴を管理する分散型バージョン管理システムである
- 作業ディレクトリ → ステージング → ローカルリポジトリ → リモートリポジトリの流れでファイルの変更を管理する
- ブランチを使って作業を分離し、マージで統合するのがチーム開発の基本である
- SIer の現場では SVN も現役だが、Git への移行が着実に進んでいる
- プロジェクトに参加したら、まずバージョン管理の運用ルール(ブランチ戦略、コミットメッセージ規約等)を確認することが重要である