攻略法
GitHubでチーム開発の流れを体験してみよう！ - ハンズオンガイド
はじめに
この記事では、GitHubを使ったチーム開発の流れを一緒に体験してみましょう。ハッカソンは複数人でプロダクトを開発する場なので、GitHubの基本的な使い方とチーム開発の流れを知っておくとスムーズに開発を進められます。プログラミング初心者の方や、GitHubを使ったことがない方でも理解できるよう、丁寧に説明していきます。
目次
- Gitとは？GitHubとは？
- GitHubの基本概念を理解しよう
- 環境準備：GitHubアカウント作成とGitのインストール
- リポジトリの作成とクローン
- 変更を加えてコミットする
- ブランチの作成と作業
- プルリクエストの作成とレビュー
- マージとコンフリクト解決
- チーム開発でのコミュニケーション
- まとめ：ハッカソンでの実践ポイント
1. Gitとは？GitHubとは？
Gitとは
Gitは「バージョン管理システム」です。ファイルの変更履歴を記録し、過去の状態に戻したり、複数人での並行作業を可能にするツールです。例えるなら、Wordの変更履歴機能を超強力にしたようなものです。
GitHubとは
GitHubはGitを利用したウェブサービスで、Gitリポジトリ（プロジェクトのフォルダとその履歴）をインターネット上で共有・管理できるプラットフォームです。「コードのSNS」とも呼ばれ、世界中の開発者が利用しています。
なぜチーム開発にGitHubが必要なのか？
チーム開発では、以下のような課題が発生します：
- 複数人が同時に同じファイルを編集したい
- 誰がいつどのコードを変更したか記録しておきたい
- 作業中の変更を他の人の作業に影響なく進めたい
- コードレビューをして品質を保ちたい
GitHubはこれらの課題を解決する機能を提供しています。
2. GitHubの基本概念を理解しよう
GitHubを使う前に、基本的な概念を理解しておきましょう。
リポジトリ（Repository）
プロジェクトのファイルとその変更履歴をまとめて格納する場所です。フォルダのようなもので「レポジトリ」と呼ばれることもあります。
コミット（Commit）
変更内容をリポジトリに記録することです。「スナップショットを撮る」と考えるとわかりやすいでしょう。各コミットには説明文（コミットメッセージ）を付けて、何を変更したのか記録します。
ブランチ（Branch）
開発の流れを分岐させる機能です。メインの開発ラインから枝分かれさせて、独立して作業できます。例えるなら、小説を書いていて「別のエンディングも試してみよう」と分岐させるようなものです。
プルリクエスト（Pull Request）
あるブランチでの変更を別のブランチに取り込む提案です。「私のブランチの変更内容を確認して、問題なければマージしてください」という依頼と考えてください。コードレビューの場としても機能します。
マージ（Merge）
プルリクエストで提案された変更を、ターゲットブランチに統合することです。例えば、機能開発用のブランチの変更を、メインのブランチに取り込むといった使い方をします。
クローン（Clone）
リモート（GitHub上）のリポジトリを自分のコンピュータ（ローカル）にコピーすることです。これにより、ローカルでコードを編集できるようになります。
プッシュ（Push）
ローカルで行った変更をリモートリポジトリに送信することです。自分の変更を他の開発者と共有する際に使用します。
プル（Pull）
リモートリポジトリの最新の変更を自分のローカルリポジトリに取り込むことです。他の開発者の変更を自分の環境に反映する際に使用します。
3. 環境準備：GitHubアカウント作成とGitのインストール
GitHubアカウントの作成
- GitHubにアクセスします
- 「Sign up」ボタンをクリックします
- メールアドレス、パスワード、ユーザー名を入力します
- 画面の指示に従って登録を完了させます（メール認証などが必要です）
Gitのインストール
Windows:
- Git for Windowsから最新版をダウンロードします
- ダウンロードしたインストーラーを実行します
- 基本的にはデフォルト設定のままで「Next」をクリックしていきます
Mac:
- ターミナルを開きます（DockのLaunchpadアイコンをクリックし、検索フィールドに「ターミナル」と入力してください）
- 以下のコマンドを実行します（Homebrewがインストールされている場合）
または、Gitの公式サイトからインストーラーをダウンロードします
brew install git
Homebrewは開発にすごい役に立つので今後のためにもインストールしましょう！
Linux:
-
ターミナルを開きます
-
Ubuntuの場合は以下のコマンドを実行します
sudo apt-get updatesudo apt-get install git
Gitの初期設定
ターミナル（WindowsならGit Bash）で以下のコマンドを実行し、ユーザー名とメールアドレスを設定します：
git config --global user.name "あなたの名前"
git config --global user.email "あなたのメールアドレス"
この設定は、あなたが行った変更に「誰が行ったのか」を記録するために必要です。
SSHの設定
Githubのレポジトリを操作するときにSSH（秘密鍵）の設定が必須です。
各OSに合わせてレポジトリを設定していきましょう。
Windows
https://zenn.dev/aoikoala/articles/388eb861249780
Mac
https://zenn.dev/konru/articles/mac_github_ssh_setting
4. リポジトリの作成とクローン
リポジトリの作成
-
GitHubにログインします
-
右上の「New」を選択します
-
リポジトリの詳細を入力します：
- リポジトリ名（例:
my-hackathon-project） - 説明（任意）
- 公開設定（「Public」か「Private」）
- 「Initialize this repository with a README」にチェックを入れる
- リポジトリ名（例:
-
「Create repository」ボタンをクリックします
これで、あなたのプロジェクトのための「箱」ができました！
リポジトリのクローン
作成したリポジトリをあなたのパソコンにダウンロード（クローン）しましょう：
-
リポジトリページで緑色の「Code」ボタンをクリックします
-
HTTPSのURLをコピーします
-
ターミナル（WindowsならGit Bash）を開きます
-
作業したいディレクトリに移動します（例:
cd Documents） -
以下のコマンドを実行します：
git clone git@github.com:あなたのユーザー名/my-hackathon-project.git
- クローンしたフォルダに移動します：
cd my-hackathon-project
これで、リポジトリのクローンが完了しました。次に、このリポジトリに変更を加えてみましょう。
5. 変更を加えてコミットする
変更を加える
まずは単純な変更として、READMEファイルを編集してみましょう：
-
好きなテキストエディタ（VScodeやCursorなど）で「README.md」を開きます
-
何か内容を追加します。例えば：
# My Hackathon Projectこれは関西ビギナーズハッカソンのためのプロジェクトです。
チームメンバー
あなたの名前
-
ファイルを保存します
変更をステージングする
変更したファイルをGitの「ステージングエリア」に追加します。ステージングとは、次にコミットする変更を指定する作業です。
git add README.md
すべてのファイルをステージングするには：
git add .
変更の状態を確認する
現在の変更状態を確認するには：
git status
緑色で表示されるファイルはステージングされたもの、赤色は変更されているがステージングされていないファイルです。
変更をコミットする
ステージングした変更をリポジトリに記録（コミット）します：
git commit -m "READMEを更新：プロジェクト説明とメンバー情報を追加"
mオプションの後に続く文字列がコミットメッセージです。変更内容を簡潔に説明しましょう。
変更をGitHubにプッシュする
ローカルでのコミットをGitHub（リモート）にアップロードします：
git push origin main
originはリモートリポジトリの名前（デフォルト）、mainはブランチ名です。
これでGitHubのリポジトリページを更新すると、変更が反映されているはずです！
6. ブランチの作成と作業
実際のチーム開発では、メインブランチ（main）に直接変更を加えるのではなく、機能ごとに別のブランチを作成して作業するのが一般的です。
ブランチを作成して切り替える
新機能のためのブランチを作成しましょう：
git checkout -b feature/add-homepage
このコマンドは「feature/add-homepageという名前の新しいブランチを作成し、そのブランチに切り替える」という意味です。
ブランチ名は「何の作業をするブランチか」がわかるようにするのが良いでしょう。
ブランチでの作業
新しいブランチで作業を行います：
- 例として、
index.htmlという新しいファイルを作成します：
<!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>My Hackathon Project</title> </head> <body> <h1>Welcome to My Hackathon Project!</h1> <p>This is a sample project for the Kansai Beginners Hackathon.</p> </body> </html>
- 変更をステージングしてコミットします：
git add index.html git commit -m "Add simple homepage"
ブランチをGitHubにプッシュする
作成したブランチをGitHubにプッシュします：
git push -u origin feature/add-homepage
初めてブランチをプッシュする場合は-uオプションをつけます。これにより、このブランチとリモートブランチが「追跡」関係になります。
7. プルリクエストの作成とレビュー
ブランチでの作業が完了したら、その変更をメインブランチ（main）に統合するために「プルリクエスト」を作成します。
プルリクエストの作成
- GitHubのリポジトリページに移動します
- 表示される「Compare & pull request」ボタンをクリックします（表示されない場合は「Pull requests」タブから「New pull request」をクリック）
- 以下の情報を入力します：
- タイトル（例: 「Add homepage」）
- 説明（何を変更したか、なぜ変更したかなど）
- 「Create pull request」ボタンをクリックします
プルリクエストのレビュー
実際のチーム開発では、プルリクエストに対して他のメンバーがレビューを行います：
- 「Files changed」タブで変更内容を確認します
- 特定の行にコメントするには、その行の左側にマウスを合わせて表示される「+」をクリックします
- 全体的なレビューを行うには「Review changes」ボタンをクリックし：
- 「Approve」（承認）
- 「Request changes」（変更を要求）
- 「Comment」（単にコメントする）
のいずれかを選択します
プルリクエストの修正
レビューで指摘された場合は、ローカルで修正してプッシュします：
- 同じブランチで修正を行います
- 変更をコミットしてプッシュします
- 自動的にプルリクエストに反映されます
8. マージとコンフリクト解決
プルリクエストのマージ
レビューが完了したら、プルリクエストをマージします：
- プルリクエストページの「Merge pull request」ボタンをクリックします
- マージコミットのメッセージを確認し、「Confirm merge」をクリックします
- マージが完了すると、ブランチを削除するオプションが表示されます
これで、ブランチでの変更がメインブランチに統合されました！
コンフリクトとは
コンフリクト（競合）は、複数の人が同じファイルの同じ箇所を異なる方法で変更した場合に発生します。Gitは自動的に解決できないため、手動で解決する必要があります。
コンフリクトを体験してみる
コンフリクトを擬似的に体験してみましょう：
-
メインブランチに戻ります：
git checkout main -
最新の変更を取得します：
git pull -
新しいブランチを作成します：
git checkout -b feature/update-title -
index.htmlの<title>タグを変更します：<title>Our Awesome Hackathon Project</title> -
変更をコミットしてプッシュします：
git add index.html git commit -m "Update page title" git push -u origin feature/update-title -
別のブランチも作成します：
git checkout main git checkout -b feature/add-description -
同じ
index.htmlの同じ部分を別の内容に変更します：<title>Kansai Beginners Hackathon Project</title> -
こちらもコミットしてプッシュします：
git add index.html git commit -m "Update title with event name" git push -u origin feature/add-description -
GitHubで両方のブランチからプルリクエストを作成します
-
最初のプルリクエストをマージします
-
2つ目のプルリクエストではコンフリクトが表示されます
コンフリクトの解決方法
- 「Resolve conflicts」ボタンをクリックするか、ローカルでコンフリクトを解決します
Resolve Conflictsをクリックした後の画面↓
-
ローカルで解決する場合：
git checkout feature/add-description git pull origin main -
コンフリクトが発生すると、ファイルには以下のようなマーカーが挿入されます：
<<<<<<< HEAD <title>Kansai Beginners Hackathon Project</title> ======= <title>Our Awesome Hackathon Project</title> >>>>>>> main -
マーカーを削除し、残したい内容にします：
<title>Kansai Beginners Awesome Hackathon Project</title>
-
解決した変更をコミットしてプッシュします：
git add index.html git commit -m "Resolve title conflict" git push -
GitHubのプルリクエストページに戻ると、コンフリクトが解決されているはずです
9. チーム開発でのコミュニケーション
Issuesの活用
GitHubの「Issues」機能は、タスク管理、バグ報告、機能要望などに使用できます：
- リポジトリページで「Issues」タブをクリックします
- 「New issue」ボタンをクリックします
- タイトルと説明を入力します：
- タイトル（例: 「ナビゲーションメニューの追加」）
- 説明（タスクの詳細、期待される結果など）
- ラベル、担当者、マイルストーンなどを設定できます
- 「Submit new issue」ボタンをクリックします
プロジェクトボードの活用
GitHubの「Projects」機能を使って、カンバンボード形式でタスク管理ができます：
カンバンボードの追加方法
- リポジトリページで「Projects」タブをクリックします
- 「Create a project」ボタンをクリックします
- プロジェクト名と説明を入力します
- テンプレートとして「Basic kanban」を選択します
- 「Create project」ボタンをクリックします
- 作成したプロジェクトボードにIssuesを追加できます
カンバンボードに新しいIssueを追加する方法
- 追加したい列にある＋ボタンを押す
- Create New Issueをクリック
- Repositoryを自分たちのレポジトリに指定
- Blank Issueをクリック
- 項目を書いてCreateを押す
カンバンに既存のIssueを追加する方法
- 追加したい列にある＋ボタンを押す
- 追加したいIssueを選ぶ
- Add Selected Itemsを押す
効果的なコミュニケーションのためのポイント
- 明確なIssueを作成する：何を実装するのか、どのような問題があるのかを具体的に記述します
- コミットメッセージは具体的に：「修正」ではなく「ナビゲーションメニューのリンク切れを修正」のように具体的に書きます
- プルリクエストには十分な情報を：変更内容、テスト方法、スクリーンショットなどを含めると、レビュワーが理解しやすくなります
- コードレビューはポジティブに：批判ではなく建設的なフィードバックを心がけます
10. まとめ：ハッカソンでの実践ポイント
チーム開発の効率的なワークフロー
- 最初の打ち合わせ：リポジトリ作成、作業分担、ブランチ戦略を決める
- Issueベースの開発：タスクごとにIssueを作成し、担当者を割り当てる
- ブランチ命名規則：「feature/機能名」や「fix/バグ名」など、何の作業をするブランチかわかるようにする
- 小さく頻繁にコミット：大きな変更を一度に行うのではなく、小さな変更を頻繁にコミットする
- 定期的なプルリクエストとマージ：長時間ブランチを分けたままにせず、小さな機能単位でマージする
- コミュニケーションを維持：進捗状況、問題点、アイデアを常に共有する
チームでの役割分担の例
- リポジトリ管理者：リポジトリの設定、権限管理、マージの最終承認を担当
- レビュワー：プルリクエストのレビューを担当
- 開発者：担当機能の実装を行う
- テスター：実装された機能のテストを担当
よくあるトラブルと解決策
- コンフリクト：頻繁にプルして最新の変更を取り込む習慣をつける
- コミュニケーション不足：定期的な進捗報告、問題点の共有を行う
- ブランチの混乱：命名規則を統一し、不要になったブランチは削除する
- マージミス：重要なブランチへのマージは必ずレビューを経てから行う
実践演習：ミニプロジェクト
- 3-4人でチームを組みます
- 共同で簡単なウェブページを作成します：
- ホームページ
- チーム紹介ページ
- お問い合わせフォーム
- 各機能をIssueとして登録し、担当者を決めます
- 各自がブランチを作成して開発を進めます
- プルリクエストを作成し、レビューを行います
- マージしてプロジェクトを完成させます
これでGitHubを使ったチーム開発の基本的な流れが理解できたと思います。実際にハッカソンで使う際には、チームメンバーと事前に運用ルールを決めておくと、スムーズに開発を進められるでしょう。
何か質問や不明点があれば、いつでも聞いてください！GitHub初心者の方も多いと思いますので、わからないことは遠慮なく質問してくださいね。
がんばって素晴らしいプロダクトを作り上げましょう！
Shin Yamamoto