Git / GitHub
変更履歴を刻む Git と、クラウドで共有する GitHub。基本の言葉と自動リリースまで
Git は手元で変更履歴を刻む道具、GitHub はその履歴を持ち寄って共有・レビューするクラウドの場所です。2 つが組み合わさって、はじめてチーム開発になります。
- 記録は手元の Git、共有とレビューは GitHub
- main への合流はレビューを通った提案だけ
- 5SLAB ではマージが本番リリースの起点
Git と GitHub はどう違う？
呼び名が似ていて、いつもセットで語られるため、同じものだと思われがちです。どこまでが手元で完結して、どこからが共有の話なのか ── その境目こそが 2 つの違いの正体です。
各ブロックや矢印をクリックすると、その仕組みの説明がここに表示されます。
手元で刻んだ履歴を push で持ち寄る — 2 つの役割はこの 1 本でつながる
この図をテキストで読む
構成図「Git と GitHub はどう違う？」。ブロック6個、つながり1本。 枠: Git（手元の記録係）（ブロック3個）、GitHub（みんなの置き場）（ブロック3個）。 【ブロック】 - PCで動く道具: インストールして使う - 変更履歴を刻む: commit ＝ 記録の単位 - ネットなしで動く: 手元で完結 - クラウドのサービス: ブラウザで使う - 履歴を集めて共有: push の置き場 - レビュー・自動化: PR / Actions 【流れ】 - Git で記録 → GitHub へ共有: 変更履歴を刻む → 履歴を集めて共有
GitHub はどう始める？
会社の開発に加わるには、まず自分の GitHub アカウントが要ります。登録そのものより大切なのは、途中にある守りの設定です。アカウントの乗っ取りは会社のコード流出に直結するため、面倒でも最初の数分で固めてしまうのが近道です。
各ステップをクリックすると、その内容の説明がここに表示されます。
この図をテキストで読む
ステップ図「GitHub アカウントの作り方」。5ステップ。 【手順】（順番に） 1. サインアップ（メール・ユーザー名・パスワード） 2. メール認証（届いたコードを入力） 3. 二要素認証(2FA)（スマホアプリで保護） 4. プロフィール設定（表示名・アイコン） 5. 5SLABに参加（招待を受ける） 補足: GitHub アカウントは無料。①から順に進めば数分で完了します 【流れ】 - アカウント開設の流れ: サインアップ → メール認証 → 二要素認証(2FA) → プロフィール設定 → 5SLABに参加
変更はどう記録され、どう共有される？
コミット・プッシュ・プルリクエスト ── 呪文のように聞こえる言葉も、実際の作業ではいつも同じ順番で現れます。自分がいまどの段階にいて、次に何が起きるのかという地図を持つと、チームの会話に迷わずついていけます。
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
シーケンス図「基本の言葉と流れ」。参加者4人、ステップ9個。 【参加者】（左から右） - あなた: エディタ / 作業ツリー - ローカルGit: PC内の履歴（.git） - GitHub: クラウドのリモート - レビュアー: 5SLAB / 仲間 【流れ】（上から下へ） ── ① 作業の前にブランチを切る ── 1. あなた → ローカルGit: 作業用のブランチを作る（git switch -c） ── ② 手元で変更を記録する（commit） ── 2. あなた（自身で処理）: ファイルを編集する 3. あなた → ローカルGit: 変更を選んでコミット（git add → commit） ── ③ GitHub に共有する（push） ── 4. ローカルGit → GitHub: ブランチを push してアップロード ── ④ プルリクエストでレビュー＆合流（PR → merge） ── 5. あなた → GitHub: プルリクエスト（PR）を作る 6. GitHub → レビュアー: レビューを依頼 7. レビュアー → GitHub: 確認して承認（Approve）（応答） 8. GitHub（自身で処理）: main に merge（合流） ── ⑤ 最新を手元に取り込む（pull） ── 9. GitHub → ローカルGit: main の最新を pull（応答）
マージした変更はどう本番に届く？
5SLAB では、リリースを人の手作業にしていません。手順書どおりに人が操作する方式は、抜け漏れや「担当者しかできない」を生みがちだからです。仕組みに任せるとリリースは日常の作業になり、小さく頻繁に届けられるようになります。
各工程・分岐・レーンをクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
業務フロー図「GitHub Actions で自動リリース」。レーン4本、工程10個。 【レーン（担当）】（左から右） - 開発者: あなた / レビュアー - GitHub: リモートリポジトリ - GitHub Actions: CI / CD（自動実行） - 本番環境: 公開サーバー 【工程】（上から下へ。担当 → 工程名） ── フェーズ: マージ ── 1. 開発者: PR を承認して main へマージ〔開始・終了〕 2. GitHub: main の更新を検知 ── フェーズ: 検査 ── 3. GitHub Actions: ワークフローが自動起動 4. GitHub Actions: テスト＆型チェックは合格?〔分岐〕（品質の関所） はい → 本番用にビルド いいえ → デプロイ中止・原因を通知 5. 開発者: デプロイ中止・原因を通知〔開始・終了〕（本番は元のまま） 6. GitHub Actions: 本番用にビルド（配布できる形に固める） ── フェーズ: 公開 ── 7. 本番環境: 本番サーバーへ反映 8. GitHub Actions: 公開後の稼働チェック OK?〔分岐〕（ちゃんと動くか確認） はい → リリース完了・サイト公開 いいえ → 自動で切り戻し・通知 9. GitHub Actions: 自動で切り戻し・通知〔開始・終了〕（前の版に戻す） 10. 本番環境: リリース完了・サイト公開〔開始・終了〕（利用者が使える状態に）
開発は 5SLAB の Organization の中で
会社の開発は GitHub の Organization（組織アカウント）の中で行います。あなたは個人アカウントのまま招待され、コードは会社の資産として管理されます。リポジトリや自動リリースの仕組みは 5SLAB が用意するので、決められた流れに乗るだけで大丈夫です。
押さえておきたい用語
- コミット（commit）
- 変更を手元の履歴に刻む単位。何をなぜ変えたかのメッセージを添え、区切りごとに小さく刻むのがコツです。
- push / pull
- push は手元のコミットを GitHub へアップロードして共有すること。pull はその逆で、最新を手元に取り込むことです。
- プルリクエスト（PR）とマージ
- PR は「この変更を main に入れて」という提案。差分を見ながらレビューし、通ると main に合流（マージ）されて正式な状態になります。
- Organization（組織）
- 会社・チーム用の GitHub アカウント。メンバー・チーム・リポジトリ（プロジェクトの入れ物）をまとめて持ち、権限はチーム単位で付与します。
- GitHub Actions
- push やマージをきっかけに、テストやリリースを自動で実行する仕組み。CI（自動テスト）/ CD（自動リリース）を担います。
ここから先へ
この解説とつながりのあるページ