GitHubという名前は聞いたことがあっても、「結局、何をするサイトなの？」と聞かれると答えに困る人は多いはずだ。
プログラマーが黒い画面で何か危険そうなことをしている場所。コードを無料で公開する場所。そんな印象を持っている人もいるだろう。
しかし、それだけではかなりもったいない。
GitHubは簡単に言えば、ファイルの変更履歴を残しながら、開発や共同作業を進めるためのサービスである。しかも単なる保存場所ではない。変更前に戻したり、別の機能を安全に試したり、他人の変更を確認してから採用したり、Webサイトを公開したり、自動でテストやデプロイまで実行できる。
私ならGitHubを「プログラムを置くクラウド」とだけ説明することはない。
むしろ、開発のセーブデータ、作業場、相談場所、自動化装置をまとめたサービスと考えたほうが理解しやすい。
では、普通のGoogle DriveやDropboxとは何が違うのか。そしてGitという名前まで出てくるのはなぜなのか。
ここがGitHubを理解する最大のポイントだ。
GitHubとは何？
GitHubは、Gitという仕組みを利用してソースコードやファイルを管理できるオンラインサービスである。
GitHub公式では、リポジトリについて「コード、ファイル、それぞれの変更履歴を含むもの」と説明している。つまり現在のファイルだけではなく、そこに至るまでの変更も管理できるのが大きな特徴だ。
GitHub公式「Repositories documentation」
たとえば自分でWebアプリを作っているとしよう。
昨日までは正常に動いていたのに、今日コードを書き換えたら突然動かなくなった。
普通のファイル管理なら、
「どこを直したっけ？」
となる。
そして最終的には、
- app.php
- app2.php
- app_new.php
- app_new2.php
- app_最終.php
- app_最終本当.php
という、人類が何度も繰り返してきた悲しいファイル管理が始まる。
GitHubとGitを使えば、こうした管理をかなり減らせる。
変更した場所と変更した時点を記録できるため、「昨日の正常だった状態」に戻したり、「この機能を追加したときに問題が起きた」と調べたりできるのだ。
GitHubはコード専用の保存場所ではない
GitHubではプログラムだけでなく、文章、設定ファイル、画像などもリポジトリに入れられる。
ただし、何でも入れればよいわけではない。
Gitは特に、プログラムやMarkdownなどのテキストファイルの変更管理を得意としている。
そのためGitHubは、
- プログラム
- Webサイト
- アプリ
- 設定ファイル
- 技術資料
- Markdownで書いた文章
などとの相性が非常に良い。
一方、大量の写真や動画を保存するだけなら、Google Driveなどのクラウドストレージを使ったほうがわかりやすい。
GitHubは「何でも入れる倉庫」ではない。
変更しながら育てていくデータを管理する場所と考えると理解しやすい。
GitHubとGitの違いは？
ここが初心者にとって最もややこしい。
GitとGitHubは別物である。
Gitは変更履歴を管理する仕組み
Gitは「バージョン管理システム」と呼ばれるソフトウェアだ。
ファイルを変更するたびに状態を記録し、「誰が」「いつ」「何を変更したのか」を管理できる。
Gitは分散型バージョン管理システムなので、基本的には自分のパソコンにもリポジトリと履歴を持つことができる。Git公式の解説でも、分散型ではクライアント側にリポジトリの履歴まで複製される仕組みが説明されている。
つまりGitだけでも変更履歴の管理はできる。
GitHubがなければGitが使えない、というわけではない。
GitHubはGitをオンラインで使いやすくしたサービス
ではGitHubは何をするのか。
GitHub上にリポジトリを置けば、
自分のパソコン
↓
GitHub
↓
別のパソコン
という形でコードを共有できる。
さらに複数人で同じプロジェクトを開発したり、他人が作ったプログラムを閲覧したり、変更内容を話し合ったりできる。
かなり乱暴に言えば、
Gitがセーブ機能で、GitHubがそのセーブデータを共有できるオンライン拠点
くらいに考えると最初は十分だ。
GitHubはどういう仕組み？
GitHubを理解するには、専門用語を全部暗記する必要はない。
まず、
Repository → Commit → Branch → Pull Request → Merge
という流れだけ覚えておけばよい。
GitHub公式の初心者向けチュートリアルでも、リポジトリを作り、ブランチを作成し、コミットし、Pull Requestを作成してマージする流れが基本として紹介されている。
Repository（リポジトリ）はプロジェクトの箱
リポジトリは、プロジェクトに必要なファイルと変更履歴をまとめて管理する場所だ。
たとえば「家計簿アプリ」を作るなら、
kakeibo-app
のようなリポジトリを作る。
その中にHTML、CSS、JavaScript、PHPなどのファイルを入れて管理していく。
普通のフォルダと似ているが、リポジトリには変更履歴まで残せるところが大きく違う。
Commit（コミット）はセーブポイント
コミットは、その時点の変更を記録する操作である。
GitHub公式では、コミットは1つ以上のファイルに加えた変更を記録するものと説明されている。各コミットには識別用のSHAと呼ばれる値も付く。
たとえば、
「ログイン機能を追加」
「文字サイズを修正」
「決済画面の不具合を修正」
という単位でコミットしておけば、何をしたのか後から追いやすい。
ゲームでいうセーブポイントにかなり近い。
ただし「今日はかなり作業した」などという雑なコミットを連発すると、未来の自分が困る。
記録は未来の自分への手紙だと思ったほうがいい。
Branch（ブランチ）は別ルートを作る機能
新しい機能を試したい。
しかし、現在正常に動いているプログラムは壊したくない。
そこで使うのがブランチだ。
たとえば、
main
という完成版のブランチから、
new-login
という別ブランチを作る。
そこでログイン機能を開発すれば、main側を直接壊さずに作業できる。
GitHub公式も、ブランチを使えばメインのコードに影響を与えず、新機能の開発や実験ができると説明している。
これはかなり重要だ。
私はGitHubの便利さを理解するなら、まずブランチを理解するのが近道だと思っている。
Pull Requestは「この変更を入れていい？」という申請
別ブランチで開発が終わった。
そこで、
「この変更をmainに追加したい」
と提案するのがPull Request、略してPRである。
Pull Requestでは、変更されたコードを確認し、コメントしたりレビューしたりできる。
GitHub自身もPull Requestを、変更を提案し、話し合い、マージするための中心的な共同作業機能としている。
一人開発でもPull Requestは使える。
変更内容を確認してから本番側へ入れる癖をつけられるので、私は個人開発でもかなり有効な仕組みだと思う。
Merge（マージ）で変更を統合する
Pull Requestを確認して問題がなければ、変更したブランチをmainなどのブランチへ統合する。
これがマージだ。
つまり基本の流れは、
- リポジトリを作る
- ブランチを作る
- ファイルを変更する
- コミットする
- Pull Requestを作る
- 内容を確認する
- マージする
となる。
これだけ理解できれば、GitHubの仕組みはかなり見えてくる。
Clone・Push・Pullとは？
GitHubを使い始めると、さらにClone、Push、Pullという単語が出てくる。
ここも難しく考える必要はない。
CloneはGitHubから自分のPCへコピーする
GitHub上にあるリポジトリを、自分のパソコンへ複製するのがCloneだ。
他人が公開しているプロジェクトや、自分が別PCで作ったプロジェクトを手元へ持ってくるときに使う。
Pushは自分の変更をGitHubへ送る
パソコン側でコードを書いてコミットしただけでは、その変更は自分のパソコンにある。
GitHubへ送る操作がPushだ。
イメージとしては、
PC → GitHub
である。
PullはGitHub側の変更を受け取る
反対にGitHub側に新しい変更がある場合、それを自分のパソコンへ持ってくるのがPullだ。
GitHub → PC
となる。
複数のパソコンや複数人で作業すると、このPushとPullを頻繁に使うことになる。
GitHubは何に使える？
GitHubの用途はコード保存だけではない。
ここが意外と面白いところだ。
アプリやWebサービスの開発
最も代表的なのはプログラム開発だ。
HTML、CSS、JavaScript、PHP、Pythonなどのコードを保存し、変更履歴を管理できる。
個人開発でも、
「昨日までは動いていたのに今日壊れた」
という事故は普通に起きる。
Gitを使って履歴を細かく残していれば、どの変更から問題が起きたのかを調べやすい。
AIにコードを書かせる時代になった今こそ、この履歴管理はむしろ重要になっている。
AIが100行直してくれた。
そして動かなくなった。
実に現代らしい事故だ。
だからこそ、変更前へ戻れる仕組みは強い。
複数人での共同開発
GitHubはチーム開発との相性が非常に良い。
それぞれがブランチで作業し、Pull Requestで変更を提出し、レビューしてからmainへ入れる。
誰かが直接完成版を書き換えるよりはるかに安全だ。
さらに、「なぜこのコードになったのか」という話し合いまで記録として残せる。
単純なファイル共有サービスとの大きな違いはここにある。
Issueでバグや作業を管理する
GitHubにはIssuesという機能もある。
Issuesでは、
- バグ
- 新機能
- アイデア
- やること
- 改善要求
などを登録できる。
GitHub公式でもIssuesは、アイデア、フィードバック、タスク、バグなどを追跡するための機能として説明されている。
個人開発でも、
「ログイン画面を修正する」
「スマホ表示を改善する」
「Googleカレンダー同期を追加する」
といった作業をIssueにしておけば、簡単なタスク管理ツールとして使える。
さらにGitHub Projectsを使えば、IssueやPull Requestを表、ボード、ロードマップ形式などで管理できる。
GitHub Actionsで作業を自動化する
GitHub Actionsを使えば、コードの変更をきっかけに処理を自動実行できる。
たとえば、
「mainへPushされたらテストする」
「Pull Requestが作られたらチェックする」
「マージされたらサーバーへ公開する」
といった処理だ。
GitHub Actionsは公式にも、ビルド、テスト、デプロイなどを自動化できるCI/CDプラットフォームとして説明されている。
GitHub公式「Quickstart for GitHub Actions」
個人開発でも使い道は多い。
毎回手作業でサーバーへファイルをアップロードする作業などを自動化できれば、ミスも手間も減らせる。
GitHub PagesでWebサイトを公開する
GitHub Pagesという機能を使えば、GitHubのリポジトリからWebサイトを公開できる。
GitHub公式では、リポジトリをWebサイトとして公開でき、別のホスティングを用意せず利用できる仕組みとして紹介されている。
GitHub公式「GitHub Pages documentation」
HTMLやCSSを勉強している初心者が、自分で作ったページを公開する用途にも向いている。
ただしPHPやMySQLをそのまま動かす一般的なレンタルサーバーとは役割が違う。
基本的には静的なWebサイト向けと考えたほうがよい。
オープンソースの開発に参加する
GitHubには世界中の公開プロジェクトが存在する。
公開リポジトリならコードを読んだり、Forkして自分用に変更したり、Pull Requestを出して改善を提案したりできる。
Forkは元のリポジトリとは別に自分側のリポジトリを作る仕組みで、書き込み権限がないプロジェクトへ変更を提案するときにも使われる。
GitHubが単なるオンラインストレージではなく、巨大な開発コミュニティでもある理由がここにある。
プログラマー以外でもGitHubは使える？
使える。
ただし、全員が使うべきとは思わない。
WordやExcelを置いておくだけならGoogle Driveなどのほうが簡単だ。
一方、
- Markdownで文章を書く
- 設定ファイルを管理する
- Webサイトを作る
- 技術資料を書く
- ファイルの変更履歴を細かく残したい
という人なら、プログラマーでなくてもGitHubを使う意味はある。
特に生成AIを使ってWebサイトやアプリを作る人は、GitHubを覚えておいたほうがいい。
コードを書けなくても、AIが変更したコードを安全に管理する必要は残るからだ。
むしろAIに大量のコードを書かせるからこそ、変更履歴が重要になる。
GitHub初心者は何から始めればいい？
最初からGitコマンドを30個暗記する必要はない。
そんなことをすると、GitHubを使う前にGitが嫌いになる。
最初は次の操作だけでよい。
1. GitHubアカウントを作る
まずGitHubのアカウントを作成する。
2. Repositoryを1つ作る
練習用のリポジトリを作る。
名前は、
hello-world
でも、
test
でも構わない。
3. README.mdを編集する
READMEは、そのリポジトリが何なのか説明するファイルだ。
文章を1行追加するだけでもよい。
4. Commitする
変更内容をコミットする。
ここで「変更を記録する」という感覚を覚える。
5. Branchを作る
mainとは別のブランチを作って、READMEを変更してみる。
6. Pull Requestを作ってMergeする
変更内容を確認し、mainへマージする。
GitHub公式にも、この一連の流れを体験できるHello Worldチュートリアルが用意されている。最初はこれで十分だ。
GitHubを使うときの注意点
便利なGitHubだが、一つだけ初心者が絶対に知っておきたい注意点がある。
パスワードやAPIキーをコードへ直接書いたままGitHubへPushしてはいけない。
APIキー、アクセストークン、パスワードなどがリポジトリに含まれると、不正利用される危険がある。
GitHubにもSecret scanningなどの検出機能が用意されているが、「検出してくれるから入れてよい」という話ではない。GitHub公式もハードコードされたAPIキーやパスワードなどを認証情報漏えいの危険として扱っている。
.envなどを使って重要な情報をコード本体から分離し、.gitignoreでGitの管理対象から外す方法などを覚えておくべきだ。
GitHubを使い始めるなら、ここだけは軽く考えないほうがいい。
GitHubは結局何が便利なの？
GitHubの強さは、単にコードを保存できることではない。
変更した履歴が残る。
別の機能を安全に開発できる。
他人の変更を確認できる。
バグやタスクを管理できる。
テストや公開作業まで自動化できる。
これらが、一つのプロジェクトにつながっている。
だからGitHubは世界中のソフトウェア開発で使われている。
「コードを置くサイト」とだけ覚えてしまうと、本当の便利さの半分も見えてこない。
まとめ
GitHubとは、Gitによるバージョン管理を利用して、コードやファイルをオンラインで管理・共有できるサービスだ。
Gitは変更履歴を管理する仕組み。
GitHubは、そのGitを使ったプロジェクトをオンライン上で共有し、開発や共同作業をしやすくする場所。
最初はこの違いだけ理解すればいい。
そして、
Repository → Branch → Commit → Pull Request → Merge
という基本の流れを一度実際に触ってみる。
ここまで来れば、GitHubはもう謎のプログラマー専用サイトではない。
特に個人でWebサイトやアプリを作るなら、GitHubは「使えたら便利」という程度ではなく、かなり早い段階で覚えておきたい道具だ。
コードは壊れる。
AIが直したコードも壊れる。
人間が「ここだけ少し直そう」と触ったコードは、なぜかもっと壊れる。
だからこそ、いつでも変更を確認でき、必要なら前の状態へ戻れる仕組みには大きな価値がある。
GitHubの本質はコードを保存することではない。
変更し続けても、プロジェクトを壊しにくくすることにある。
コメント