GitHubの使い方

GitHub September 8, 2025

▶ 目次 1 GitHub とは 2 GitHub を用いた開発フロー 3 commit
message の書き方 4 branch 5 conﬂict 6 Pull Request 7 Issue 1 / 37

GitHub とは

▶ GitHub とは • 世界最大のソースコードホスティングサービス • Git を使ったバージョン管理システム • マイクロソフトが
2018 年に 75 億ドルで買収 • オープンソースプロジェクトの中心地 • コードの共有、バージョン管理、協働開発の場 2 / 37

▶ Git と GitHub の違い Git • 分散型バージョン管理システム • ローカルで動作
• コマンドライン中心 • Linus Torvalds が開発 GitHub • Git リポジトリのホスティングサービス • クラウドベース • Web UI と連携機能 • Issues/PR/Actions など追加機能 3 / 37

▶ GitHub の主要機能 Repositories コードの保存・管理場所 Issues タスク・バグ管理システム Pull Requests コードレビューと統合の仕組み
Actions CI/CD の自動化ワークフロー Pages 静的 Web サイトのホスティング Projects カンバン形式のプロジェクト管理 Discussions コミュニティとのやり取り 4 / 37

▶ GitHub の基本的な使いかた図 1: リモートリポジトリとローカルリポジトリの関係性 5 / 37

GitHub を用いた開発フロー

▶ GitHub の開発フロー Github は，品質の高いソフトウェアを高速で開発するためのツールである．よりシンプルで分かりやすい必要がある．個人的には他の開発者から見てその人が何をしているのかが分かるようにする (透明化) が最優先であると感じている． 6
/ 37

▶ 開発フローの流れ 1 main ブランチは常にデプロイできる状態とする 2 新しい作業をする場合は main ブランチから切り離して作業する 3
作業内容は定期的に push する 4 助けてほしいときやフィードバックが欲しいときは，Pull Request を作成，そこでやり取りする 5 他の開発者がレビューをし，確認したらマージする 6 マージ後は，デプロイする 7 / 37

▶ 開発フローのイメージ図 2: GitHub を用いた開発フローのイメージ図 8 / 37

▶ GitHub 開発フローにおける概念 i 常にデプロイ main ブランチは，常にデプロイ a できる状態を保つ必要がある．そのため，新しい作業を行う際には新しくブランチを作成してそこで作成，問題が完全にない場合にのみ
main ブランチにマージする．それと同時に，マージ後はすぐにデプロイbする必要がある． aデプロイとは，開発されたアプリケーションやソフトウェアを本番環境に配置し，ユーザが利用できる環境にするための作業全般を指す． bCI/CD という手法を用いることでそれを自動化することができる定期的な push 自身が作業するブランチは，他の開発者からの干渉を受けないため，気軽に push することができる． Pull Request を使う Pull Request は，差分確認やコードに対してコメントを入れることができる．そのため，自分が分からない点や他の人に質問したい場合に利用することができる． 9 / 37

▶ GitHub 開発フローにおける概念 ii コードレビュー Pull Request では，自分自身でマージすることができる．しかし，自分が見落としていた問題点や他の人から見たら問題がある場合もあるため，他の人がレビュー・マージをすることが望ましい． 10
/ 37

commit message の書き方

▶ commit message とは commit message とはこのメッセージでは，他の人に対してどのような変更を行ったかを説明するためのメッセージである．そのため，コードの変更部分を直接見なくてもこのメッセージを見ただけで変更箇所が分かるように記述するべきである．
Listing 1: commit message の書き方 1 <type>(<scope>): #<Issue Number> <subject> 2 1 行空ける 3 <body> 4 5 <footer> 11 / 37

▶ type Type Description Example feat 新機能新しいボタンを追加 ﬁx バグ修正
ボタンが反応しない問題を修正 docs ドキュメント変更 README.md を更新 style スタイル変更コードのフォーマットを修正 refactor リファクタリングコードの構造を改善 test テスト追加新しいテストケースを追加 chore その他の変更ビルドプロセスを更新 perf パフォーマンス改善に関する変更コードのパフォーマンス向上 build ビルドシステムや外部関係の変更依存関係の変更 ci 継続的インテグレーションに関する変更 CI/CD 設定の更新 revert 直線のコミットを取り消す変更 git revert コマンドで生成されるコミット 12 / 37

▶ commit message の各部分紹介 i scope 変更が影響する範囲を示す要素．例えば，特定のモジュールやコンポーネントの名前を使用することが一般的であるが省略しても構わない． Issue number
関連する Issue やタスクの番号を含めることで，変更がどの問題に関連しているかを明確にする． subject 変更の要約を示す要素．30 文字以内を推奨とし，命令系かつ具体的に記述する． 13 / 37

▶ commit message の各部分紹介 ii body 変更した理由や変更内容などを詳細に記述する．複数行にわたっても構わないので誰が見ても分かりやすい文章にするべきである． Listing 2:
commit message の具体例 1 feat(user): #10 ユーザー登録機能を追加 2 3 ユーザーがメールアドレスとパスワードでアカウントを作成できるようにしました。入力 validation やエラーハンドリングも実装済みです。 → 14 / 37

branch

▶ branch とは branch とは，別々の作業を並行して行うために利用する機能である．基本的には，同じファイル等を同時に編集する際にマージやコンフリクトの回数を減らすため利用する．ブランチでの作業が終了すると main ブランチにマージする．また，各ブランチが何を行っているのかを把握しやすくするために特定の機能や修正のみの作業を行うこともある．
図 3: branch のイメージ図 15 / 37

▶ branch を切る branch branch には，以下のコマンドがある． • git branch <branch-name>
: 新しいブランチを作成 • git switch <branch-name> : 指定したブランチに切り替え図 4: branch を切る図 16 / 37

