フローはなんで必要？(ブランチ戦略)

なんで、フローを使うのか考えたことありますか？

私は、前職で有名なフローを使わなかったために起こったさまざまな問題に直面しました。
その際に身をもってフローが必要な理由を体験しましたので、
今回そちらを共有したいと思います。

目次
代表的なフローの説明として、GitHubフローとGitフローの説明とフローの共通の利点
フローを活用しなかった場合にどんなことが起こるのかとして、実際に起こった問題と解決した方法を3つお話ししたいと思います。
問題等に直面した私が思う結論もお話ししたいと思います。

目標
今日のこのLT会を経て、勉強でも個人開発でも
フローを使ってみようかなって思っていただければ幸いです！

GitHubフロー
上がリモート(GitHub上に存在するデータ)
下がローカル(自分のPC上のデータ)
となっています。

gitが、リポジトリ作成時にリモートのmainブランチを作成してくれます。
まず、リモートのmainから、ローカルのmainに最新のものをpullします。
そこから新機能を作成するブランチとして、フィーチャーブランチを作成します。
開発を終えたら、次はリモートにフィーチャーブランチをpushします。
PRを作成して、変更内容に誤りや漏れ等がない場合にマージします。
これを繰り返します。

GitHubフローの特徴
名前の通りGitHubの開発で使用されています
今からお話しするGitフローよりもシンプルでわかりやすく、実践してみやすい
一日何回もデプロイする場合に適用しているため、私は勉強の際に使用しています
PRを作成して、必ず出すところや、
リモートのmain
ブランチは常にデプロイ可能という点が優れています。

Gitフロー
先ほどの話にも出たチーム開発でよく使用されるGitフロー

Gitフローの説明の前にこちらの画像に記載してある内容について補助的な説明をします！

mainが、gitがデフォルトで作成してくれるブランチで、その後デプロイ用のブランチとして使用します。
このブランチはずっとバグが無い状態状況で動いているものとされます。

developブランチは、mainに揚げる前の統合ブランチです。
各個人がfeatureブランチにて開発したものをdevelopブランチにマージして、新機能をどんどん入れていきながら全体の挙動を確認します。

featureブランチは、新機能開発ブランチです。
ブランチとは、履歴の流れを分岐して記録していくためのものです。分岐したブランチは他のブランチの影響を受けないため、同じリポジトリ内で複数の変更を同時に進めていくことができます。
この機能を使い、featureブランチはチーム開発時にチームメンバーが同時進行で新機能等を作成することができます。featureブランチは実装後developブランチにマージします。

fixブランチは、バグや実装漏れを回収するブランチです。
featureをdevelopにマージ後に気がついた際に行われます。

hotfixes(ホットフィックス)ブランチとrelease(リリース)ブランチは他のブランチとは少し違う動きをします。
ホットフィックス　ブランチは、main(本番)リリース後の緊急対応後のブランチです。
本番にマージしたら、バグった！等の大急ぎで直さなきゃいけない場合に使用します。またこのブランチは、mainとdevelopの両方にマージをします。
リリースブランチは、プロダクトリリース用のブランチです。リリース予定の機能やバグフィックスが反映された状態のdevelopから分岐します。リリース準備が整ったら、mainにマージすると共にdevelopにマージします。

mainからdevelopを作成して、developに新機能をどんどん入れていき、デプロイのタイミングで、developをmainに上げます。

Gitフローの特徴
A successful (アクセスフル)Git branching model(Gitブランチの成功モデル)が
もとになっています
説明の通りブランチは、main・develop・feature等の種類があります
それぞれのブランチに意味があり、それをうまく使い分けて開発を進めていく
ブランチに意味があることで、チーム開発の際に、なぜ　そのブランチを作成したのか　などが　すぐに伝わるという利点があります

tea break(masterとmainってなにが違うの？)
画像ではmasterと書いてありますが、現在のリモートリポジトリのデフォルトに合わせて
今回の説明はmainで行おうと思います。
では、master→mainになんで変更したのでしょうか？
githubのリポジトリのデフォルトのブランチが、2020年10月にmasterからmainに変更になりました。
移行期間もあったため、ごく最近変更になり、今も記事等でmasterというブランチ名も見かけることがあると思います。
なぜ、変更になったかというと、
アメリカの人権運動が背景にあり、masterがセンシティブと見なされる用語であるため、見直そうという動きが広がり変更になりました。
私は、いろんな方の意見をお聞きして、masterが「主人」の意味を持ってるため、「主な（おもな）」の意味を持つmainが妥当(だとう)という判断をGitHub側がしたと理解しました

