More than 1 year has passed since last update.

【確認用】Github flowについてまとめてみた

Last updated at 2023-08-23Posted at 2023-08-23

はじめに

みなさんこんにちは！
都内で受託開発企業のSEをしているhirokiです。

今回は 「Github flow」 について、解説させていただきます。
gitは何度か使用したことはありますが、
打ち慣れたコマンドを何となく打ちながら利用しており、
その裏の動き、コマンドによる詳細な挙動等は意識してきませんでした。

そこで今回は

Github flowの流れを実際に操作しながら確認しつつ、概要を整理する

ことを目的に記事を書き上げました。

ぜひ最後まで閲覧いただければ幸いです。

※Github flowの流れを整理した記事なので、gitの基礎的説明は割愛致します。

Github flowとは

Github flowとは 「Github社が用いているワークフロー」　のことで
言い換えると開発でgit、githubを用いる際の基本手順のことです。

Github flowはシンプルさとわかりやすさが特徴のワークフローなので、
Git、Githubに慣れていない人でも使用することが可能です。

よってGithub flowに従って運用ルールを統一した開発を行うことで
よりスムーズなチーム開発を行うこと可能になります。

Github flowにおける6つの基本ルール

Github flowを用いた開発を行う際、基本ルールをGithub社が定めています。
以下６つがそのルールになります。

【ルール1】mainブランチは常にデプロイ可能である

【ルール2】作業用ブランチをmasterから作成する

【ルール3】作業用ブランチを定期的にリモートにプッシュする

【ルール4】プルリクエストを活用する

【ルール5】プルリクエストが承認されたらmainへマージする

【ルール6】mainへのマージが完了したら直ちにデプロイを行う

順番に解説していきます。

【ルール1】mainブランチは常にデプロイ可能である

デプロイというのは本番環境で使える状態にするということです。
つまり、常に正常に動作する状態を保たなければならないということです。
そのため、修正内容を作業ブランチからmergeする際は、動作しなくなるということが無いように
慎重に行わなくてはいけません。（そのためにプルリクエストがあります）

【ルール2】作業用ブランチをmainから作成する

Github flowで作業用ブランチを作る際は、
必ずmainブランチから作業用ブランチを作成する必要があります。
作業用ブランチから枝分かれさせて作業用ブランチを作ってはいけません。
こうすることで、ブランチをシンプルに保つことができ、管理がしやすくなるというメリットがあります。

【ルール3】作業用ブランチを定期的にリモートにプッシュする

作業がまだ途中の状態であっても修正内容を反映した、作業用ブランチをリモートにプッシュすることで、
開発状況をチーム全体で共有することができます。
それによって、重複した作業を防いだり、ミスが発見しやすくなったりと
効率よく開発業務を進めていくことができるようになります。

【ルール4】プルリクエストを活用する

pullリクエストはローカルで作業用ブランチを作成し
その作業用ブランチをリモートにプッシュすることで作成することができます。
言い換えると、ローカルの作業内容をmainブランチには直接mergeしてはいけないと言うことです。
必ず、作業ブランチを切ってから作業を行わなければいけません。
mainブランチは【ルール1】でも述べた通り、デプロイ可能な状況でなければなりません。
なので、mainブランチむやみに修正内容を反映して、動かなくなるということは、避けなければならないということです。

【ルール5】プルリクエストが承認されたらmainへマージする

こちらに関しても上記で述べたことと同様に、
mainブランチは常に、デプロイ可能な状況ではならないので、
慎重にmergeしなければならないという原則に沿い、
第三者がコードレビューして、問題なければ、mergeするという、ダブルチェック体制を取ります。
それによって、バグや不具合をリリース前に発見することができ、
またコードの質も高く保つことができます。

【ルール6】mainへのマージが完了したら直ちにデプロイを行う

マージが終わったら、直ちにデプロイを行うことで、
今、どの内容をリリースしているのかというのがすぐに認知することができます。
また、リリース単位を細かくして、都度迅速にリリースしているのでリリース後にバグが見つかっても
すぐに元の状態に戻すことができるといったメリットがあります。

Github flowを用いた具体的開発手順

ここからは、具体的開発手順について説明していきます。

Github flow　開発手順

手順１（ローカル）
main(master)ブランチから作業用ブランチに切り替える

手順２（ローカル）
切り替えたブランチで作業を行う

手順３（ローカル）
作業内容をadd→commitする

手順4（ローカル→リモート）
ローカルでcommitした作業内容をリモートにpushする

手順5（リモート）
pullリクエストを作成する。

手順6（リモート）
レビュー

手順7（リモート↔︎ローカル）
修正がある場合はローカルで修正し、変更内容をリモートに反映させる

手順8（リモート）
作業完了後、リモート上のブランチをmainにmergeし、作業ブランチを破棄する

手順9（リモート→ローカル）
ローカルのmainブランチ(masterブランチ)をリモートの最新と一致させる。