▶ merge main ブランチから派生したブランチは， git merge <branch-name> コマンドを使用して main ブ
ランチにマージすることができるが，基本的には GitHub 上のサイトで行う．図 5: branch を merge する図 17 / 37

conﬂict

▶ conﬁlct の概要図 6: branch の conﬂict のイメージ図 18
/ 37

▶ conflict とは conflict の定義 conflict とは，複数の開発者が同じファイルの同じ部分を異なる方法で変更した場合に発生する状態である．この状態になると，手動による merge が必要となる．
• 複数のブランチで同じファイルの同じ行を編集 • rebase や merge 時に発生 • チーム開発では頻繁に発生する一般的な状況 19 / 37

▶ conﬂict が発生する状況典型的なコンフリクト状況: • 同じファイルの同じ行を複数人が編集 • branch が長期間分岐したまま •
rebase と merge の混在 • ファイルの削除と変更の競合 20 / 37

▶ conﬂict の解消方法 i conﬂict が発生すると、ファイルには特殊なマーカーが挿入される Listing 3: コンフリクトマーカーの例 1
«««< HEAD 2 現在のブランチでの変更内容 3 ======= 4 マージしようとしているブランチでの変更内容 5 »»»> feature-branch 21 / 37

▶ conﬂict の解消方法 ii 解消の手順 1 エディタでファイルを開き、コンフリクトマーカーを探す 2 両方の変更を検討し、最終的にどうすべきか決定 3
マーカー（«««< HEAD、=======、»»»> feature-branch）を削除 4 修正したファイルを保存 22 / 37

▶ conﬂict の解消方法 i 図 7: conﬂict 発生画面 23 /
37

▶ conﬂict の解消方法 ii 図 8: コンフリクト解消画面 24 / 37

▶ conﬂict の解消方法 iii 図 9: コンフリクト解消後の画面 25 / 37

▶ コンフリクトを減らすためのベストプラクティス予防策と対策 • 小さな単位での頻繁なマージ: 長期間のブランチ分岐を避ける • 明確な役割分担: 同じファイルを複数人で同時に編集しない •
事前のコミュニケーション: 大きな変更は事前に共有する • コードのモジュール化: ファイルを機能ごとに分割し依存関係を減らす • 定期的なリベース: 最新の main ブランチの変更を取り込む • PR のサイズを小さく: レビュー・マージのサイクルを早くする 26 / 37

Pull Request

▶ Pull Request とは i 図 10: Pull Request のイメージ図
27 / 37

▶ Pull Request とは ii 基本概念 Pull Request とは，あるブランチの変更を統合する前に，コードレビューや議論を行うための機能である．
• 変更内容を他のチームメンバーに共有し、レビューを受ける場 • コードの品質保証とバグの早期発見に貢献 • 知識の共有とチーム全体のスキル向上を促進 • CI/CD パイプラインと連携して自動テスト・検証を実行 28 / 37

▶ Pull Request の流れ 1 変更箇所の確認: 差分を確認し，変更の意図を理解する 2 コメント: 質問や提案を具体的な箇所に対して行う
3 議論: 提案された修正について建設的に議論する 4 修正: フィードバックに基づいてコードを修正する 5 承認: レビュアーが変更を承認する図 11: Pull Request の流れ 29 / 37

▶ 効果的な Pull Request 良い Pull Request の特徴 1 目的が明確:
タイトルと説明で何をなぜ変更したのかが明確 2 適切なサイズ: レビューしやすい範囲に収まっている（目安: 300〜500 行以内） 3 単一の責任: 一つの PR で一つの機能や修正に集中 4 テスト済み: 変更に対応するテストが含まれている 5 自己レビュー済み: 提出前に自分でレビューを行っている 30 / 37

▶ Issue とは Issue とは，バグやタスク，改善点などを管理するための機能である．Issue を使うことで，プロジェクトの進行状況を GitHub 上でも管理することができる．また，チケットと呼ばれる単位を使って管理する．
Issue には以下のような機能がある． 1 担当者の割り振り 2 締め切り (Milestone) の設定 3 ラベルを使った分類 4 Pull Request との関連付け 31 / 37

▶ Issue の作り方 i 図 12: Issue 画面 32 /
37

▶ Issue の作り方 ii 図 13: Issue の作成画面 33 /
37

▶ Issue の作り方 iii 図 14: Issue 作成後の画面 34 /
37

▶ Issue の書き方 Issue を活用することで，以下のようなメリットがある． • 概要 • 目的 •
タスク • 補足 35 / 37

▶ Issue の書き方例 Listing 4: Issue の書き方例 1 ## 概要
2 拡張機能のポップアップ画面から、プレビュー機能の ON/OFF を切り替えられるスイッチを新設する。 3 4 ## 目的 5 ユーザーが拡張機能管理ページを開くことなく、手軽に機能の有効/無効を切り替えられるようにし、利便性を向上させる。 → 6 7 ## タスク 8 - [ ] ポップアップ用の HTML ( popup.html ) を作成する。 9 - [ ] ON/OFF の状態を保存・読み込みするロジックを実装する ( chrome.storage を使用)。 10 - [ ] スイッチの状態に応じて content.js の動作を制御する仕組みを実装する。 11 12 ## 補足 13 - スイッチのデザインについては、別途 Figma で共有します。 36 / 37

▶ 最後に GitHub を使いこなすことで，ただのソースコード共有ツールから，チーム開発の中心的なプラットフォームへと進化させることができる．そのためには，使い方や規則等をチーム内で統一が必要である． 37 / 37

GitHubの使い方

GitHubの使い方

More Decks by ユート

Other Decks in Technology

Featured

Transcript