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

by つくぼし

Embed

Start on current slide

Slide 1

Slide 1 text

モダンアプリ勉強会 #1 今更聞けないGit/GitHub⼊⾨ 2026/5/11 つくぼし

Slide 2

Slide 2 text

2 ⾃⼰紹介 ● 部署 ○ クラウド事業本部 ○ モダンアプリコンサルチーム ● ニックネーム ○ つくぼし ● 推していたAWSサービス ○ AWS App Runner ● SNS/ブログ ○ X(@tsukuboshi0755) ○ DevelopersIO(つくぼし) 職種歴： 1. インフラエンジニア：3年 2. クラウドエンジニア：3.5年 3. 開発エンジニア：2年

Slide 3

Slide 3 text

はじめに

Slide 4

Slide 4 text

4 みなさんAI駆動開発してますよね？

Slide 5

Slide 5 text

5 バイブコーディングでコードがどんどん変わる頻繁に変更するとGit/GitHubが⽋かせなくなる

Slide 6

Slide 6 text

6 でも何となくGit/GitHubを使っていませんか？

Slide 7

Slide 7 text

7 本スライドで最低限のGit/GitHubの使い⽅を知って頂けると幸いです

Slide 8

Slide 8 text

本スライドの対象者 ● ターミナルの基本操作は分かる ● Gitを使ったことがない、またはほぼ初めて ● GitHubをなんとなく使っているが、仕組みがよくわからない 8

Slide 9

Slide 9 text

⽬次(1/2) ● バージョン管理ってなに？ ○ バージョン管理とは ○ Gitとは ○ GitHubとは ○ ブランチとは ○ プルリクエストとは 9 ● Gitの基本操作を理解しよう ○ Git全体の流れ ○ リポジトリを⼿元にコピーする ○ リモートのファイル変更を取り込む ○ 作業ブランチを作る ○ 記録するファイルを選ぶ ○ 変更を記録する ○ 変更をリモートに反映する

Slide 10

Slide 10 text

⽬次(2/2) ● GitHubでチーム開発しよう ○ GitHub全体の流れ ○ タスクを管理する ○ コードの取り込みを依頼する ○ コードの変更をチェックする ○ コードを本番に取り込む 10 ● トラブルを防ぐ技術を知ろう ○ 今の変更状態を確認する ○ 変更を取り消す‧やり直す ○ 記録しないファイルを指定する ○ コミット前に⾃動チェックを⾛らせる ○ 変更の衝突を解消する ○ ブランチの使い分けを知る ● 良い開発習慣を⾝につけよう ○ 認証情報/秘匿情報はコミットするな ○ コミットメッセージに種類をつける ○ こまめにプルとプッシュを実⾏する ○ プルリクエストは⼩さく作る

Slide 11

Slide 11 text

バージョン管理ってなに？

Slide 12

Slide 12 text

バージョン管理とは 12 バージョン管理：ファイルの変更履歴を記録‧管理する仕組み  変更履歴の追跡「いつ‧誰が‧何を変更したか」という情報を詳細に記録し、後から追いかけることが可能。  復元と⽐較過去の任意の時点の状態にファイルを戻したり、現在の変更点との差異を視覚的に⽐較可能。

Slide 13

Slide 13 text

バージョン管理システムがない世界 13

Slide 14

Slide 14 text

バージョン管理システムがある世界 14

Slide 15

Slide 15 text

Gitとは  Git：最も広く使われている分散型バージョン管理システム ● プロジェクトをリポジトリ（ファイルと変更履歴をまとめた保管庫）として管理 ● 変更履歴をコミット（ある時点のファイルの変更記録）として1つずつ記録 15 Gitの主な特徴分散型ローカルに履歴のコピーを持つため、オフラインでも作業可能⾼速差分ではなくスナップショット⽅式で履歴を管理軽量なブランチブランチを気軽に作成‧切り替え‧削除できるデータの完全性すべての変更をハッシュ値で管理し、改竄を検知可能

