Handism's Tech Blog
学習ガイド一覧へ戻る

GitHub入門

ローカルのGit操作からGitHub上でのプルリクエスト、チーム開発のワークフローまで図解でスムーズに理解します。

学習をスタートする

ロードマップ

1

GitHubを用いた開発の流れ

GitHubは、Gitを利用したソースコードの管理や、チーム開発を円滑に行うためのWebサービスです。 第1章では、GitとGitHubの役割の違いを整理し、現場で最もよく使われている「GitHubを用いたチーム開発の基本的な流れ（ワークフロー）」を図解します。 1. Git と GitHub の違い よく混同されますが、この2つの役割は明確に異なります。 * Git: ファイルの変更履歴をローカル（自分のパソコン内）で管理するための ツール（プログラム）。 * GitHub: 複数人でコードを共有し、レビューやマージを行うための Webサービス（プラットフォーム）。 2. 開発全体のワークフロー（図解） ローカルPCでの作業から、GitHubにコードをアップロードし、メインのコードへ統合（マージ）するまでの全体の流れを可視化した図です。 3. 各ステップの詳細解説 実際の開発現場では、以下の手順（GitHub Flowと呼ばれるシンプルな手順）に沿って進めます。 Step 1. ブランチを切る（作成する） 新しくコードを追加したりバグを修正したりするときは、いきなりメインのブランチ（main / master）を書き換えず、専用の「作業用ブランチ（例: feature-login-page）」を作成します。 Step 2. コードを編集してコミットする 作業ディレクトリでコードを書き終えたら、変更したファイルを履歴に登録（コミット）します。 Step 3. GitHubへプッシュする ローカルの変更履歴を、GitHub上にあるリモートリポジトリへ送信（アップロード）します。 Step 4. プルリクエスト（PR）を作成する GitHub上で「このブランチの変更を、メインのコード（main）に合流させてもいいですか？」という提案を作成します。これを プルリクエスト（Pull Request） と呼びます。 Step 5. レビュー ＆ 修正 チームのメンバーがあなたのコードを読み、問題がないか、もっと良い書き方がないかをチェック（コードレビュー）します。指摘があれば修正し、再度プッシュします。 Step 6. マージする レビューが通り、安全であることが確認されたら、プルリクエストを承認（マージ）してメインのコードに統合します。これであなたのコードが正式に本番環境に反映されます！ まとめ GitHubでの開発は、「ブランチを作成し、コミットしてプッシュ、プルリクエストでレビューを受け、最後にマージする」 というサイクルを繰り返すことで、安全かつスピーディにチーム開発を進めることができます。 次のステップに進んで、実際のGitコマンドや競合（コンフリクト）の解決方法について学んでいきましょう！

2

コンフリクト（衝突）の仕組みと解決方法

複数人で同じリポジトリを使って開発を進めていると、必ず遭遇するのが 「コンフリクト（Conflict：衝突）」 です。 コンフリクトが発生すると「壊してしまったのでは？」と焦るかもしれませんが、Gitが安全にマージを行うためのごく自然な仕組みです。 第2章では、コンフリクトがなぜ起きるのか、その仕組みと安全な解決方法を図解します。 1. コンフリクトとは？ Gitは通常、別々のファイルへの変更や、同じファイルであっても異なる行への変更であれば、自動的に1つに統合（マージ）してくれます。 しかし、「同じファイルの、全く同じ行」に対して、別々の変更が同時に行われた場合、Gitはどちらの変更を採用すべきか判断できません。この時、Gitは自動マージをストップし、ユーザーに「どちらを残すか決めてください」と指示を出します。これがコンフリクトです。 2. コンフリクトが発生する流れ（図解） コンフリクトがどのようなプロセスで発生するのか、時系列で表した図です。 1. 共通のコミット A から、開発者A（feature-alpha）と開発者B（feature-beta）がブランチを切ります。 2. それぞれ同じファイルの同じ行（例：10行目）を、異なるテキストに書き換えてコミットします。 3. 先に feature-alpha が main ブランチにマージされます（この時点ではまだ競合はありません）。 4. 次に feature-beta を main にマージしようとした際、Gitは「10行目がすでに Hello になっているのに、World に上書きしようとしている」と検知し、マージを中断してコンフリクトを報告します。 3. コンフリクトマーカーの読み方 コンフリクトが発生したファイルを開くと、Gitによって以下のような特殊な記号（コンフリクトマーカー）が挿入されています。 * >>>>>> [ブランチ名] まで： 取り込もうとしているブランチ（競合した相手）の変更内容。 4. コンフリクトの解決ステップ コンフリクトの解決は、エディタでファイルを修正して「正しい状態」にし、再度コミットする流れで行います。 Step 1. 競合箇所を確認し、不要なコードと記号を削除する VS Codeなどのモダンなエディタを使用している場合、UI上で「現在の変更を取り込む」「入力側の変更を取り込む」「両方の変更を取り込む」といったボタンが表示されます。 手動で修正する場合は、>>>>>> のマーカー自体をすべて削除し、プログラムとして正しい形にコードを書き換えます。 Step 2. 修正したファイルをステージングする 修正が完了し、テストが通ることを確認したら、解決したことをGitに伝えます。 Step 3. マージコミットを作成する 通常のマージの続きとしてコミットを実行します。 これでコンフリクトの解消とマージが完了します！ まとめ * コンフリクト は、同じファイルの同じ行に対して異なる変更が同時に行われたときに発生する。 * Gitは勝手にコードを上書きせず、コンフリクトマーカー を挿入して人間に判断を委ねる。 * 解決する時は、マーカー記号をすべて消して正しいコードに編集し、git add & git commit を行う。