一気にざっと手順だけ記載してしまいましたが
順番に図を用いて、確認していきます。

前提条件

これから、私のpcで実演しながら解説していくのですが、
その際の前提条件として

既にリモートリポジトリが作成されていている。
手元pcのローカルとリモートが接続されていて、mainブランチに1ファイルがコミットされている。

という状態からスタートしていきます。

手順1:main(master)ブランチから作業用ブランチに切り替える

git branchコマンドにて現在のブランチを確認するとmainブランチしかない状態です。

そこでgit checkout -b ブランチ名コマンドにて、ブランチの作成と切替を同時に行います。
git branch ブランチ名+ git checkout ブランチ名でもいいのですが
打つコマンドが１回で済むことを考えると、上記コマンドがおすすめです。
今回は「test_branch」という**作業用ブランチを作成し、こちらにて作業を行います。

現在のリポジトリ、ブランチの状況

手順２:切り替えたブランチで作業を行う

手順１で作成したtest_branch上にて、作業を行います。
今回は、「test_branch.md」というファイルを新たに生成し
そちらに「test_branchの確認用のテストです。」という一文を記述しました。

手順3:作業内容をadd→commitする

test_branchにて変更が完了したので、
ステージに git addコマンドで
ローカルリポジトリにgit commit -m "コミット名"コマンド
にて、変更内容を反映します。

これで、ローカルリポジトリの変更をリモートリポジトリに反映する準備は整いました。

現在のリポジトリ、ブランチの状況

手順4:ローカルでcommitした作業内容をリモートにpushする

ローカルリポジトリに反映された変更を
リモートリポジトリ（Github）にも反映させるために
git push origin 作業ブランチ名のコマンドを叩きます。

実際にリモートリポジトリの「test_repository」を確認すると
「test_branch」が生成され、ローカルでの変更内容がリモートにも反映されていることが確認できました。

現在のリポジトリ、ブランチの状況

手順5:pullリクエストを作成する。

pullリクエストを行うにはまず 「Compare & pull request」 を押下します。
（※このボタンは、リモートからローカルに作業ブランチをpushすると表示されるものになります。）

↓

すると以下の画面に遷移します。
レビュー完了後に
結合される側のブランチがbase:main(master)で、
結合する側のブランチが、compare:test_branchで、今回作成した作業ブランチであることが確認できたので
レビュアーへのメッセージを添えて「Create pull request」を押下します。

↓

下記画面が表示されればpullリクエストの作成が完了です。
必要に応じて、画面URLをレビュアーやPMの方々に共有して下さい。

手順6:レビュー

レビューを受ける側の操作

レビューを受ける側は「Reviewers」の入力欄に
レビュアーのGithubアカウントを入力し、登録を行います。

※今回の場合は私が1人でレビュー→承認→mergeの一連の流れを行うため登録しません。

↓

レビューをする側の操作

レビューをする場合は下記画面のように「Conversation」画面にて
ローカルから送られてきたコミットを選択します。

↓

するとレビュー画面に遷移するので
レビューする箇所を　「＋」で選択すると、
その箇所をどのように修正するのか、コメントが追記できるようになります

↓

レビュー内容を登録すると、「Conversation」画面にその内容が表示されます。
reply機能などもあるので、必要に応じてやり取りすることができます。

手順7:修正がある場合はローカルで修正し、変更内容をリモートに反映

レビューにて、「テスト → testに修正して下さい。」との指摘があったので、修正していきます。
該当箇所を修正したら
git add　→　git　commit -m "コミット名"でローカルリポジトリに
git push origin 作業ブランチ名でリモートリポジトリに
それぞれ修正内容を反映させます。
手順３、４と同じ流れをレビューを受けた際の修正作業でも行うわけですね。

↓

pullリクエストの画面を確認すると、ローカルからpushしたcommitが反映されているのでクリックします。

↓

確認すると
変更前のコードが「ー」赤網掛け
変更後のコードが「＋」緑網掛け
となっており、変更箇所が一目で分かるようになっています。

このように
レビュー→修正→add,commit,pushでローカルの内容をリモートに反映→レビュー、、、
という一連の作業をレビュアーからLGTMが出るまでひたすら繰り返していきます。

操作8:作業完了後、リモート上のブランチをmainにmergeし、作業ブランチを破棄する

操作7のレビューにてLGTMを貰ったら、今回の修正内容をmainブランチにMergeしていきます。

まず下記の「Merge pull request」を押下します

↓
最後にもう一度、merge内容を確認して、大丈夫であれば「Confirm」を押下します。

↓

ヘッダーにMergedと表示されていればマージ完了です。
作業ブランチ「test_branch」はもう使用しないので、
「Delete branch」を押下して削除しておきましょう。
こうすることで、ブランチでの作業が完了したことを示し、
ユーザーや他のユーザーが誤って古いブランチを使用するのを防ぐことができます。
削除したブランチはいつでも復元することができるのでご安心いただければと思います。