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

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

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

そこで今回は

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

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

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


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


## Github flowとは

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

https://docs.github.com/ja/get-started/quickstart/github-flow


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　開発手順**  

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

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

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

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

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

:::note info
手順6（リモート）
**レビュー**
:::

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

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

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

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


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

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

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

![スクリーンショット 2023-08-22 21.10.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/6475e937-cb9d-adad-14f6-c6e10ddaa36d.png)



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

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

![スクリーンショット 2023-08-22 21.27.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/fe4629a5-8569-e5b0-397d-75a674ebce15.png)

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

![スクリーンショット 2023-08-22 21.36.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/1d002ad0-bc90-cca7-a7f3-f3b47a48f7f4.png)

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

![スクリーンショット 2023-08-23 132411.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/3ae60987-5247-0d89-d5db-b63dd1fbf7c4.png)





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

![スクリーンショット 2023-08-23 7.26.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/23fd4533-a4dd-d7c5-0f0e-5b5247fe91e1.png)



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

![スクリーンショット 2023-08-23 7.33.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/77080e9b-d01e-077c-0a6d-37c9a31f51e8.png)

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

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

![スクリーンショット 2023-08-23 132454.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/9492f5da-10ea-5761-6939-51743f61e9c7.png)


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

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

![スクリーンショット 2023-08-23 7.58.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/e005febd-f948-8794-42bb-3d5c7e45cadc.png)

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

![スクリーンショット 2023-08-23 8.03.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/2795012c-39dc-3d08-cc0a-69e739d1a045.png)

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

![スクリーンショット 2023-08-23 132524.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/201b9d4c-4223-5a35-5ada-6550f38bec1f.png)



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

pullリクエストを行うにはまず **「Compare & pull request」** を押下します。
（※このボタンは、**リモートからローカルに作業ブランチをpushすると表示**されるものになります。）
![スクリーンショット 2023-08-23 8.20.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/2a431214-385b-0846-e1e8-bdc07224ba55.png)

↓

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

![スクリーンショット 2023-08-23 8.52.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/dfc7578c-0f2c-42ec-9ccb-1ce349ac07b5.png)

↓

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

![スクリーンショット 2023-08-23 9.01.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/50df3d10-cb06-fc22-25b1-3c42c581ccc9.png)

### 手順6:レビュー


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

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

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

![スクリーンショット 2023-08-23 9.22.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/a65e8ae5-bf60-79e5-0812-8922213381bd.png)

↓

**レビューをする側の操作**

レビューをする場合は下記画面のように``「Conversation」画面``にて
ローカルから送られてきたコミットを選択します。
![スクリーンショット 2023-08-23 9.28.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/522cc643-d209-f998-f37a-687817d9cd1f.png)

↓

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

![スクリーンショット 2023-08-23 9.52.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/f40b0cb3-ef25-119d-6960-5add8168faa7.png)

↓

レビュー内容を登録すると、``「Conversation」画面``にその内容が表示されます。
reply機能などもあるので、必要に応じてやり取りすることができます。
![スクリーンショット 2023-08-23 9.57.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/3d8cd60b-5f7b-d692-a939-cfe2ac105583.png)



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

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

![スクリーンショット 2023-08-23 10.28.18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/392294d7-ddb6-bdd0-3874-fccf7d64065c.png)

↓

pullリクエストの画面を確認すると、**ローカルからpushしたcommitが反映**されているのでクリックします。
![スクリーンショット 2023-08-23 10.41.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/29b61d60-ff9e-383f-7466-91de9faaf49b.png)

↓

確認すると
変更前のコードが``「ー」赤網掛け``
変更後のコードが``「＋」緑網掛け``
となっており、変更箇所が一目で分かるようになっています。
![スクリーンショット 2023-08-23 10.52.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/afa88306-6ea7-d8de-0382-db60ccb05134.png)

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

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

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

まず下記の``「Merge pull request」``を押下します
![スクリーンショット 2023-08-23 11.03.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/69770d20-6fdc-aaf7-db7a-3604290e08a5.png)

↓
最後にもう一度、merge内容を確認して、大丈夫であれば``「Confirm」``を押下します。
![スクリーンショット 2023-08-23 11.08.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/cd71f092-d546-d84e-9047-39d9d07c41f8.png)

↓

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

https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/deleting-and-restoring-branches-in-a-pull-request


![スクリーンショット 2023-08-23 11.27.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/38567ab0-9722-e3dd-6654-ac9bca78ed6d.png)

↓
``「mainブランチ」``を確認すると、先ほど``「test_branch」``からmergeした内容が反映されていることが確認できました。
![スクリーンショット 2023-08-23 11.34.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/16c181f2-330b-abff-684b-98f5d79d2479.png)

作業ブランチも削除されてmainブランチだけになっていることも確認できます。
![スクリーンショット 2023-08-23 11.32.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/eb884b05-cc4f-9800-4ce0-9375e93b7f1f.png)

以上にて、リモート側の作業は終了になります。

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

![スクリーンショット 2023-08-23 132555.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/611ff359-7280-565a-ce40-a02a11765ffe.png)


### 操作9:ローカルのmainブランチ(masterブランチ)をリモートの最新と一致させる。

最後に、リモートの更新内容をローカルにも反映させていきます。

``git checkout main``コマンドにてブランチを切替えた後に
``git pull origin main --rebase``コマンドでリモートの変更を
ローカルのmainブランチに取り込みます。


![スクリーンショット 2023-08-23 13.16.10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/2fc64a14-e9b4-1cd3-b5fc-98e72adf9108.png)

これにて、Github　flowにおける全ての作業が完了となります。

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

![スクリーンショット 2023-08-23 132623.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2265379/2ef54aac-d393-3f39-2d9d-068eb9dba104.png)








## 終わりに
Github　flowに関して、いかがだったでしょうか？
今後も開発現場で頻繁に使用することになるであろうフローなので、今のうちに覚えておいて損はないと思います。
ここまで、本記事を閲覧いただきありがとうございました！！


## 参考文献

https://docs.github.com/ja/get-started/quickstart/github-flow

https://www.udemy.com/course/unscared_git/learn/lecture/6680416#questions

https://pbs.twimg.com/media/Fh6bl4DWIAAZxse.jpg:large

https://www.amazon.co.jp/dp/4295013617/?tag=impressjapan-22&linkCode=as1

https://atmarkit.itmedia.co.jp/ait/articles/1708/01/news015.html#021