tea break(コンフリクトについて)
チーム開発をフローでしようと思うと一番最初に「コンフリクト」という言葉をよく聞きます
初心者だった時は聞きなれない単語に未知すぎて、怖いものと認識していました。

先輩から「コードの内容わかってたら大丈夫だよ」って言われたけどその言われた理由もよくわかんなくて困惑しました。

私が認識しているコンフリクトとは、
同じファイルを変更した際にGitHubがどちらの変更を優先すればいいかわからない場合に確認を取ってくることです。

例えば、Aさんがリファクタリングとして、CSSファイルをSCSSの記載方式で変更をかけました。
Bさんはそれに気が付かずに元のCSSで追記してしまいました。
GitHubが、同じファイルなのにまったく書き方が違うことでどちらが正しいかわからずに戸惑ったため、コンフリクトを使い人間にこのことを伝えました。
この際は、AさんBさんが話し合い、両者でファイル内容を確認とりながらコンフリクトを解決すればよいです。
下手に一人で解決しようとするとファイル内容に漏れが生じる場合があるため、確実に確認を行いなからやることをお勧めします。
ちなみに私はこの例のままのコンフリクトを出したことがあり、丸１日かけて解決いたしました・・・
ほうれん草は、しっかり行いましょう・・・

利点
大人数での開発では、フローでの統合ブランチを作成することにより、ダブルチェックや本番環境に上げる前にバグの発見等ができます。
PRを作成すると上げたいコード内容が何なのか確認が取れたり、マージ後にもし落ちてもリバートがボタン一つで行うことができます。

ブランチ戦略を活用しなかったら？
もし活用しない場合はどうなるのでしょうか？
みなさんはどんな問題が起こると思いますか？

1つ目として、
「人のcommitがPR作成時になぜか現れてしまう」
develop・stagingに分けているのに、gitフローを採用してない時に発生いたしました。
featureブランチで新機能を作成して、develop・staging・本番と直接マージしていくフローをしていました。
そうすると、もう先にマージし終わっているブランチが通ってきたフローが　違うために自分のPRに他人のcommitが入ってきてしまいました。
それをそのまま上げるのはご法度なため、解消しなければならずかなり苦労しました。
しかも解決策が、PRを一旦作成して、再度現在のmainからブランチを切り直して、自分の実装のcommitをチェリーピックするか、コピペして同じ内容の新しいブランチを作成する方法しかありませんでした。手間と時間がかかり苦労しました。

２つ目に
個人がそれぞれのfeatureブランチをバラバラに上げるため、他の誰かがあげている場合に待ちの時間が発生しました。
もし誰かがバグや環境を落としてしまうと他の全員の作業が止まってしまいました。
今日中に上げてしまいたい、バグ解消が済んだfixブランチがあったとします。その前に、新機能を上げる話になり待っていました。両方ともデブには無事に上がり、次stgに上げる際に新機能でバグが発生。一日中stgが新機能を上げるチームで止まってしまったことがあります。
こちらには、解決策が存在せず、
自分達のブランチは宙ぶらりんのまま次のタスクを行うことになったことが幾度かあります。

3つ目に
フローにはPRが必ず存在します。
統合ブランチやmainブランチに上げる際に実装者以外の挙動確認やコード確認が入ります。
これにより、実装者が確認していなかった点やおかしな挙動等が炙り出されます。
また、負担が分散されることにもつながります。
PRの制度も統合ブランチの制度も存在しない場合　一個人の確認だけに頼るため、毎日どこかの環境が落ちる・・・ということに繋がります。
例えば、投稿機能にバグが発生していて、そこを治した際に同じ関数を使っていた、編集機能にバグが生じることが多々ありました。
理由は、関数を変更する際に影響範囲を調べきれなかったことです。一個人があまり触ったことのないリポジトリやファイルのバグ回収の際にPR制度もなく必死に調べたけど漏れてしまったとも言えます。一個人に背負わせるには少し大きいと思いますし、PRのありがたさがわかります。

結論！
先人が残してくれたフローや制度は大切な開発の手段です。
もし、問題が起きてもググれば大体先人が残してくれた記事や対策が残っています。
過去に起こったさまざまな問題を起こりにくくするために　よりよく開発を進めるために　先人がまとめてくれたものがフローです。
ですので、有名なフローを日常的に使用して慣れたり思想を理解していきましょう！