GitHub
Git を基盤としたソースコードのホスティング / 共同開発プラットフォーム
GitHub とは
GitHub (ギットハブ) は、バージョン管理システム Git を基盤に、ソースコードの保管・公開・共同開発を支援するプラットフォームだ。世界中の開発者が利用しており、オープンソースソフトウェアの開発拠点としても、企業の開発基盤としても標準的な存在になっている。「コードを置く場所」にとどまらず、開発の流れ全体を支える機能を備えている。2018 年に Microsoft が買収したが、土台の Git はオープンソースのままで、リポジトリを履歴ごと他のホスティングサービスへ移せる構造は変わっていない。乗り換えで失われるのは Issue やプルリクエストの議論といった GitHub 側に蓄積したデータで、コードの履歴そのものではない。
Git と GitHub の違い
| Git | GitHub | |
|---|---|---|
| 正体 | バージョン管理の仕組み (ツール) | Git を使うクラウドサービス |
| 動作 | 手元の PC で完結する | チームで共有・連携する |
| 役割 | 変更履歴の記録 | 共同開発・公開・運用 |
混同されやすいが、Git が土台の技術で、GitHub はそれをチーム開発向けに拡張したサービスという関係になる。
主な機能
GitHub の機能は、リポジトリを中心に次の層で組み立てられている。
- リポジトリ: Git の履歴を置く器。公開 (public) と非公開 (private) を選べ、fork でリポジトリ全体を自分の名前空間へ複製できる
- プルリクエスト: あるブランチの変更を別のブランチへ取り込む提案。差分の行単位にコメントが付き、承認や自動チェックの結果が揃うまで merge を保留できる
- Issue: バグ報告や作業項目を議論として記録する場。プルリクエストから番号で参照すると、merge 時に自動で閉じられる
- GitHub Actions: push やプルリクエスト作成といったイベントを引き金に、GitHub 側の実行環境でテストやデプロイを走らせる仕組み
この組み合わせにより、複数人が同じコードベースを壊さずに並行開発し、変更を議論しながら統合していくワークフローが成立する。無料枠の有無や実行時間の上限はプランごとに変わるため、金額や上限値は必ず公式の料金ページで確認したい。
活用の勘所
GitHub の価値は単なる保管庫ではなく、変更をレビューし議論する文化を支える点にある。プルリクエスト単位で変更を小さく保つ、コミットメッセージで意図を残す、Issue で背景を記録する、といった運用がチームの生産性を左右する。一方、公開リポジトリに API キーやパスワードを誤ってコミットする事故は後を絶たない。ここで理解しておきたいのは、後からファイルを消して commit しても、鍵は過去の履歴に残り続けるという点だ。履歴の書き換えは共同作業者の手元と衝突するため、現実的な対処は「漏れた鍵を無効化して再発行する」ことに尽きる。GitHub 側にも漏洩しやすい形式のトークンを検出する secret scanning や、push の時点で止める push protection が用意されているが、検出できるのは既知のパターンだけなので、自前の設定値まで守ってくれるわけではない。
設定ファイルは環境変数や外部の秘密管理へ寄せ、リポジトリには「置かない」状態を既定にしておくのが安全側の運用になる。
この記事は役に立ちましたか?
関連用語
関連する記事
技術書の読書ログを GitHub で管理する - エンジニアらしい記録法
技術書の読書記録を GitHub リポジトリで管理する方法を紹介します。Markdown で読書ノートを書き、コミット履歴で読書の軌跡を残す、エンジニアならではの読書ログ術です。
「それ、本に書いてあったよ」が最高の褒め言葉になる職場
チーム全員が技術書を読む文化がある職場では、議論の質とコードの質が変わります。読書文化を持つチームの特徴と、その文化を育てるための具体的な方法を紹介します。
エンジニアが最初に読むべき技術書 5 冊の選び方 - ジャンル配分が鍵
新人エンジニアやキャリアチェンジ組が最初に読むべき技術書のジャンル配分と、言語 / 設計 / 運用 / CS 基礎 / ソフトスキルの 5 冊を選ぶチェックリストを紹介。