Slide 16

Slide 16 text

⽬次(1/2) ● バージョン管理ってなに？ ○ バージョン管理とは ○ Gitとは ○ GitHubとは ○ ブランチとは ○ プルリクエストとは 16 ● Gitの基本操作を理解しよう ○ Git全体の流れ ○ リポジトリを⼿元にコピーする ○ リモートのファイル変更を取り込む ○ 作業ブランチを作る ○ 記録するファイルを選ぶ ○ 変更を記録する ○ 変更をリモートに反映する

Slide 17

Slide 17 text

GitHubとは 17  GitHub：Gitリポジトリのホスティングサービス ● リモートリポジトリの置き場所として最も⼈気 ● コードの共有‧レビュー‧プロジェクト管理機能を提供 GitとGitHubの関係（ローカルとリモートの役割分担） Git = ローカルリポジトリ⾃分のPCで動くバージョン管理ツール GitHub = リモートリポジトリ Web上でリポジトリをホストするサービス

Slide 18

Slide 18 text

Git/GitHubによる開発 18 ローカルリポジトリローカルリポジトリリモートリポジトリ

Slide 19

Slide 19 text

19 ローカルリポジトリローカルリポジトリリモートリポジトリ git commit -m “ファイルA追加” Git/GitHubによる開発 commit: ファイルA追加

Slide 20

Slide 20 text

20 ローカルリポジトリローカルリポジトリリモートリポジトリ git push Git/GitHubによる開発 commit: ファイルA追加

Slide 21

Slide 21 text

21 ローカルリポジトリローカルリポジトリリモートリポジトリ git pull Git/GitHubによる開発 commit: ファイルA追加

Slide 22

Slide 22 text

22 ローカルリポジトリローカルリポジトリリモートリポジトリ git commit -m “ファイルA更新” Git/GitHubによる開発 commit: ファイルA更新

Slide 23

Slide 23 text

23 ローカルリポジトリローカルリポジトリリモートリポジトリ git push Git/GitHubによる開発 commit: ファイルA更新

Slide 24

Slide 24 text

ブランチとは  ブランチ(branch)：本流（mainブランチ）から分岐させた作業⽤の枝 ● 機能追加やバグ修正を本流と切り離して進められる ● 作業が終わったら本流に統合（マージ）する 24 ブランチを使うメリット安全な開発本流に影響を与えず、独⽴した環境で試⾏錯誤が可能です並⾏作業の推進複数の開発者が、それぞれのブランチで同時に別機能を開発できます失敗のリセット不要になったブランチは破棄するだけで、簡単に元の状態に戻せます

Slide 25

Slide 25 text

25 ブランチが無い世界ローカルリポジトリローカルリポジトリリモートリポジトリ

Slide 26

Slide 26 text

26 ブランチが無い世界ローカルリポジトリローカルリポジトリリモートリポジトリ git commit git commit

Slide 27

Slide 27 text

27 ブランチが無い世界ローカルリポジトリローカルリポジトリリモートリポジトリ git push

Slide 28

Slide 28 text

28 ブランチが無い世界ローカルリポジトリローカルリポジトリリモートリポジトリ git push

Slide 29

Slide 29 text

29 ブランチが無い世界ローカルリポジトリローカルリポジトリリモートリポジトリ git push 最新コミットと矛盾するため pushできません

Slide 30

Slide 30 text

30 ブランチがある世界ローカルリポジトリローカルリポジトリリモートリポジトリ git branch feat/A git branch feat/B

Slide 31

Slide 31 text

31 ブランチがある世界ローカルリポジトリローカルリポジトリリモートリポジトリ git commit git commit

Slide 32

Slide 32 text

32 ブランチがある世界ローカルリポジトリローカルリポジトリリモートリポジトリ git merge

Slide 33

Slide 33 text

33 ブランチがある世界ローカルリポジトリローカルリポジトリリモートリポジトリ git push

Slide 34

