Git
よみ: ギット
プログラムのソースコードの「変更履歴」を記録・追跡し、複数人での安全な協働開発を可能にする「分散型バージョン管理システム」です。現在の Web・ソフトウェア開発において、世界的な事実上の標準(デファクトスタンダード)ツールとなっています。
非エンジニアが覚えるべき「5 つの基本用語」
コードを書かない Web 担当者でも、以下の用語を知っておくだけでエンジニアや制作会社との会話が劇的にスムーズになります。
| 用語 | エンジニア側の意味 | 担当者向けの分かりやすい翻訳 |
|---|---|---|
| リポジトリ | ファイルや履歴の保管場所 | プロジェクトの「大きな保管庫」 |
| コミット | 変更履歴の記録 | 変更内容の「セーブデータを作る」こと |
| ブランチ | 履歴の分岐 | 本番に影響を与えない「作業用の分身」 |
| マージ | 分岐した履歴の統合 | 作業した分身(ブランチ)を「本流に合体させる」こと |
| プルリク(プルリクエスト) | マージの依頼 | 「作業が終わったから、確認して合体させて」という依頼 |
実務における重要性(ベンダーマネジメント)
Web サイトの障害時やバグ発生時に、「いつ、誰が、どこを変更したか」を瞬時に特定し、安全に前の状態に「切り戻す(復元する)」ための生命線となります。
絶対に避けるべき落とし穴(注意点)
- 新規の制作会社を選定する際、「Git ベースの開発体制かどうか」の確認を怠る。
- 業者が Git を使わず、手作業で「index_最新_修正版2.html」のようなアナログなファイル管理をしており、先祖返り(修正したはずのバグが元に戻ってしまうこと)や、障害時の復旧不能などの大事故を引き起こす。
言葉をよく利用する人
- コーダー / フロントエンドエンジニア
- バックエンドエンジニア
- Web 担当者(発注側)
- 情シス
会話上での使用例
新規業者の開発体制を選定時に確認する場面
-
営業
弊社の開発体制について、ご説明させていただきます。
-
Web担当者
Gitベースで開発されている前提でよろしいですか。GitHubかGitLabか、それからリポジトリの所有権がどうなるかも教えてください。
-
営業
はい、Gitで管理しております。所有権の件も持ち帰って整理します。
本番障害から切り戻したい情シスと対応を相談する場面
-
情シス
本番でエラーが出ていて、できれば元に戻したいんです。
-
Web担当者
Gitでコードを管理しているなら、直前のコミットへの切り戻しは数分で済みます。すぐ業者に連絡しましょう。
-
情シス
では戻せる前提で、急いで連絡を入れます。