3

GitHub Actionsによる自動テスト（CI）入門

現代のソフトウェア開発では、コードの変更が既存の機能を壊していないかを確認するために、自動化されたテストやビルドの仕組みを導入するのが一般的です。これを CI/CD（継続的インテグレーション／継続的デリバリー） と呼びます。 GitHubには、このCI/CDを簡単に構築できる機能 GitHub Actions（ギットハブ・アクションズ） が標準搭載されています。 第3章では、GitHub Actionsの基本概念と、プルリクエスト作成時に自動テストを実行するワークフローの作り方を解説します。 1. CI（継続的インテグレーション）とは？ 新しいコードをメインブランチにマージする前に、自動的に「ビルド」「構文チェック（Lint）」「ユニットテスト」を実行し、問題がないことを継続的に検証するプロセスです。 人間による手動テストの漏れを防ぎ、バグの早期発見につながります。 2. GitHub Actions による自動テストフロー（図解） 開発者がコードをプッシュしてからマージされるまでの自動化の流れです。 3. ワークフローファイルの基本構成 GitHub Actionsの設定は、リポジトリの特定のフォルダ（.github/workflows/）の中に YAML 形式（.yml）のファイルとして保存します。 * Workflows（ワークフロー）: 自動化されるプロセス全体。 * Events（イベント）: ワークフローを起動するトリガー（例：push、pull_request）。 * Jobs（ジョブ）: 同じマシン（仮想環境）で実行されるステップの集まり。デフォルトで並列実行されます。 * Steps（ステップ）: コマンドの実行やアクションの呼び出しを行う最小単位。上から順に実行されます。 * Actions（アクション）: よく使われるステップをパッケージ化した共有モジュール（例：チェックアウト処理など）。 4. 自動テストを実行する設定ファイルの例 以下は、Node.js プロジェクトでプルリクエストが作成された際に、自動テストを走らせる標準的な設定ファイルです。 このファイルを .github/workflows/ci.yml としてリポジトリにコミットしておくと、GitHubは自動的に検知し、プルリクエストの画面に進捗やテスト結果が表示されるようになります。 まとめ * GitHub Actions は、GitHubに統合された強力なCI/CDツール。 * .github/workflows/ 内の YAMLファイル で自動化の手順を定義する。 * プルリクエスト等の イベントをトリガー にして、クラウド上の仮想マシンでテストやビルドを自動実行できる。 自動化を導入することで、コードの品質を保ちながら、安全かつスピーディにチーム開発を進めることができます！

4

プルリクエストとコードレビューの実践

