0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

Pull Requestでマージしたのに、対象ブランチにマージコミットが存在しない

0
Posted at

あ…ありのまま 今起こった事を話すぜ!
な…何を言っているのか分からねーと思うが、おれも何が起こっているのかわからなかった…

発生した事象

1. 2つの作業ブランチを本番化するため、masterブランチへPull Requestをそれぞれ作成
2. Pull Requestを、担当者の承認してマージする
3. マージすると同時に、Github ActionsでBump versionする処理(package.jsonのバージョンを上げる)が実行される
4. その後、Github Actionsの本番デプロイワークフローが実行され、無事に本番化完了
5. ところがmasterブランチにはPull Requestした作業ブランチのうち1つかマージされていない

下図の青枠で囲った2つが、今回masterにマージした作業ブランチである。
#12と#13のPull Requestを出している。
そのうち#13のPull Requestでマージしたはずのブランチは、Merged状態なのに、進行しているコミットがある(masterより進んでいる)
screencapture-github-ligua-WORKBASE-WORKBASE-ligua-branches-2023-01-27-13_30_16.png

#13のPull Requestを確認してみると、問題なく承認されマージが完了しているように見える。
マージコミット6108aeaを確認してみる。
screencapture-github-ligua-WORKBASE-WORKBASE-ligua-pull-13-2023-01-27-13_29_43.png

何やら注意文が出ている。
screencapture-github-ligua-WORKBASE-WORKBASE-ligua-commit-6108aead88000599eb0e49e9f92631efbef25d94-2023-01-27-13_29_23.png

This Commit does not belong to any Branch on this repository, and may belong to a fork outside of the repository
(訳:このコミットはどのブランチにも所属していない。フォークされた外部リポジトリのものかもしれない)

ちなみに、フォークなどされてないので、外部リポジトリのコミットである可能性などない。

原因

結論から言う。
Github ActionsでmasterへのPull Requestの直後に、Bump versionする処理により、マージコミットを上書きして無きものにしていた

  • Bump versionのために追加したコミットをforce Pushしていた
  • 複数のPull Requestを立て続けに承認・マージした

この二つが重なって問題が起きていた。
詳細は以下の通り。

Github Actionsの処理

Github Actionでは、以下のようなワークフローを設定している

  • プルリクエスト後に、npm versionコマンドを実行して、package.jsonのバージョンを書き換えて、Gitにコミットする
    • そのときバージョン番号のタグが付けられる
  • バージョン番号のタグがpushされると、本番環境へのデプロイを実行

Bump Version

詳細は省くが、プルリクエストが承認されると以下のようなコマンドを実行するように設定している。

npm version minor
# major, minor, patchは場合分けしている

git push origin master --follow-tags --force

本番デプロイ

npm versionで自動で付けられるタグ(v2.7.0)がpushされると、本番へのデプロイが実行されるように設定している。

実際に起こったこと

実際に起こったことを時系列に沿って書いておこう。
[]内は、masterブランチに含まれるコミット

1.担当者がプルリエクエスト#12 を承認し、作業ブランチAがマージされる [Aのマージ]
2.Bump Versionの処理が実行を開始 [Aのマージ]
3.担当者がプルリエクエスト#13 を承認し、作業ブランチBが作業ブランチAのマージコミットの直後にマージされる(#12のBump versionはまだリモートリポジトリにpushされてない) [Aのマージ,Bのマージ]
4.Bump Versionの処理が実行を開始 [Aのマージ,Bのマージ]
5.#13の方のBump versionしたコミットがPushされる [Aのマージ,Bのマージ,Bump]
6.本番デプロイ処理が開始される [Aのマージ,Bのマージ,Bump]
7.#12の方のBump versionしたコミットがPushされる [Aのマージ,Bump]

こうして、#13でマージされたのに、当該作業ブランチBは、masterにマージされていない状態になっていた。
なお、本番デプロイはAもBも両方の変更を反映したものになっていたのは、#13の方のBump versionコミットが先にPushされたためである。

もし#13のBump versionのpush が、#12のBump versionより遅かった場合

masterブランチの最新コミットは、[Aのマージ,Bのマージ,Bump]と意図したものとなっていたであろう。
だが、本番デプロイは[Aのマージ,Bump]のコミット状態で開始されていたであろうから、作業ブランチBの更新内容が含まれないままリリースされてしまっていただろう。

教訓

この環境におけるプルリクエストは1個ずつ承認してもらうこと。
あるいは、複数の作業ブランチを同時に本番化するなら、プルリクエストする作業ブランチを1個にまとめること。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?