##概要
GitHub Flowを用いて開発を行うことでワークフローを確立し、効率的に開発をすすめられるようにする
####参考：GitHub Flow ～GitHubを活用するブランチモデル～
##GitHub Flowとは
・GitHubが生み出した開発フローのこと。
似たものとしてgit-flowがあげられるが、こちらはGitHub Flowとは異なるものなので混同しないようにする
・GitHub Flowでは頻繁にリリースすることに主軸を置いており、それに適したフローになっている
##git-flowとの違い
###ブランチの種類
・git-flowでは６種類のブランチが存在し、ブランチごとの役割がある。
・GitHub Flowではmasterとtopicしか存在しない。
###リリースの取り扱い
・git-flowではリリースは特別なイベントとして扱う(releaseブランチを作成し、リリースした後にmasterに取り込まれ、バージョンタグを打ったりして管理している)
・GitHub Flowではリリースは日常的に発生するものであるため、masterブランチは常に安定している必要がある
(masterブランチに差分が取り込まれたら自動的にデプロイされるようにしてDXを向上しているところが多いため。masterブランチの資産＝公開しているサービス)
###コミュニケーションに対する姿勢
・git-flowは単なるブランチモデルであり、コミュニケーションに対する規定はない。
・GitHub FlowではGitHubを中心としたコミュニケーションを行って開発を行う
例：プルリクエスト機能を使用して、masterブランチにマージする前にレビュアーにレビューしてもらう等。
##GitHub Flowの６つのルール
###①masterブランチは常にリリース可能な状態である必要がある
・上記で説明した通り、masterブランチは常にサービスとしてデプロイされている資産であるため。
・また、ローカルリポジトリから直接masterブランチにコミットすることはない。(しっかりレビューしてもらってマージする)
###②必ずmasterブランチからtopicブランチを切る
・機能の追加、変更、バグフィックス等サービスに対する変更を行う際には必ずmasterブランチからtopicブランチを切るようにする
・topicブランチをローカルに落として開発し、topicブランチにpushしてレビューしてもらった後でmasterにマージする流れになる
・masterブランチはtopicブランチを切って、同じブランチからマージされるのみのブランチとなる
###③ブランチは定期的にPushする
・チーム開発においてはコミュニケーションが大事になる
・自分が担当しているタスクのトピックブランチに対して開発分をこまめにPushすることで、他のメンバーとも内容を共有することができるため
他のメンバーにタスクでうまくいっていないことを伝えるときには、ローカルからPushしたリモートリポジトリの該当のトピックブランチを落としてもらって説明する流れで良いと思う
###④プルリクエストを使用してレビューする
・GitHubのプルリクエスト機能を使用してコードレビューをしてもらうことで自分が担当するタスクで開発した内容をレビュアーに見てもらうことができる
###⑤masterブランチにコミットする前にコードレビューを行う
・topicブランチをmasterブランチにマージする前に必ずレビューを行う。
・レビュー後にmasteブランチにマージされる。
・プルリクエストでは疑問点の解消や議論などのコミュニケーションも行われる。(レビュアーから実装内容に関する質問点などもプルリクエスト内でコミュニケーションが取れる)
###⑥コードレビューを通過したら速やかにマージする
・コードレビューを通過したら速やかにマージを行うこと
・ここに関してはプルリクエストを承認してmasterブランチにマージする箇所を自動化できないのか(できるっぽい)
##実際の流れ
###前提
・リモートリポジトリが存在し、ローカルにクローンを作成していること
###①ローカルリポジトリで、トピックブランチを作成する
コマンド例：git checkout -b implement-app-base(この名前はトピックブランチ名になる)
(コマンドではブランチを作成して作成したブランチに切り替えるところまでをしている)
###②作成したブランチで作業内容をステージングエリアに追加
コマンド例：git add *
###③ステージングエリアの内容をローカルリポジトリ(implement-app-base)にコミット
コマンド例：git commit -m first commit
(コマンドでは一行でコミットするときのサブコマンドを使用してコミットしている)
###④ローカルリポジトリの内容をリモート追跡ブランチに追加し、リモート追跡ブランチの内容をリモートリポジトリにPushする
コマンド例：git push origin implement-app-base
###⑤GitHubでプルリクエストを作成する
######GitHub上で該当のリポジトリに移動し、Codeタブに移動する
######Pull Requestボタンがあるので押下する
######Pull Requestのメッセージ(※５)を記載しプルリクエストを作成する
※５：厳密にはPull Requestの書き方もある程度型がある。
レビュアーになぜその内容をmasterにマージする必要あるのかを伝え、観点を与える必要がある
参考：4. [WIP]でPull Requestを出す (この時何が終わってないのかも書くと良い)
###⑥(レビュアー視点)プルリクエストをレビューする
Pull RequestページのFiles changesタブからコミット内容をレビューする
レビュー完了とする
###⑦マージする
Pull RequestページにMerge Pull Requestボタンがあるのでそれでmasterブランチにマージする
###⑧topicブランチを削除する
Delete branchボタンで削除する
###⑨ローカルリポジトリからも同様にtopicブランチを削除する
コマンド例：git branch -D implement-app-base
###⑩ローカルリポジトリを最新にする
コマンド例：git pull origin master
##まとめ
・GitHub Flowはブランチ数も少なく、仕組みも簡単ではあるがそれゆえに運用次第で効率的に開発できたり、逆も然りということがわかった
・GitHub Flowを実際の開発現場でどのように運用しているのかというところに今後はフォーカスして調べてみようと思う