「mainブランチ消しちゃったみたいでぇ……」

Git, GitHub, 失敗談

はじめに

こんにちは。株式会社レコチョクの長島です。2022年4月に新卒で入社し、iOSアプリの開発をしています。

今日はタイトル通りmainブランチを消し飛ばすという経験をしたので、なんでそうなったのか、どう復旧・対策したのかを過ちを繰り返さないために文章にして紹介しようと思います。

やらかしに気付く

エンジニアを初めて2年半強、いくつかアプリリリースもして満足していたある日のこと。ブランチの一覧を見ていたら、開発プロダクトのmainブランチがなくなっていました。
ローカルには残っているけど、remoteにはdevelopブランチしかない。「そんなことある？」と呟き、色々と調べていました。

犯人は自分でした。

要因

問題が起きたプロダクトでは、git-flowに基づいた管理フローを採用しています。今回以下のような流れでリリース関連の作業を行いました。

  • mainブランチからdevelopブランチを作成
  • developブランチからreleaseブランチを作成
  • リリースする
  • releaseブランチをmainブランチにマージする
  • mainブランチをdevelopブランチにPull Request（PR）を出してマージする

Merge1.drawio.png

さて、この部分ですが、git-flow的におかしい点があります。以下の部分です。

mainブランチをdevelopブランチにPRを出してマージする

別リポジトリでの開発時にはローカル上でmain→developでマージしたあとpushしていたのですが、今回のリポジトリではdevelopにプロテクションルールとして『Require a pull request before merging(マージ前に pull request 必須)』の機能が設定されていました。これにより直接マージすることができなかったため、main→developのPRを作成しレビュー依頼を出していました。

さて、GitHubにはPRがマージされたあとのブランチを自動で削除してくれる『Automatically delete head branches』というオプションがあり、今回のリポジトリではそれを有効化していました。さらに、mainブランチにプロテクションルールを設定することを忘れていました。
この状態でmain→developのPRがマージされたらどうなるでしょうか。当然、mainが消えます。諸行無常ですね。

MainBranchDeleted.png

MainDestroy.drawio.png

復旧

GitHubには削除したブランチを復旧できる機能があったので、これを利用して復旧しました。Merged状態になったPRを開き『Restore branch』ボタンを押すことで復活できます。

MainBranchRestored.png

その期間中、新たな開発は行われていなかったため、特にプロダクト周りで影響はありませんでした。

対策

この件があってもう一度学び直しましたが、git-flowではrelease→developと、release→mainを行うのがリリース後のやり方としては一般的です。今回、私が横着してrelease→main→developとして作業していたのが原因なので、正しくブランチ管理をするのは大切だなぁと感じられました。

Merge2.drawio.png

また、mainブランチがこうした事故で警告なく消えることを繰り返さないように、『Require a pull request before merging, Require approvals : 1(マージ前に1件以上のApproveされているpull request必須)』のプロテクションルールを設定しました。これにより、マージ前に作業でなにかミスをしてないか見てもらえる環境になりました。むしろ今までdevelopブランチにはあったけどmainブランチには設定できていなかったのが危ない状況だったんだなぁと気付けて良かったです。

余談

先輩に話したとき、シンプルに「mainブランチ消しちゃったみたいでぇ……」という言葉が状況として面白すぎて職場で爆笑が起きました。

笑顔が消え失せることがなくて良かったです。

まとめ

  • git-flowに沿うなら、releaseからdevelop、releaseからmainにマージする形でブランチ管理をやりましょう。
  • 消えてほしくないブランチにはプロテクションルールを設定しましょう。
  • 慌てず騒がずに復旧すれば致命傷になることはないと思うので、冷静に対応しましょう。

上記のことに気付きました。今回は無傷でしたがもしかすると重大なことになっていたかもしれないので、本当に大事にならなくて良かったです。
Branchの管理ルールはいろいろとありますが、なるべく安全な方法・正しい手段に従うことで、こういうヒューマンエラーを無くしていけるのだろうなと思いました。今後も気をつけていこうと思います。

Git, GitHub, 失敗談