Slide 34 text

34 ブランチがある世界ローカルリポジトリローカルリポジトリリモートリポジトリ git pull

Slide 35

Slide 35 text

35 ブランチがある世界ローカルリポジトリローカルリポジトリリモートリポジトリ git merge

Slide 36

Slide 36 text

36 ブランチがある世界ローカルリポジトリローカルリポジトリリモートリポジトリ git push

Slide 37

Slide 37 text

プルリクエストとは 37  プルリクエスト（PR）：変更を取り込むための依頼 ● 「レビューして問題なければマージして」という申請 ● GitHub上で利⽤できる機能（Git単体の機能ではない）プルリクエストを使うメリット品質の担保マージ前にコードレビューを挟める履歴の蓄積変更内容や議論がGitHub上に残り、後から追える⾃動化との連携 CIによる⾃動テストを経てからマージできる

Slide 38

Slide 38 text

38 プルリクエストがない世界リモートリポジトリローカルリポジトリローカルリポジトリコードレビューめんどいな直接変更をプッシュしたろ！

Slide 39

Slide 39 text

39 プルリクエストがない世界リモートリポジトリローカルリポジトリローカルリポジトリコードレビューめんどいな直接変更をプッシュしたろ！許可

Slide 40

Slide 40 text

40 プルリクエストがない世界リモートリポジトリローカルリポジトリローカルリポジトリコードレビューめんどいな直接変更をプッシュしたろ！許可勝手に変更が追加されてる！書き方がコード規約に則ってない！めっちゃバグ出る！

Slide 41

Slide 41 text

41 プルリクエストがある世界リモートリポジトリローカルリポジトリローカルリポジトリコードレビューめんどいな直接変更をプッシュしたろ！

Slide 42

Slide 42 text

42 プルリクエストがある世界リモートリポジトリローカルリポジトリローカルリポジトリコードレビューめんどいな直接変更をプッシュしたろ！拒否

Slide 43

Slide 43 text

43 プルリクエストがある世界リモートリポジトリローカルリポジトリローカルリポジトリしゃーない、プルリクエスト作成するかそれはOK

Slide 44

Slide 44 text

44 プルリクエストがある世界リモートリポジトリローカルリポジトリローカルリポジトリしゃーない、プルリクエスト作成するかそれはOK レビューしまーす

Slide 45

Slide 45 text

45 プルリクエストがある世界リモートリポジトリローカルリポジトリローカルリポジトリはわわインデントがずれています。変数名が命名規則に則っていません。余分な空白行が追加されています。コミット粒度が粗すぎます。関数の挙動が変わっていますがこれは意図したものでしょうか？このクラスの設計意図は何でしょうか？テストに失敗しています。

Slide 46

Slide 46 text

Gitの基本操作を理解しよう

Slide 47

Slide 47 text

Git全体の流れ 47 基本フロー：クローン → プル → ブランチ → ステージング → コミット → プッシュ 1. クローンリモートリポジトリをローカルに複製する（最初の1回だけ） 2. プルリモートの最新変更をローカルに取り込む（作業開始前に毎回） 3. ブランチ作業⽤のブランチを切って切り替える 4. ステージングコミットに含めたい変更を選択する 5. コミット選択した変更をローカルリポジトリに記録する 6. プッシュローカルのコミットをリモートに反映するローカル（⾃分のPC）とリモート（GitHub）を⾏き来しながら作業を進めるのが基本

Slide 48

Slide 48 text

リポジトリを⼿元にコピーする（クローン） 48 クローン (clone) リモートリポジトリをローカルにコピーすること  実⾏のタイミング最初に1回だけ実⾏する必要があるコマンドです。プロジェクトへの参加時に最初に⾏います。 git clone

Slide 49

Slide 49 text

リモートの変更を取り込む（プル）プル (pull) リモートリポジトリの最新変更をローカルに取り込むこと  実⾏のタイミング他のメンバーの変更を取り込むために、作業開始前などに定期的に実⾏します。 49 git pull

