[モダンアプリ勉強会]今更聞けないGit/GitHub入門

Transcript

1. モダンアプリ勉強会 #1 今更聞けないGit/GitHub⼊⾨ 2026/5/11 つくぼし
2. 2 ⾃⼰紹介 • 部署 ◦ クラウド事業本部 ◦ モダンアプリコンサルチーム • ニックネーム ◦ つくぼし • 推していたAWSサービス ◦ AWS App Runner • SNS/ブログ ◦ X(@tsukuboshi0755) ◦ DevelopersIO(つくぼし) 職種歴： 1. インフラエンジニア：3年 2. クラウドエンジニア：3.5年 3. 開発エンジニア：2年
3. はじめに
4. 4 みなさんAI駆動開発してますよね？
5. 5 バイブコーディングでコードがどんどん変わる 頻繁に変更するとGit/GitHubが⽋かせなくなる
6. 6 でも何となくGit/GitHubを使っていませんか？
7. 7 本スライドで最低限のGit/GitHubの使い⽅を 知って頂けると幸いです
8. 本スライドの対象者 • ターミナルの基本操作は分かる • Gitを使ったことがない、またはほぼ初めて • GitHubをなんとなく使っているが、仕組みがよくわからない 8
9. ⽬次(1/2) • バージョン管理ってなに？ ◦ バージョン管理とは ◦ Gitとは ◦ GitHubとは ◦ ブランチとは ◦ プルリクエストとは 9 • Gitの基本操作を理解しよう ◦ Git全体の流れ ◦ リポジトリを⼿元にコピーする ◦ リモートのファイル変更を取り 込む ◦ 作業ブランチを作る ◦ 記録するファイルを選ぶ ◦ 変更を記録する ◦ 変更をリモートに反映する
10. ⽬次(2/2) • GitHubでチーム開発しよう ◦ GitHub全体の流れ ◦ タスクを管理する ◦ コードの取り込みを依頼する ◦ コードの変更をチェックする ◦ コードを本番に取り込む 10 • トラブルを防ぐ技術を知ろう ◦ 今の変更状態を確認する ◦ 変更を取り消す‧やり直す ◦ 記録しないファイルを指定する ◦ コミット前に⾃動チェックを⾛らせる ◦ 変更の衝突を解消する ◦ ブランチの使い分けを知る • 良い開発習慣を⾝につけよう ◦ 認証情報/秘匿情報はコミットするな ◦ コミットメッセージに種類をつける ◦ こまめにプルとプッシュを実⾏する ◦ プルリクエストは⼩さく作る
11. バージョン管理ってなに？
12. バージョン管理とは 12 バージョン管理：ファイルの変更履歴を記録‧管理する仕組み  変更履歴の追跡 「いつ‧誰が‧何を変更したか」という情 報を詳細に記録し、後から追いかけること が可能。  復元と⽐較 過去の任意の時点の状態にファイルを戻し たり、現在の変更点との差異を視覚的に⽐ 較可能。
13. バージョン管理システムがない世界 13
14. バージョン管理システムがある世界 14
15. Gitとは  Git：最も広く使われている分散型バージョン管理システム • プロジェクトをリポジトリ（ファイルと変更履歴をまとめた保管庫）として管理 • 変更履歴を コミット（ある時点のファイルの変更記録）として1つずつ記録 15 Gitの主な特徴 分散型 ローカルに履歴のコピーを持つため、オフラインでも作業可能 ⾼速 差分ではなくスナップショット⽅式で履歴を管理 軽量なブランチ ブランチを気軽に作成‧切り替え‧削除できる データの整合性 すべての変更をハッシュ値で管理し、コンテンツの同⼀性を保証
16. なぜSubversionではなくGitなのか 16 Subversion (SVN) Git アーキテクチャ 集中型 vs 分散型 履歴は中央サーバーに⼀元管理。コミットには常に サーバー接続が必須。 各開発者が完全なコピーを保持。 オフラインでもコミットや履歴参照が可能。 ブランチの扱い 運⽤の⼿軽さ ディレクトリコピー⽅式。⼤規模になると構造が複雑 になりがち。 ポインタによる超軽量管理。 作成‧切替‧削除が⼀瞬で完了し、並⾏開発が容易。 コードレビュー レビューの運⽤負荷 ブランチ作成が重く、レビュー⽤環境の構築に⼿間が かかる。 レビュー効率が⾼い。 軽量ブランチにより⼿元で即座に動作確認可能。PR機 能で対話的なレビューを実現。 💡 結論：バージョン管理システムを採⽤するなら、Gitを推奨します
17. GitHubとは 17  GitHub：Gitリポジトリのホスティングサービス • リモートリポジトリの置き場所として最も⼈気 • コードの共有‧レビュー‧プロジェクト管理機能を提供 GitとGitHubの関係（ローカルとリモートの役割分担） Git = ローカルリポジトリ ⾃分のPCで動くバージョン管理ツール GitHub = リモートリポジトリ Web上でリポジトリをホストするサービス
18.  Gitリポジトリホスティングサービスの違い GitHub GitLab CodeCommit Backlog 主な特徴 世界最⼤シェア。OSSとの 親和性や開発者コミュニ ティとの外部連携が協⼒ DevOps機能を⼀体提供。 無償版から⾃社サーバでセ ルフホスト可能な点が魅⼒ AWS完全統合。IAMによる 権限管理とAWS内での完結 がメリット プロジェクト管理⼀体 型。⽇本語UIで⾮エンジ ニアとの協働に最適 推奨ターゲット あらゆる場⾯に対応可能な デファクトスタンダード、 迷ったらまずこれ セキュリティ要件でリモー トリポジトリのセルフホス トが必須となる場合 社内ポリシーでAWSは利⽤ できるがGitHubを利⽤でき ない場合 ⾮エンジニアも含むチー ムで、開発ではなくタス ク管理を実施したい場合 CI/CD 標準でGitHub Actionsを提 供。外部ツール連携も⾮常 に豊富。 標準で⾼機能なGitLab CI/CDを提供。 CodeBuild/CodeDeploy/ CodePipeline等のAWSサー ビスとシームレスに連携。 専⽤のCI/CDサービスはな いため、外部ツールとの 連携が別途必要。 💡 結論：迷ったらGitHubを推奨します
19. Git/GitHubによる開発 19 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ
20. 20 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git commit -m “ファイルA追加” Git/GitHubによる開発 commit: ファイルA追加
21. 21 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git push Git/GitHubによる開発 commit: ファイルA追加
22. 22 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git pull Git/GitHubによる開発 commit: ファイルA追加
23. 23 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git commit -m “ファイルA更新” Git/GitHubによる開発 commit: ファイルA更新
24. 24 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git push Git/GitHubによる開発 commit: ファイルA更新
25. ブランチとは  ブランチ(branch)：本流（mainブランチ）から分岐させた作業⽤の枝 • 機能追加やバグ修正を本流と切り離して進められる • 作業が終わったら本流に統合（マージ）する 25 ブランチを使うメリット 安全な開発 本流に影響を与えず、独⽴した環境で試 ⾏錯誤が可能です 並⾏作業の推進 複数の開発者が、それぞれのブランチで 同時に別機能を開発できます 失敗のリセット 不要になったブランチは破棄するだけ で、簡単に元の状態に戻せます
26. 26 ブランチが無い世界 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ
27. 27 ブランチが無い世界 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git commit git commit
28. 28 ブランチが無い世界 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git push
29. 29 ブランチが無い世界 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git push
30. 30 ブランチが無い世界 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git push 最新コミットと矛盾するため pushできません
31. 31 ブランチがある世界 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git branch feat/A git branch feat/B
32. 32 ブランチがある世界 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git commit git commit
33. 33 ブランチがある世界 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git merge
34. 34 ブランチがある世界 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git push
35. 35 ブランチがある世界 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git pull
36. 36 ブランチがある世界 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git merge
37. 37 ブランチがある世界 ローカルリポジトリ ローカルリポジトリ リモートリポジトリ git push
38. プルリクエストとは 38  プルリクエスト（PR）：変更を取り込むための依頼 • 「レビューして問題なければマージして」という申請 • GitHub上で利⽤できる機能（Git単体の機能ではない） プルリクエストを使うメリット 品質の担保 マージ前にコードレビューを挟める 履歴の蓄積 変更内容や議論がGitHub上に残り、後か ら追える ⾃動化との連携 CIによる⾃動テストを経てからマージで きる
39. 39 プルリクエストがない世界 リモートリポジトリ ローカルリポジトリ ローカルリポジトリ コードレビューめんどいな 直接変更をプッシュしたろ！
40. 40 プルリクエストがない世界 リモートリポジトリ ローカルリポジトリ ローカルリポジトリ コードレビューめんどいな 直接変更をプッシュしたろ！ 許可
41. 41 プルリクエストがない世界 リモートリポジトリ ローカルリポジトリ ローカルリポジトリ コードレビューめんどいな 直接変更をプッシュしたろ！ 許可 勝手に変更が追加されてる！ 書き方がコード規約に則ってない！ めっちゃバグ出る！
42. 42 プルリクエストがある世界 リモートリポジトリ ローカルリポジトリ ローカルリポジトリ コードレビューめんどいな 直接変更をプッシュしたろ！
43. 43 プルリクエストがある世界 リモートリポジトリ ローカルリポジトリ ローカルリポジトリ コードレビューめんどいな 直接変更をプッシュしたろ！ 拒否
44. 44 プルリクエストがある世界 リモートリポジトリ ローカルリポジトリ ローカルリポジトリ しゃーない、 プルリクエスト作成するか それはOK
45. 45 プルリクエストがある世界 リモートリポジトリ ローカルリポジトリ ローカルリポジトリ しゃーない、 プルリクエスト作成するか それはOK レビューしまーす
46. 46 プルリクエストがある世界 リモートリポジトリ ローカルリポジトリ ローカルリポジトリ はわわ インデントがずれています。変 数名が命名規則に則っていま せん。余分な空白行が追加さ れています。コミット粒度が粗 すぎます。関数の挙動が変 わっていますがこれは意図した ものでしょうか？このクラスの 設計意図は何でしょうか？テス トに失敗しています。
47. Gitの基本操作を理解しよう
48. Git全体の流れ 48 基本フロー：クローン → プル → ブランチ → ステージング → コミット → プッシュ 1. クローン リモートリポジトリをローカルに複製する （最初の1回だけ） 2. プル リモートの最新変更をローカルに取り込む （作業開始前に毎回） 3. ブランチ 作業⽤のブランチを切って切り替える 4. ステージング コミットに含めたい変更を選択する 5. コミット 選択した変更をローカルリポジトリに記録 する 6. プッシュ ローカルのコミットをリモートに反映する ローカル（⾃分のPC）とリモート（GitHub）を⾏き来しながら作業を進めるのが基本
49. リポジトリを⼿元にコピーする（クローン） 49 クローン (clone) リモートリポジトリをローカルにコピーするこ と  実⾏のタイミング 最初に1回だけ実⾏する必要があるコマンドです。プ ロジェクトへの参加時に最初に⾏います。 git clone <repository-url>
50. リモートの変更を取り込む（プル） プル (pull) リモートリポジトリの最新変更をローカルに取 り込むこと  実⾏のタイミング 他のメンバーの変更を取り込むために、作業開始前な どに定期的に実⾏します。 50 git pull
51. 作業ブランチを作って切り替える（スイッチ） 51 スイッチ (switch) 作業するブランチを切り替えること  実⾏のタイミング -c オプションで新規作成と切り替えを同時に実⾏でき ます。作業開始前にまず実⾏しましょう。 git switch -c <branch-name>
52. 記録するファイルを選ぶ（ステージング） ステージング (staging) コミットに含める変更を選択すること  実⾏のタイミング コミット前に毎回実⾏します。ファイル変更の記録を 残す起点となるのでこまめに実⾏しましょう。 52 git add <file-name>
53. 変更を記録する（コミット） 53 コミット (commit) ステージングした変更をローカルリポジトリに 記録すること  実⾏のタイミング 作業の区切りがついた時や、機能の実装が終わったタ イミングで⾏います。 git commit -m “message”
54. 変更をリモートに反映する（プッシュ） 54 プッシュ (push) ローカルのコミットをリモートリポジトリに反 映すること  実⾏のタイミング ローカルでの作業（コミット）が完了し、その成果を 共有リポジトリに公開したい時に実⾏します。 git push origin <branch-name>
55. GitHubでチーム開発しよう
56. GitHub全体の流れ 56 基本フロー：イシュー → プルリクエスト → レビュー → マージ → イシューのクローズ 1. イシュー タスクやバグをチケットとして起票し、誰が何 をやるかを明確にする 2. プルリクエスト 作業ブランチの変更を本流に取り込むよう依頼 する 3. レビュー 他のメンバーがコードの品質‧設計‧バグの有 無をチェックする 4. マージ レビューで承認された変更をmainブランチに 統合する 5. イシューのクローズ 対応が完了したイシューを閉じて状態を整理す る ローカルでのGit操作 → GitHub上での議論‧承認、という流れでチーム開発を回す
57. タスクを管理する（イシュー） 57 イシュー (Issue)：タスク‧バグ‧要望などを管理するチケット機能 「何をやるべきか」をチームで共有‧追跡するために使う イシューに書く内容の例 タイトル やることの概要 説明 背景‧再現⼿順‧期待する動作など ラベル bug, enhancement, documentation などで分類 担当者 (Assignee) 誰が対応するか
58. GitHub Issueの例 58
59. GitHub Issueの例 59
60. GitHub Issueの例 60
61. コードの取り込みを依頼する（プルリクエスト） 61 プルリクエスト (Pull Request)：ブランチの変更をmainブランチに取り込む依頼 「このコードをレビューして、問題なければマージしてください」という申請 PRに書く内容の例 タイトル 変更の概要 説明 変更内容‧関連するイシュー番号 #123 で⾃動リンク レビュアー レビューを依頼する相⼿を指定 適切な情報を記載することで、スムーズなレビューと品質の維持が可能になります
62. GitHub Pull Requestsの例 62
63. GitHub Pull Requestsの例 63
64. GitHub Pull Requestsの例 64
65. コードの変更をチェックする（レビュー） 65 レビュー (Review)：PRの変更内容を他のメンバーが確認すること コードの品質‧バグの有無‧設計⽅針をチェックする レビューの種類 Comment 質問やコメントのみ （承認でも却下でもない） Approve 問題なし → マージOK Request Changes 修正が必要 → 修正後に再レビュー 適切なレビューサイクルを回すことで、チーム全体のコード品質を向上させることができます
66. レビューの例 66
67. レビューの例 67
68. レビューの例 68
69. レビューの例 69
70. コードを本番に取り込む（マージ） 70 マージ (Merge)：PRの変更をmainブランチに統合すること レビューでApproveされた後に実⾏する マージの種類 Create a merge commit マージコミットを作成 （履歴がそのまま残る） ← 迷ったら基本これ Squash and merge 複数コミットを1つに まとめてマージ Rebase and merge コミットをmainの先頭に 付け替えてマージ マージ後はイシューのクローズも忘れずに
71. マージの例 71
72. マージの例 72
73. トラブルを防ぐ技術を知ろう
74. 今の変更状態を確認する（status / diff / log） 74 🔍 status 作業ツリーの状態を確認 ファイルの追加、変更、削除など、現 在の作業状況を把握します。 git status 📝 diff 変更内容の差分を確認 具体的にどの⾏が追加‧削除されたの か、詳細な変更箇所を表⽰します。 git diff 📜 log コミット履歴を確認 過去のコミットメッセージやIDを⼀覧 で確認し、開発の経緯を辿ります。 git log --oneline
75. 変更を取り消す‧やり直す（reset / stash） 🔄 reset コミットを取り消す • 直前のコミットを取り消し（変更は残す） git reset --soft HEAD~1 HEAD=今いる位置、~1=1つ前。つまり1つ前の状態に戻り ます。 • 直前のコミット内容やメッセージを修正 git commit --amend 75 📦 stash 作業中の変更を⼀時退避する • 変更を⼀時的に脇に置いておく git stash • 退避した変更を元に戻す git stash pop 間違ったブランチで作業を始めてしまった時などに、別のブ ランチへ移動する前に使うと便利です。
76. 記録しないファイルを指定する（.gitignore） 76 .gitignore：Gitの追跡対象から除外するファイルを指定する設定ファイル リポジトリのルートに .gitignore ファイルを作成する 🔐 秘匿情報 流出厳禁の情報 • .env • credentials.json • *.pem 📦 依存パッケージ 再⽣成可能な外部ライブラリ • node_modules/ • __pycache__/ 🛠 ビルド成果物 実⾏⽤に変換されたファイル • dist/ • build/ 💻 OS固有ファイル システムが⾃動⽣成するファ イル • .DS_Store • Thumbs.db
77. コミット前に⾃動チェックを⾛らせる(pre-commit) 77 Gitフック：特定のGit操作（コミット等）の前後でスクリプトを⾃動実⾏する仕組み チェック失敗時にコミットを中断し、不備のあるコードが混⼊するのを防ぐ 🛠 代表的なフレームワーク pre-commit (Python製‧多⾔語対応) • YAMLで設定を宣⾔的に記述 • Python中⼼や⾔語混在プロジェクトで定番 husky (Node.js製) • シェルスクリプトを直接記述 • JS/TSプロジェクトのデファクト 🔍 主な⽤途 フォーマッタ‧リンタ コードスタイルを⾃動整形‧指摘。レビュー負荷を軽減しま す。 秘匿情報の検出 APIキー等の混⼊を未然に防⽌（例: gitleaks）。
78. 変更の衝突を解消する（コンフリクト） 78 💥 コンフリクト (conflict) 同じファイルの同じ箇所を複数⼈が変更した場合に発⽣する 衝突 • Gitが⾃動マージできず、⼿動で解決が必要になる 🛠 対処⽅法 1. 該当ファイルのマーカーを確認 2. 残すべき変更を修正＆コミット ※ マーカー：<<<<<<< ======= >>>>>>> conflict_example.txt <<<<<<< HEAD 自分が行った変更内容 (Current Change) ======= 他の人が行った変更内容 (Incoming Change) >>>>>>> feature/other-branch ※ コンフリクトマーカーの例
79. 79 ブランチ戦略とは チームでブランチをどう運⽤するかの共通ルール GitHub Flow イメージ図 ブランチの使い分けを知る（ブランチ戦略） 🚀 GitHub Flow から始めよう シンプルで分かりやすいため、最初の導⼊として⾮常に おすすめです。 • 構成： main + feature/xxx のみ • ルール： featureからPRを出してmainへマージ
80. 良い開発習慣を⾝につけよう
81. 認証情報や秘匿情報はコミットするな 81 🚨 秘匿情報とは 外部に漏れると重⼤な被害が出る情報 • APIキー‧トークン • パスワード‧秘密鍵 • 公開されると世界中から閲覧可能 になる ⚠ 削除は困難 ⼀度のコミットで完全削除が不可能に • 履歴消去後もクローン済みなら⼿ 遅れ • GitHubキャッシュに残る可能性 • 漏洩時は必ずローテーション（再 発⾏） ✅ 事前の対策 コミットによる流出を未然に防ぐ習慣 • .env で情報を分離 • .gitignore で除外設定 • gitleaks を⽤いてpre-commitに よるコードスキャンを実⾏
82. コミットメッセージに種類をつける Conventional Commits の prefix を使うと変更の種類が⼀⽬でわかる feat: 新機能の追加 fix: バグ修正 docs: ドキュメントの変更 refactor: リファクタリング test: テストの追加‧修正 chore: ビルド設定などの変更 例： feat: ログイン機能を追加、fix: メール送信エラーを修正 82
83. こまめにプルとプッシュを実⾏する 83 ✅ こまめにプル 作業開始前に必ず git pull で最新の状 態を取得 • コンフリクトを最⼩限に • 他者の変更を早期把握 🚀 こまめにプッシュ キリのいい単位で git push してリモー トに反映 • PC紛失等の消失リスク回避 • チームへの変更の早期共有 ⚠ 同期しないと… 同期を怠ると発⽣する負の連鎖 • ⼤量のコンフリクトが発⽣ • マージ作業が極めて複雑に • ローカルの変更を事故で紛失
84. プルリクエストは⼩さく作る 84  PRは⼩さくする レビューの品質を⾼め、マージを迅速 に • ⽬安は変更300⾏以内 • 1つのPRに1つの⽬的 • 機能追加とリファクタを混ぜない  明確な説明を書く ⽂脈を共有し、意図を正しく伝える • 何を‧なぜ変更したかを簡潔に • 関連イシュー番号をリンク • レビュアーの負荷を軽減する  セルフレビュー 提出前に⾃分のコードを客観視する • ⾃分でdiffを最終確認 • ケアレスミスを事前に修正 • ⾃信を持ってレビュー依頼へ
85. 最後に
86. まとめ • Git = ローカルで動く分散型バージョン管理ツール • GitHub = Gitリポジトリのホスティングサービス • clone → pull → switch → add → commit → pushの流れを押さえる • イシューで起票 → PRで依頼 → レビュー → マージの流れで品質を担保 • 秘匿情報はコミットしない、コミットメッセージに種類を付ける、こまめ にプルとプッシュ、PRは⼩さく作る 86
87. 次に学ぶべきGit/GitHubの仕組み • GitHub Actions：CI/CDによる⾃動化 • GitHub Projects：タスク‧進捗の可視化 • タグ‧リリース（tag / release）：リリースノートと配布物のパッケージ化 • GitHub CLI（gh）：ターミナルからのGitHub操作 87