前回の記事では Gitコンフリクト（merge conflict） を解説しました。
Gitを使った開発では
- ブランチ
- merge
- コンフリクト
などが日常的に発生します。
しかし実際のチーム開発では
どの順番で開発するのか
という開発ルールが必要になります。
その開発ルールの1つが GitHub Flow です。
GitHub Flowは現在、多くのWeb開発で使われている シンプルなGit運用モデルです。
この記事では次の内容を解説します。
- GitHub Flowとは
- GitHub Flowの流れ
- Pull Request
- コードレビュー
- GitHub Flowのメリット
GitHub Flowとは
GitHub Flowとは
GitHubを使った開発の手順
です。
GitHub Flowには次の特徴があります。
- シンプル
- 小さな変更
- 頻繁なデプロイ
特に
Webアプリ開発
でよく使われます。
GitHub Flowの基本構造
GitHub Flowでは
mainというブランチが 常に安定した状態であることが前提です。
つまり
main = 本番コード
です。
新しい機能を作る場合は
featureブランチを作ります。
GitHub Flowの開発手順
GitHub Flowの基本手順は次の通りです。
1 mainからブランチ作成
2 機能開発
3 commit
4 push
5 Pull Request
6 レビュー
7 merge順番に説明します。
1 ブランチを作る
まず main から新しいブランチを作ります。
git switch -c feature-loginブランチ名は
feature-login
feature-payment
fix-headerのように 機能名 を付けることが多いです。
2 機能を開発
新しい機能を実装します。
例
ログイン機能3 commit
変更をコミットします。
git add .
git commit -m "add login feature"4 push
GitHubへ送信します。
git push origin feature-loginするとGitHubに
feature-loginブランチが作成されます。
5 Pull Request
GitHubでは次に
Pull Request
を作成します。
Pull Requestとは
変更をmainに取り込む提案
です。
Pull Requestの内容
Pull Requestには次の情報を記載します。
- 変更内容
- 理由
- 影響範囲
例
ログイン機能を追加しました6 コードレビュー
Pull Requestが作成されると
コードレビュー
が行われます。
レビューでは
- バグ
- 設計
- 可読性
などを確認します。
7 merge
レビューが完了すると
merge
します。
つまり
featureブランチ
↓
mainに統合されます。
GitHub Flowのイメージ
開発の流れ
main
↓
feature branch
↓
commit
↓
push
↓
Pull Request
↓
review
↓
mergeこれが GitHub Flow です。
GitHub Flowのメリット
GitHub Flowには次のメリットがあります。
シンプル
ルールが少ないため理解しやすいです。
安全
mainを直接変更しないため安全です。
レビュー文化
Pull Requestでコードレビューができます。
小さな変更
小さな変更を積み重ねる開発スタイルです。
GitHub Flowが向いているプロジェクト
GitHub Flowは次のプロジェクトに向いています。
- Webアプリ
- SaaS
- スタートアップ
頻繁にデプロイするプロジェクトに適しています。
Git Flowとの違い
Gitにはもう1つ有名な運用モデルがあります。
Git FlowGit Flowは
release
developなど多くのブランチを使います。
一方GitHub Flowは
main + featureだけなのでシンプルです。
まとめ
この記事では GitHub Flow を解説しました。
重要なポイント
main = 本番コード
featureブランチで開発
Pull Requestでレビュー
mergeで統合GitHub Flowは現在最もよく使われるGit運用モデルです。
次の記事
次回は Gitシリーズ最終回
Gitベストプラクティスを解説します。
コメント