GitHub Flow は、Git Flow よりも GitHub Flowが優れているということではなく、単に開発スタイルの問題です。
頻繁にリリース（デプロイ）する GitHub の開発には「Git Flow」は適していませんでした。
逆に、「GitHub Flow」では頻繁にリリースすることを主軸においています。
こちらは小〜中規模の案件に向いています。
GitHub Flow は、よく Git Flow と比較されます。
ここでは、Git Flow との違いをみていきましょう。
プロジェクトや開発スタイルによって、どちら向いているかは変わってきます。
Git Flow では 6 種類のブランチを使い分けるのに対して、GitHub Flow では 2 種類のブランチ（main、topic）しか使いません。このため、Git Flow のほうがより厳格ですが、手間が多くなりがちです。場合によっては、そこまで必要ないと思うこともあるでしょう。
Git Flow では、リリースのために新しいブランチを作ります。しかし、GitHub Flow では、main ブランチへのマージとリリース（デプロイ）はほぼ同義です。つまり、Git Flow ではリリースを特別なイベントと見なしていますが、GitHub Flow では日常の一部です。このため、main ブランチは常に安定している必要があります。
GitHub Flow は、6 つのルールから成り立っています。この 6 つのルールを守ることで、開発の流れができてきます。
GitHub Flow では、main ブランチへマージした時、すぐにデプロイを行います。そのため、main ブランチが不安定になるようなマージを行ってはいけません。
機能の追加・変更、バグフィックスの際には、main ブランチから topic ブランチを切って作業を行います。直接 main ブランチ上で作業してしまうことのないようにしましょう。
- 機能追加：feature-機能を表す名称
例） feature-user-notice - バグフィックス：fix-修正を表す名称
例） fix-login-validation - 変更：mod-変更内容を表す名称
例）mod-color-change
GitHub Flow では、、頻繁にコードレビューを行うことになります。GitHub にはプルリクエストという機能があり、これを活用すると簡単にコードレビューが行えます。。
コードレビューを通過したら、できるだけ早くマージしましょう。あまり放置していると他の開発者とマージが衝突しやすくなってしまいます。
main ブランチにチェックアウト後、作業ブランチを作成する
git checkout -b 【ブランチ名(※ルール参照)】
〜 作業中 〜
各タスクでブランチを切っているためタスクが完了したら一度コミットする
- 作業したファイルをステージングする。
git add *
- コミットを行う
git commit -m "コミットメッセージ"
- プッシュする
git push origin implement-app-base
※origin…リモートリポジトリのことを指す
- main ブランチ派生させたブランチは main ブランチにデータの上書きをしてよいかのリクエストを送らなければならない = プルリクエスト(プルリク)
- その後、プルリクを main ブランチに依頼し、main ブランチはなるべく早くマージさせる。
- マージ後、派生させたブランチは削除する。
- main ブランチにチェックアウト
git checkout main
- 派生させたローカルブランチを削除
git branch -D implement-app-base
以下のコマンドで解決します。
git remote prune origin
※削除されるものを確認したい場合
git remote prune origin --dry-run
現在存在するリモートブランチを確認する
git remote show origin
※origin…リモートリポジトリのことを指す
ローカルの master ブランチが古いままなので、リモート（GitHub）から pull して更新します。次のコマンドを入力すれば OK です。
git pull origin main
※origin…リモートリポジトリのことを指す