Slide 50

Slide 50 text

作業ブランチを作って切り替える（スイッチ） 50 スイッチ (switch) 作業するブランチを切り替えること  実⾏のタイミング -c オプションで新規作成と切り替えを同時に実⾏できます。作業開始前にまず実⾏しましょう。 git switch -c

Slide 51

Slide 51 text

記録するファイルを選ぶ（ステージング）ステージング (staging) コミットに含める変更を選択すること  実⾏のタイミングコミット前に毎回実⾏します。ファイル変更の記録を残す起点となるのでこまめに実⾏しましょう。 51 git add

Slide 52

Slide 52 text

変更を記録する（コミット） 52 コミット (commit) ステージングした変更をローカルリポジトリに記録すること  実⾏のタイミング作業の区切りがついた時や、機能の実装が終わったタイミングで⾏います。 git commit -m “message”

Slide 53

Slide 53 text

変更をリモートに反映する（プッシュ） 53 プッシュ (push) ローカルのコミットをリモートリポジトリに反映すること  実⾏のタイミングローカルでの作業（コミット）が完了し、その成果を共有リポジトリに公開したい時に実⾏します。 git push origin

Slide 54

Slide 54 text

GitHubでチーム開発しよう

Slide 55

Slide 55 text

GitHub全体の流れ 55 基本フロー：イシュー → プルリクエスト → レビュー → マージ → イシューのクローズ 1. イシュータスクやバグをチケットとして起票し、誰が何をやるかを明確にする 2. プルリクエスト作業ブランチの変更を本流に取り込むよう依頼する 3. レビュー他のメンバーがコードの品質‧設計‧バグの有無をチェックする 4. マージレビューで承認された変更をmainブランチに統合する 5. イシューのクローズ対応が完了したイシューを閉じて状態を整理するローカルでのGit操作 → GitHub上での議論‧承認、という流れでチーム開発を回す

Slide 56

Slide 56 text

タスクを管理する（イシュー） 56 イシュー (Issue)：タスク‧バグ‧要望などを管理するチケット機能「何をやるべきか」をチームで共有‧追跡するために使うイシューに書く内容の例タイトルやることの概要説明背景‧再現⼿順‧期待する動作などラベル bug, enhancement, documentation などで分類担当者 (Assignee) 誰が対応するか

Slide 57

Slide 57 text

GitHub Issueの例 57

Slide 58

Slide 58 text

GitHub Issueの例 58

Slide 59

Slide 59 text

GitHub Issueの例 59

Slide 60

Slide 60 text

コードの取り込みを依頼する（プルリクエスト） 60 プルリクエスト (Pull Request)：ブランチの変更をmainブランチに取り込む依頼「このコードをレビューして、問題なければマージしてください」という申請 PRに書く内容の例タイトル変更の概要説明変更内容‧関連するイシュー番号 #123 で⾃動リンクレビュアーレビューを依頼する相⼿を指定適切な情報を記載することで、スムーズなレビューと品質の維持が可能になります

Slide 61

Slide 61 text

GitHub Pull Requestsの例 61

Slide 62

Slide 62 text

GitHub Pull Requestsの例 62

Slide 63

Slide 63 text

GitHub Pull Requestsの例 63

Slide 64

Slide 64 text

コードの変更をチェックする（レビュー） 64 レビュー (Review)：PRの変更内容を他のメンバーが確認することコードの品質‧バグの有無‧設計⽅針をチェックするレビューの種類 Comment 質問やコメントのみ（承認でも却下でもない） Approve 問題なし → マージOK Request Changes 修正が必要 → 修正後に再レビュー適切なレビューサイクルを回すことで、チーム全体のコード品質を向上させることができます

Slide 65

Slide 65 text

レビューの例 65

Slide 66

Slide 66 text

レビューの例 66

Slide 67

Slide 67 text

レビューの例 67

Slide 68

Slide 68 text

レビューの例 68

