はじめに
今回は、GitHubを使ったチーム開発の流れを、自分への備忘録も兼ねて体系的にまとめてみます。
GitコマンドやGitHubの操作は、定期的に意識して振り返らないと、忘れてしまいがちです。
この機会に、基礎的な内容を記事としてまとめ、振り返っていこうと思います。この記事が誰かの技術の参考になれば幸いです！
書こうと思ったきっかけ
現在受講しているITスクールのチーム開発（ハッカソン）に参加するにあたり、忘れかけていたGitHubでのチーム開発の知識を整理しようと考えました。
引用画像：https://www.ricksoft.jp/blog/articles/001410.html
これまで、基本的には1人で開発することが多く、その際は直接メインブランチにプッシュする方法で管理していました。
しかし、チーム開発では、4～5人のチームで1つのリポジトリを共有して作業する必要があります。
そのため、ブランチの設定や作成方法、マージのタイミングなどを改めて整理し、記事としてまとめることにしました！
1. リポジトリの準備
まず、GitHubで新しいリポジトリを作成します。詳しい作成方法については、以下の記事を参考にしてください。
リポジトリの作成が完了すると、初期ブランチ（通常は main）が自動的に作成されます。
次に、チームメンバーがローカル環境でリポジトリを使用できるよう、以下のコマンドでリポジトリをクローンします。
git clone <リポジトリのURL>
cd <リポジトリ名>
2. ブランチを作成する
自分の作業内容に応じて、新しいブランチを作成します。以下のコマンドを使用してください。
git checkout -b <ブランチ名>
例: test
作成したブランチをリモートリポジトリにプッシュします。
git push -u origin <ブランチ名>
リモートリポジトリに新しいブランチが保存されたことを確認できます。
3. 作業内容をコミットする
変更内容の確認
ファイルを編集後、現在の変更内容を確認します。
git status
今回は、まだファイルの追加や編集を行っていないため、以下のような出力になります。
➜ GitHub-test git:(test) git status
On branch test
Your branch is up to date with 'origin/test'.
nothing to commit, working tree clean
➜ GitHub-test git:(test)
ファイルの作成
適当な空ファイルを作成して変更を試します。
touch test
変更のステージング
必要な変更をステージに追加します
## 特定のファイルを追加する場合
git add <ファイル名>
## すべての変更を追加する場合
git add .
変更内容をコミット
適切なメッセージを添えてコミットします。
git commit -m "プルリクエスト（Pull Request）もろもろのテスト検証"
正常にコミットが完了すると、以下のような出力が表示されます。
➜ GitHub-test git:(test) ✗ git commit -m "プルリクエスト（Pull Request）もろもろのテスト検証"
[test ca7da4c] プルリクエスト（Pull Request）もろもろのテスト検証
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 test
➜ GitHub-test git:(test)
リモートブランチへのプッシュ
作業内容をリモートリポジトリのブランチにプッシュします。
git push
プッシュが正常に完了すると、以下のような出力が表示されます。
➜ GitHub-test git:(test) git push
Warning: Permanently added 'github.com' (ED25519) to the list of known hosts.
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 10 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 343 bytes | 343.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
To github.com:free-honda/GitHub-test.git
6c2b007..ca7da4c test -> test
➜ GitHub-test git:(test)
4. プルリクエスト（Pull Request）を作成する
プルリクエストの作成
GitHubのリポジトリページにアクセスし、「Compare & pull request」をクリックします。
メインブランチ（例: main）に対して作成したブランチをマージするリクエストを作成します。
変更内容、目的、関連するタスクや問題を明確に説明します。
このPRでは以下を変更しました：
- ログイン機能の追加
- ユーザ認証APIの統合
説明を記入し終えたら、画面右下の「Create Pull Request」ボタンをクリックしてリクエストを作成します。
レビュープロセス
作成したPRは、他のチームメンバーがコードをレビューします。メンバーからのフィードバックを受け取り、必要に応じて修正を行います。
修正が必要な場合は、該当の変更をローカルでコミットし、再度プッシュします。
5. ブランチをマージする
マージの手順
レビュー完了後、チームの同意を得たらPRを承認し、GitHub上で「Merge Pull Request」をクリックします。
「Confirm Merge」を実行し、これでブランチがメインブランチに統合されます。
マージが成功すると、画面の色が変わり、メインリポジトリに統合されたことが確認できます。
メインリポジトリに、テストブランチで作成したテストファイルが表示されていることを確認してください。
最新のメインブランチをローカルに反映
以下のコマンドを実行して、最新のメインブランチをローカルに反映します。
git checkout main
git pull origin main
コマンド実行後の出力例
➜ GitHub-test git:(test) git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
➜ GitHub-test git:(main) git pull origin main
Warning: Permanently added 'github.com' (ED25519) to the list of known hosts.
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
Unpacking objects: 100% (1/1), 971 bytes | 323.00 KiB/s, done.
From github.com:free-honda/GitHub-test
* branch main -> FETCH_HEAD
6c2b007..3bc7ef7 main -> origin/main
Updating 6c2b007..3bc7ef7
Fast-forward
test | 0
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 test
➜ GitHub-test git:(main)
不要なブランチを削除
マージ後、作業が完了した不要なブランチは削除してリポジトリを整理します。
git branch -d <ブランチ名> # ローカル
git push origin --delete <ブランチ名> # リモート
コマンド実行後の出力例
➜ GitHub-test git:(main) git branch -d test
Deleted branch test (was ca7da4c).
➜ GitHub-test git:(main) git push origin --delete test
Warning: Permanently added 'github.com' (ED25519) to the list of known hosts.
To github.com:free-honda/GitHub-test.git
- [deleted] test
➜ GitHub-test git:(main)
リポジトリの確認
削除したブランチがリポジトリからも消えていることを確認します。
不要なブランチを適切に削除することで、リポジトリの管理が簡潔になり、チーム開発における効率性が向上します。
まとめ
今回、GitHubを使ったチーム開発の流れを整理してみたことで、ブランチ運用やプルリクエストの仕組みがいかに効率的であるかを再確認できました。
※特に、以下のポイントが重要だと感じました。
- レビュー文化を定着させることで、品質向上とチームの協力体制が強化される。
- ブランチ命名規則などのルールをあらかじめ明確にしておくことで、後々のトラブルを未然に防ぐ。
これらを実践することで、チーム開発がより円滑に進むと改めて実感しました。引き続き、学んだ内容を活かしながら、チーム開発の効率化に努めていきたいと思います。
参考記事