GitHubを用いた共同開発の中心となるのが、「プルリクエスト（Pull Request: PR）」 と 「コードレビュー（Code Review）」 です。これらは単にソースコードの誤り（バグ）を見つけるだけでなく、コード品質の均一化、知識共有、保守性の高いプロダクト作りにおいて強力な手段となります。 第4章では、開発チームで円滑かつ安全にプルリクエストとコードレビューを回すための手法について学びます。 1. 良いプルリクエストの作成方法 プルリクエストは、レビュアー（レビューをする人）への手紙のようなものです。レビュアーが「何を」「なぜ」「どのように」変更したかを理解しやすいように記述することが、迅速で正確なマージへの近道です。 * 明確なタイトルと説明: 目的（ユーザーの課題解決など）を明記し、可能であれば「修正前後のスクリーンショット」や「動作確認手順」を掲載します。 * 小さく分ける（スモールPR）: 1つのPRにおける変更行数が多すぎると、レビューの精度が落ち、時間もかかります。1つのPRは「1つの課題やタスク」に焦点を当てるように細分化します。 2. コードレビューの作法とステータス レビュー担当者は、コードの変更点を確認し、以下のいずれかのステータスを提示します。 * Approve (承認): 変更内容に問題がなく、マージして良いと判断した場合に選択します。 * Request Changes (要修正): バグや規約違反などがあり、マージ前に修正が必要な場合に選択します（これによってPRのマージがブロックされます）。 * Comment (コメント): 承認でも却下でもなく、質問や軽微な提案などを伝える場合に使用します。 レビューのコミュニケーション * 敬意と思いやり: 「〜を修正してください」ではなく、「〜した方がバグを防げそうですが、いかがでしょうか？」のように、人格への攻撃ではなくコードに焦点を当てた前向きなコミュニケーションを心がけます。 3. ブランチ保護ルール (Branch Protection) チーム開発において、誰かがうっかり誤ったコードを main ブランチに直接プッシュしてしまうと、リリースされているシステムが壊れてしまいます。これを防ぐのが Branch Protection Rules (ブランチ保護ルール) です。 この設定により、ルールに適合しないPRは Merge ボタンが非活性となり、不正なコードの本番混入を防ぐガードレールとなります。

5

GitHub Projectsと開発環境の標準化

GitHubは単なるソースコードの共有ツールではありません。Issue（課題管理）、Projects（プロジェクト管理ボード）、そしてCodespaces（クラウド開発環境）を組み合わせることで、要件定義からコーディング、進捗追跡までを一元管理する強力なプラットフォームとなります。 第5章では、GitHubによるプロジェクト管理と開発環境の標準化について解説します。 1. IssueとGitHub Projectsによる進捗管理 ソフトウェア開発を円滑に進めるためには、タスクやバグを追跡可能な形にする必要があります。 GitHub Issues バグ報告、新機能の提案、リファクタリングなどを記録するチケットです。Markdownで詳細な要件やチェックリストを記述し、メンバー（Assignee）を割り当てます。 GitHub Projects アジャイル開発における「かんばん（Kanban）」ボードとして、Issueやプルリクエストの状況をビジュアル管理します。 * Todo: 着手前のタスク * In Progress: 開発中のタスク * Done: 完了したタスク PRの説明欄に Closes #12 のように記述しておくと、PRが main ブランチにマージされた瞬間に、該当するIssueが自動的にクローズ（解決）され、Projectボードも「Done」へ自動で遷移する仕組みがあります。 2. GitHub CLI (gh) によるコマンド操作 ターミナルからブラウザを開くことなくGitHubの操作を行えるのが GitHub CLI (gh コマンド) です。 これにより、開発者のエディタとターミナル間でのコンテキストスイッチ（切り替え）を抑え、コマンドラインで素早く作業を進められます。 3. GitHub Codespacesによる環境構築の排除 新しいメンバーがチームに入った際、環境構築（Node.jsやDBのインストール、バージョンの違いなど）で何日も浪費してしまうことがあります。この問題を解決するのが GitHub Codespaces です。 リポジトリ直下の .devcontainer/ ディレクトリに設定ファイルを配置することで、クラウド上に標準化された開発コンテナ環境を即時立ち上げることができます。 開発者はGitHubのページで「Create codespace」をクリックするだけで、ブラウザ上のVS Code（またはローカルのVS Code）が起動し、すでに必要なライブラリがインストールされ、ポートのフォワーディングも完了した状態ですぐにコーディングを開始できます。