Slide 69

Slide 69 text

コードを本番に取り込む（マージ） 69 マージ (Merge)：PRの変更をmainブランチに統合することレビューでApproveされた後に実⾏するマージの種類 Create a merge commit マージコミットを作成（履歴がそのまま残る） ← 迷ったら基本これ Squash and merge 複数コミットを1つにまとめてマージ Rebase and merge コミットをmainの先頭に付け替えてマージマージ後はイシューのクローズも忘れずに

Slide 70

Slide 70 text

マージの例 70

Slide 71

Slide 71 text

マージの例 71

Slide 72

Slide 72 text

トラブルを防ぐ技術を知ろう

Slide 73

Slide 73 text

今の変更状態を確認する（status / diﬀ / log） 73 🔍 status 作業ツリーの状態を確認ファイルの追加、変更、削除など、現在の作業状況を把握します。 git status 📝 diﬀ 変更内容の差分を確認具体的にどの⾏が追加‧削除されたのか、詳細な変更箇所を表⽰します。 git diff 📜 log コミット履歴を確認過去のコミットメッセージやIDを⼀覧で確認し、開発の経緯を辿ります。 git log --oneline

Slide 74

Slide 74 text

変更を取り消す‧やり直す（reset / stash） 🔄 reset コミットを取り消す ● 直前のコミットを取り消し（変更は残す） git reset --soft HEAD~1 HEAD=今いる位置、~1=1つ前。つまり1つ前の状態に戻ります。 ● 直前のコミット内容やメッセージを修正 git commit --amend 74 📦 stash 作業中の変更を⼀時退避する ● 変更を⼀時的に脇に置いておく git stash ● 退避した変更を元に戻す git stash pop 間違ったブランチで作業を始めてしまった時などに、別のブランチへ移動する前に使うと便利です。

Slide 75

Slide 75 text

記録しないファイルを指定する（.gitignore） 75 .gitignore：Gitの追跡対象から除外するファイルを指定する設定ファイルリポジトリのルートに .gitignore ファイルを作成する 🔐 秘匿情報流出厳禁の情報 ● .env ● credentials.json ● *.pem 📦 依存パッケージ再⽣成可能な外部ライブラリ ● node_modules/ ● __pycache__/ 🛠 ビルド成果物実⾏⽤に変換されたファイル ● dist/ ● build/ 💻 OS固有ファイルシステムが⾃動⽣成するファイル ● .DS_Store ● Thumbs.db

Slide 76

Slide 76 text

コミット前に⾃動チェックを⾛らせる(pre-commit) 76 Gitフック：特定のGit操作（コミット等）の前後でスクリプトを⾃動実⾏する仕組みチェック失敗時にコミットを中断し、不備のあるコードが混⼊するのを防ぐ 🛠 代表的なフレームワーク pre-commit (Python製‧多⾔語対応) ● YAMLで設定を宣⾔的に記述 ● Python中⼼や⾔語混在プロジェクトで定番 husky (Node.js製) ● シェルスクリプトを直接記述 ● JS/TSプロジェクトのデファクト 🔍 主な⽤途フォーマッタ‧リンタコードスタイルを⾃動整形‧指摘。レビュー負荷を軽減します。秘匿情報の検出 APIキー等の混⼊を未然に防⽌（例: gitleaks）。

Slide 77

Slide 77 text

変更の衝突を解消する（コンフリクト） 77 💥 コンフリクト (conﬂict) 同じファイルの同じ箇所を複数⼈が変更した場合に発⽣する衝突 ● Gitが⾃動マージできず、⼿動で解決が必要になる 🛠 対処⽅法 1. 該当ファイルのマーカーを確認 2. 残すべき変更を修正＆コミット ※ マーカー：<<<<<<< ======= >>>>>>> conflict_example.txt <<<<<<< HEAD 自分が行った変更内容 (Current Change) ======= 他の人が行った変更内容 (Incoming Change) >>>>>>> feature/other-branch ※ コンフリクトマーカーの例

