GitHubを使い始めると、必ず出会うのが「ブランチ」という概念です。
Python学習の9日目は、「ブランチとは何か？」という基本的なところから、なぜブランチを使うべきなのか、そして基本的な操作方法までを学んでいきます。
ブランチとは？
ブランチをひと言で表すなら、「開発のパラレルワールド（並行世界）」です。
プロジェクトには、常に安定して動いているコードを保管しておく「mainブランチ」という基本の世界があります。
新しい機能を追加したり、バグを修正したりするとき、この世界のコードを直接編集してしまうと、もし作業中にバグが生まれてしまった場合、製品全体が動かなくなってしまう危険性があります。
そこで、Gitでは安全に作業を進めるために、次のような手順でブランチを活用します。
- 分岐する: mainブランチの安全なコピーとして、新しいブランチを作成します。
- 作業する: 新しいブランチ上では、mainブランチに影響を与えることなく、新機能の追加や修正に自由に集中できます。
- 統合、または削除する:
- 作業が成功すれば、変更内容をmainブランチに統合（マージ）して反映させます。
- もし失敗したり不要になった場合、そのブランチを削除するだけで、mainブランチが壊れることは一切ありません。
このように、ブランチは安全な開発と効率的な並行作業を実現する、Gitの非常に強力な仕組みです。
なぜブランチを使うの？3つの大きなメリット
ブランチを使うことで、開発の安全性と効率は飛躍的に向上します。
ここでは、その代表的なメリットを3つ紹介します。
- 1. 安全に開発を進められる
-
安定しているmainブランチを直接編集しないため、開発中のコードが既存の機能を壊してしまう心配がありません。
これにより、開発者は安心して新しい機能の開発やバグの修正に集中できます。
- 2. 並行作業がスムーズになる
-
それぞれ別のブランチで作業することで、お互いの変更が衝突（コンフリクト）するのを防げます。
例えば、「背景変更機能」「タイマー機能」といった形で、それぞれの作業を邪魔することなく、同時に異なる機能の開発を進められます。
- 3. 変更履歴が整理されて分かりやすい
-
「〇〇機能の追加」や「△△のバグ修正」のように、目的ごとにブランチを分けて開発することで、変更の履歴が非常に分かりやすく整理されます。
後からプロジェクトの履歴を振り返ったときに、「この変更は何のために行われたのか」が一目で理解できるようになります。
ブランチを使った基本的な開発フロー
ここでは、ブランチを作成してから後片付けまでの一連の流れを、コマンドと共に解説します。
- 作業用ブランチを作成： git branch ブランチ名
- 作業用ブランチに切り替え： git swicht ブランチ名
- 現在のブランチを表示： git branch
- ファイルを編集し、コミットする
- ファイルを編集する
- 変更したファイルをステージング： git add 編集ファイル
- 変更内容をコミット： git commit -m "変更内容をコメント"
- 作業用ブランチをGitHubにプッシュ：git push origin ブランチ名
- GitHub上でプルリクエスト（Pull request）を作成し、統合（マージ）する
- プルリクエストを作成
- レビューを実施
- mainブランチにマージ
- 作業用ブランチを削除
- ローカルのブランチを削除
- git switch main
- git pull
- git branch -d ブランチ名
ちなみに、「git switch -c ブランチ名」でブランチの作成と移動を一度に行うことも出来ます。
ローカルブランチの一覧を表示し、今いるブランチには「*」が付きます。
GitHub上のmainブランチをローカルのmainブランチ同期させたあとに、ローカルの作業用ブランチを削除します。
Gitのブランチ名はどう付ける？分かりやすい命名規則のススメ
Gitのブランチを使いこなす上で、意外と重要になるのが「ブランチの名前の付け方」です。
ブランチ名は、そのブランチが「何のための作業をしているのか」を示す重要な看板の役割を果たし一貫性のある命名はチーム開発をスムーズにします。
厳密なルールはありませんが、多くの開発チームで使われている一般的な命名規則は以下のとおりです。
- feature/: 新しい機能を追加するとき
- bugfix/ または fix/: バグ（不具合）を修正するとき
- hotfix/: 公開中のサービスで発生した緊急のバグを修正するとき
- refactor/: 機能は変えずに、コードの内部構造を整理・改善するとき（リファクタリング）
- docs/: ドキュメントの修正や追加をするとき
- chore/: 上記以外の雑多な作業（ライブラリのアップデート、設定ファイルの変更など）
追加する機能を分かりやすく記述します。
例: feature/add-user-login, feature/realtime-background-update
何をしたのかが分かるように記述します。
例: bugfix/fix-header-layout, fix/incorrect-time-display
例: hotfix/critical-security-vulnerability
例: refactor/simplify-database-query
例: docs/update-readme
例: chore/update-gunicorn-version
さらに分かりやすくするための命名のコツ
上記の例に加えて、いくつかのルールを組み合わせることで、さらにブランチの管理がしやすくなります。
- 単語の区切りはハイフン (-) を使う
- Issue番号を含める
add-user-loginのように、単語間をハイフン(-)でつなぐのが一般的です。
「feature/TICKET-123-add-login」のように番号を含めると、どのタスクと関連するブランチなのかが一目瞭然になり、非常に便利です
作業例
前回「git clone」でダウンロードしてきたリポジトリで、「docs/update-readme」というブランチを作成して、「README.md」を編集して変更をマージするまでの作業を行っていきます。
新しいブランチを作成（ローカルで作業）
「git branch」で新しい「docs/update-readme」というブランチを作成します。
$ cd ~/project/time_app $ git branch docs/update-readme
ブランチの移動
「git switch」で「docs/update-readme」ブランチに移動します。
$ git switch docs/update-readme Switched to branch 'docs/update-readme'
現在のブランチを確認
「git branch」でブランチの一覧と、現在のブランチを確認します。
「*」がついてるものが、現在のブランチとなります。
$ git branch * docs/update-readme main
ファイル編集作業
「README.md」ファイルを編集します。
$ vi README.md
ステージングとコミット
編集が完了したら、ステージングとコミットを行います。
$ git add README.md $ git commit -m "インストール方法を修正" [docs/update-readme a1831f4] インストール方法を修正 1 file changed, 33 insertions(+), 1 deletion(-)
GitHubへプッシュ（アップロード）
「git push」でGitHubへ作成したブランチをアップロードします。
$ git push -u origin docs/update-readme Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 4 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 829 bytes | 829.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (1/1), completed with 1 local object. remote: remote: Create a pull request for 'docs/update-readme' on GitHub by visiting: remote: https://github.com/servermemo/time_app/pull/new/docs/update-readme remote: To github.com:servermemo/time_app.git * [new branch] docs/update-readme -> docs/update-readme branch 'docs/update-readme' set up to track 'origin/docs/update-readme'.
GitHubで新し作成したブランチを確認
WebブラウザでGitHubにアクセスして、アップロードした「docs/update-readme」ブランチが反映されているか確認します。
リポジトリのページを開き、ファイル一覧の上にある現在のブランチ名が書かれたボタンをクリックします。
ブランチのリストが表示されるので、表示したいブランチを選択します。
プルリクエスト（Pull Request）の作成
GitHubのウェブUIを使ってプルリクエストを作成します。
ブランチをプッシュすると、リポジトリのトップページに黄色い背景の通知が表示されます。
そこにある「Compare & pull request」ボタンをクリックするのが一番手軽です。
通知が消えてしまった場合
リポジトリのタブから「Pull requests」をクリックし、表示された画面の右側にある「New pull request」をクリックします。
マージするブランチを選択
base（統合先）とcompare（変更元）のブランチを選択する画面になりますので、baseとcompareをそれぞれ選択します。
- base (ベース): 統合先のブランチです。（通常はmainを選択）
- compare (比較): 変更元（作業を行った）ブランチで、今回は「docs/update-readme」を選択します。
※「Compare & pull request」ボタンから始めた場合、ここは自動で正しく設定されていることがほとんどです。
選択を行うと、画面の下部に変更内容が表示されるので間違いがないかを確認します。
変更内容に問題がなければ「Create pull request」ボタンをクリックします」
タイトルと説明の記述
「Open a pull request」という画面が表示されるので、以下の内容を入力します。
- Add a title（タイトル）: 変更内容を簡潔に表すタイトルをつけます
- Add a description（説明）: どんな機能を追加したのか、何を修正したのか、なぜその変更が必要だったのかなどを具体的に記述します。
- Assignees（担当者）: 画面右側のサイドバーにある歯車アイコンをクリックすることで、担当者（通常は自分）を指定できます。
- Labels（ラベル）: 画面右側のサイドバーにある歯車アイコンをクリックすることで、bug, feature, documentation のように、プルリクエストの種類を示すラベルを付けることができます。
未来の自分や他のメンバーが見たときに、コードを読まなくても変更内容が理解できるように書くのが理想です。
関連するIssueがあればリンクすることもできます。
入力が終わったら「Create pull request」ボタンをクリックして作成を完了します。
レビューを行う
一人で開発を行っている場合は、作成したプルリクエストを少し時間をおいてから自分で見直します（セルフレビュー）。
客観的な視点で見ることで、改善点やバグに気づくことがあります。
チームで開発を行っている場合、プルリクエストを作成すると指定されたレビュアー（またはチームメンバー）に通知が届きます。
レビュアーはコードをチェックし、質問や改善提案をコメントとして書き込みます。
プルリクエストを開く
リポジトリ画面の「Pull requests」タブをクリックすると、プルリクエストの一覧が表示されます。
レビューを行いたいプルリクエストをクリックします。
レビューの手順
レビューは、プルリクエストの「Files Changed」タブがメインの作業場所になります。
変更された部分が表示されるので、気になった箇所や質問したい箇所があれば、コメントを残します。
コメントしたい行の左側にある青い「+」アイコンをクリックするとテキストボックスが表示されるので、コメントを書き込みます。
コメントを入力した後に「Start a review」ボタンをクリックしてレビューを開始します。
これにより、複数のコメントをまとめて送信できるようになります。
レビューが終わったら画面右上にある「Review changes」をクリックします。
表示されたウィンドウの中にある3つの選択肢から、適切な物を選択します。
- Comment（コメント）：承認も変更要求もせず、単にフィードバックとしてコメントを残します。「ちょっと質問だけしたい」という場合に使います。
- Approve (承認)：変更内容は問題ないので、マージしてOKという意思表示です。
- Request changes (変更要求)：修正が必要ですという意思表示です。必ずコメントで具体的に修正箇所を伝えましょう。
適切な選択肢を選び、「Submit review」ボタンを押せば、レビューは完了です。
「Approve」と「Request changes」ができないのはなぜ？
一人で開発している場合は、グレーアウトしていて「Approve」と「Request changes」を選択することが出来ません。
これはGitHubの仕様です。
なぜ自分自身のPRをレビューできないのか？
プルリクエストのレビュー機能は、コードの品質を担保するための第三者によるチェックを目的としています。
- Approve: 第三者が「内容を確認し、問題ない」と承認するためのものです。
- Request changes: 第三者が「マージする前に修正が必要だ」と正式にブロックするためのものです。
このため、作成者本人が自分自身を承認したり、ブロックしたりする操作は、その目的に沿わないため無効になっています。
一人で開発している場合で、セルフレビューして問題がない場合は、プルリクエスト上で他に特別な操作は必要なく、「Converstion」タブでマージ作業を行います。
マージ：変更の統合
コードレビューが完了したら、いよいよプルリクエストの最終段階であるマージに進みます。
これにより、ブランチでの変更がmainブランチに正式に取り込まれます。
プルリクエストの画面にある「Converstion」タブをクリックして表示される画面にある、マージボタンをクリックすると以下のマージ方法が提示されます。
- Merge pull request: ブランチのコミット履歴をそのままmainに統合します。
- Squash and merge: ブランチの複数のコミットを1つのコミットにまとめてmainに統合します。
- Rebase and merge: ブランチのコミットをmainブランチの最新の状態にリベースしてから統合します。
とりあえず今回は「Squash and merge」を選択してみます。
マージコミットのメッセージを必要に応じて入力し、「Confirm squash and marge」ボタンをクリックします。（ボタンの表示は選んだマージの種類によって変わります）
ブランチの削除
プルリクエストがマージされると、その作業ブランチは不要になります。
表示されている「Delete brancd」ボタンをクリックして、GitHub上からブランチを削除しておきます。
ボタンをクリックすると、ブランチが削除されてマージが出来た旨のメッセージが表示されてます。
GitHub上では一連の作業はこれで完了です。
ローカルのブランチを削除
GitHub上でマージが完了したら、最後にローカル環境でブランチの削除を行います。
この作業を怠ると古い情報が残り、次の作業で混乱する原因になります。
mainブランチに移動
現在のブランチから「git switch」でmainブランチ移動します。
$ git switch main Switched to branch 'main' Your branch is up to date with 'origin/main'.
GitHubのmainブランチと同期
「git pull」 を実行し、GitHub上でマージされた最新の内容をローカルのmainブランチに反映させます。
$ git pull remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Compressing objects: 100% (1/1), done. remote: Total 3 (delta 2), reused 2 (delta 2), pack-reused 0 (from 0) Unpacking objects: 100% (3/3), 1016 bytes | 1016.00 KiB/s, done. From github.com:servermemo/time_app b0dcd35..b99fbaf main -> origin/main Updating b0dcd35..b99fbaf Fast-forward README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
ブランチを削除
役目を終えたローカルのブランチを削除します。
$ git branch -d docs/update-readme
warning: deleting branch 'docs/update-readme' that has been merged to
'refs/remotes/origin/docs/update-readme', but not yet merged to HEAD
Deleted branch docs/update-readme (was e53df7d).
補足：waringについて
ブランチ削除時にこのwarningが表示された場合、それはGitHub上で「Squash and merge」を使ったことが原因である可能性が高いです。
これは、「削除しようとしたブランチ（docs/update-readme）はGitHub（refs/remotes/origin/docs/update-readme）にマージ済みですが、ローカルのブランチ（通常はmain）にはまだマージされていません」という正常な警告メッセージです。
warningは表示されていますが、「Deleted branch docs/update-readme 」と表示されていれば、ブランチは問題なく削除されています。
まとめ
今回はブランチの使用方法と、GitHub上でのマージの仕方について学びました。
実際にブランチを作成し、GitHubへプッシュ、プルリククエストの作成、統合（マージ）、ブランチの削除までを行ったので、とりあえず一連の作業工程は理解できました。
ですが、細かい操作方法についてはまだまだ理解できていないので、これから実際に開発を行いながら色々と学んで行きたいと思います。
コメント