たとえるなら
文書の「変更履歴付き共同編集」です。誰がいつどこを直したかが全部記録され、間違えても過去の版にすぐ戻れます。Gitがその記録帳で、GitHubは記録帳をチーム全員で共有する置き場所だと思ってください。
もう少しくわしく
Git（ギット）は、ソースコードの変更履歴を記録する道具です。「この日にこのファイルのこの行を、誰が、なぜ変えたか」がすべて記録され、いつでも過去の状態に戻せます。ソースコードは何百回も書き換えながら育てていくものなので、この記録があるかないかで安心感がまったく違います。変更を記録する操作を「コミット」と呼びます。
GitHub（ギットハブ）は、Gitで記録した履歴をインターネット上で共有するWebサービスです。チーム全員が同じ記録を見られるので、離れた場所にいても共同開発ができます。自分の変更を共有場所へ送ることを「プッシュ」、取り込んでほしいと依頼することを「プルリクエスト」、作業を枝分かれさせて本体を壊さずに進める仕組みを「ブランチ」と呼びます。
いちばん多い誤解は、GitとGitHubを同じものだと思うことです。Gitは手元のパソコンで動く道具、GitHubはその記録を置いて共有する場所で、GitHubを使わずGitだけで使うこともできます。もうひとつ、バックアップとも違います。バックアップは失ったときに戻すための控えですが、Gitは変更のひとつひとつを理由つきで残す記録なので、途中のどの時点にも戻れます。
日々の流れはおおむね決まっています。作業用のブランチを切り、手元で直してコミットし、GitHubへプッシュしてプルリクエストを出す。レビューで指摘をもらって直し、承認されたら本体に合流させる。この合流を合図に、テストやデプロイが自動で動く仕組みを組んでいる現場も多いです。1日の終わりに必ずプッシュするなど、細かい運用は現場によって違います。
新人がつまずきやすいのはコミットの粒度です。一日分の修正をまとめて一回で記録すると、あとから「どの変更が何のためだったか」を追えなくなります。意味のかたまりごとに分けるのが基本です。もうひとつは、他の人の変更を取り込まずに長く作業して、合流のときに大量の衝突（コンフリクト）を起こすこと。こまめに最新を取り込むほうが痛みは小さくて済みます。コミットの説明文を「修正」の一語で済ませるのも、後から読む人が困る書き方です。
働きはじめたばかりの人は、迷ったら消さずに聞くことを覚えておいてください。Gitの操作を間違えてもたいていは元に戻せますが、無理に取り消そうとして他の人の記録まで消してしまう事故が起こりがちです。エンジニアではない立場の人も、仕様書や原稿をGitHubで管理する現場があります。画面上でコメントを付けられるので、使い方を教わっておくと相談が早くなります。
GitHubには世界中の開発者が公開したソースコードが集まっており、技術者の名刺代わりとして見られることもあります。採用の場面で「GitHubを見せてください」と言われるのはこのためです。同じ用途のサービスにGitLabなどもあり、どれを使うかは会社の方針で決まります。道具が違っても、履歴を記録して共有するという考え方は共通です。
現場での使われ方
「その修正、もうプッシュしてもらえました？」
手元で直した変更を、チームの共有場所（GitHubなど）へ送ってくれたかという確認です。送るまでは他の人から見えないため、レビューもテストも始められない状態が続きます。
「コミットの履歴を見れば、いつ壊れたかわかるはず」
変更の記録をさかのぼれば、どの変更で不具合が入り込んだのか特定できるという調査方針です。履歴が意味のかたまりごとに分かれているほど、絞り込みは速く終わります。
「ブランチを切ってから作業してください」
本体のコードを直接いじらず、作業用の枝を作ってそこで進めてほしいという指示です。途中で失敗しても本体には影響しないため、思い切って試せるという安心につながります。
「コンフリクトしたので見てもらえますか」
同じ場所を複数人が直したため、どちらを採用するか自動では決められない状態です。どちらが正しいかは書いた本人にしか判断できないので、声がかかることになります。
よくある質問
GitとGitHubは何が違うのですか？
Gitは自分のパソコンで動く「履歴を記録する道具」、GitHubはその記録を「みんなで共有するためのWebサービス」です。Gitだけでも使えますが、チーム開発ではGitHubのような共有サービスと組み合わせるのが一般的です。似た役割のサービスにGitLabなどもあります。
Gitはバックアップの代わりになりますか？
役割が違います。Gitは変更の履歴を理由つきで残し、途中のどの時点にも戻せる記録の道具です。共有場所へ送っておけば結果として控えにもなりますが、消えたデータを丸ごと復旧する用途には、別にバックアップの仕組みを用意しておくのがふつうです。目的の違う道具だと覚えておいてください。
エンジニア以外もGitHubを使いますか？
使うことがあります。デザイナーや企画の担当者が仕様書や文書の管理に使う例もあり、変更履歴を残しながら共同作業する道具として職種を越えて広がっています。画面上でコメントのやりとりもできるため、確認や相談のお願いにも向いています。操作は教わればすぐ覚えられます。
操作を間違えたら元に戻せますか？
多くの場合は戻せます。Gitは過去の記録を持っているため、消したつもりの内容も履歴から取り出せることがよくあります。ただし自己流で取り消し操作を重ねると復旧が難しくなるので、いったん手を止めて先輩に相談するのがいちばん安全です。焦って取り消し操作を試すのがいちばん危ない対応です。
コミットはどれくらいの単位で分けるのですか？
「この変更は何のためか」を一文で説明できる単位が目安です。機能の追加とコードの整理を同じコミットに混ぜない、動く状態で区切る、といった考え方が基本ですが、細かい決めごとは現場によって違うので、先輩のコミット履歴を見せてもらうと感覚がつかめます。