Slide 78

Slide 78 text

78 ブランチ戦略とはチームでブランチをどう運⽤するかの共通ルール GitHub Flow イメージ図ブランチの使い分けを知る（ブランチ戦略） 🚀 GitHub Flow から始めようシンプルで分かりやすいため、最初の導⼊として⾮常におすすめです。 ● 構成： main + feature/xxx のみ ● ルール： featureからPRを出してmainへマージ ● メリット：常にmainがデプロイ可能な状態に保たれる

Slide 79

Slide 79 text

良い開発習慣を⾝につけよう

Slide 80

Slide 80 text

認証情報や秘匿情報はコミットするな 80 🚨 秘匿情報とは外部に漏れると重⼤な被害が出る情報 ● APIキー‧トークン ● パスワード‧秘密鍵 ● 公開されると世界中から閲覧可能になる ⚠ 削除は困難⼀度のコミットで完全削除が不可能に ● 履歴消去後もクローン済みなら⼿遅れ ● GitHubキャッシュに残る可能性 ● 漏洩時は必ずローテーション（再発⾏） ✅ 事前の対策コミットによる流出を未然に防ぐ習慣 ● .env で情報を分離 ● .gitignore で除外設定 ● gitleaks を⽤いてpre-commitによるコードスキャンを実⾏

Slide 81

Slide 81 text

コミットメッセージに種類をつける Conventional Commits の preﬁx を使うと変更の種類が⼀⽬でわかる feat: 新機能の追加 fix: バグ修正 docs: ドキュメントの変更 refactor: リファクタリング test: テストの追加‧修正 chore: ビルド設定などの変更例： feat: ログイン機能を追加、fix: メール送信エラーを修正 81

Slide 82

Slide 82 text

こまめにプルとプッシュを実⾏する 82 ✅ こまめにプル作業開始前に必ず git pull で最新の状態を取得 ● コンフリクトを最⼩限に ● 他者の変更を早期把握 🚀 こまめにプッシュキリのいい単位で git push してリモートに反映 ● PC紛失等の消失リスク回避 ● チームへの変更の早期共有 ⚠ 同期しないと… 同期を怠ると発⽣する負の連鎖 ● ⼤量のコンフリクトが発⽣ ● マージ作業が極めて複雑に ● ローカルの変更を事故で紛失

Slide 83

Slide 83 text

プルリクエストは⼩さく作る 83  PRは⼩さくするレビューの品質を⾼め、マージを迅速に ● ⽬安は変更300⾏以内 ● 1つのPRに1つの⽬的 ● 機能追加とリファクタを混ぜない  明確な説明を書く⽂脈を共有し、意図を正しく伝える ● 何を‧なぜ変更したかを簡潔に ● 関連イシュー番号をリンク ● レビュアーの負荷を軽減する  セルフレビュー提出前に⾃分のコードを客観視する ● ⾃分でdiﬀを最終確認 ● ケアレスミスを事前に修正 ● ⾃信を持ってレビュー依頼へ

Slide 84

Slide 84 text

最後に

Slide 85

Slide 85 text

まとめ ● Git = ローカルで動く分散型バージョン管理ツール ● GitHub = Gitリポジトリのホスティングサービス ● clone → pull → switch → add → commit → pushの流れを押さえる ● イシューで起票 → PRで依頼 → レビュー → マージの流れで品質を担保 ● 秘匿情報はコミットしない、コミットメッセージに種類を付ける、こまめにプルとプッシュ、PRは⼩さく作る 85

Slide 86

Slide 86 text

次に学ぶべきGit/GitHubの仕組み ● GitHub Actions：CI/CDによる⾃動化 ● GitHub Projects：タスク‧進捗の可視化 ● タグ‧リリース（tag / release）：リリースノートと配布物のパッケージ化 ● GitHub CLI（gh）：ターミナルからのGitHub操作 86

Slide 87

Slide 87 text

No content