ブランチについて
複数人で1つのプロジェクトを開発する場合、同時に機能追加やバグ修正を行うことがあります。
開発を円滑に進めるためのバージョン管理として、Gitのブランチ機能を利用します。
ブランチのコマンドは以下になります。
# 現在のブランチを確認
git branch
# ブランチ作成
git branch [ブランチ名]
# ブランチ切り替え
git checkout [ブランチ名]
# ブランチの作成と切り替え
git checkout -b [ブランチ名]当社のルール
ブランチの種類
| ブランチの種類 | 命名規則 | 説明 |
|---|---|---|
| main | main | 開発用のブランチ |
| staging | staging | ステージング環境 コミットするとステージング環境に自動デプロイ |
| master | master | 本番環境 コミットすると本番環境に自動デプロイ |
| feature | feature/[自分の名前]_[開発するもの] | 各機能の開発用 |
| bugfix | bugfix/[自分の名前]_[修正するもの] | 不具合による修正 |
| hotfix | hotfix/[自分の名前]_[修正するもの] | 致命的不具合による修正 |
運用の流れ
当社ではブランチの構成として main (開発時) -> staging -> master (本番サーバー)で開発を行っています。
基本は main からブランチ (feature / bugfix / hotfix) を切って開発を行います。
開発フロー
main => feature | bugfix | hotfix => main => staging => master
main => hotfix => master
マージとコードレビュー
開発者がGitHubにブランチをプッシュします。
# 初回のみ
git push -u origin HEAD
# 二回目からは省略できます
git pushGitHubにアクセスし前回プッシュしたリポジトリでPull requestsをクリックしNew pull requestをクリックする
プルリクエストに作成画面に移動したら下記の必要事項を入力して、Create pull requestをクリックします。
- [Assignees]の歯車アイコンをクリックして誰にプルリクエストをするのか選択します。
例）ここでは自分を選択しています - Titleにブランチ全体の変更の概要がわかるように入力します（作業中などの場合、Titleにつける接頭語を参照）
例）README.mdを修正 - コメント欄に変更内容の意図や根拠を入力します
例）READMEが書かれていなかったので追記しました
Titleにつける接頭語について
| 接頭語 | 意味 |
|---|---|
| [WIP] | work in progless の略で作業中 |
| [Pending] | 保留中 |
| なし | 完成 |
コメント欄に変更内容の意図や根拠を入力するようにします。
例）READMEが書かれていなかったので追記しました。
プルリクエストが作成できたらコードレビューをしてもらいます。
マージできるようになるまで修正とコードレビューを繰り返し、最終的にマージしてもらいます。
コンフリクトへの対応
上記の開発フローに沿って開発を行うことにより、他者の変更によるコンフリクトの発生頻度を抑えることができます。
基本的にmainブランチのコードはコードレビューを通したものになるので、mainブランチのコードを正として扱います。
適宜コミュニケーションを取りながら、自分のコードが古くないか、他者のコードが正しいかどうかを判断しながらマージを行います。
コンフリクトが発生したときの対処法
まずmainブランチを最新の状態にします。
# mainブランチを最新の状態にする（リモートからローカルに反映）
git pull origin main
# 二回目からは省略できます
git pullコンフリクトしたファイルを修正します。
青のマーカの箇所がmainブランチでの変更なので、mainブランチの変更を取り入れて修正し、再度コミットしプッシュすることでコンフリクトを解消できます。
サブモジュールの利用
場合によっては、Gitのサブモジュールを使用することもあります。
サブモジュールを使用している場合、以下のコマンドを使用してサブモジュールをクローンする
git submodule init
git submodule update
