🐙 GitHub入門 | Handism's Tech Blog

1

GitHubを用いた開発の流れ

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

2

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

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

3

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

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

GitHub入門

🗺️ ロードマップ

GitHubを用いた開発の流れ

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

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