一人で使ったっていいじゃない、自分から自分へのマージ依頼？ それがどうした 『 プルリクエスト 』

今回は厳密には Git 自身の機能ではないのですが、リモートリポジトリを使用しているなら知っておくべきプルリクエストという機能のお話です。

以前の記事でブランチを切ってプッシュまでできているので、そのあとどーしましょうって話です。

🔘 プルリクエスト ( Pull Request ) とは？

名前からは想像しにくいのですが、第三者にレビューをしてもらい問題ない状態であれば（になったら）マージをしてもらう機能です。
プルリクと省略して言われることもあり、GitHub、BitBucket、Backlog など主要なサービスで提供されています。

「プルして内容を見てもらい、問題なければマージしてください」とリクエストするイメージです。

ただ、私もそうですが、
「いや、個人で使ってるんで、誰にもリクエスト出す必要ないんですが。というか出す相手がいない・・・」
という場合は単純にリモートリポジトリにおいて自分自身でマージを行うということで問題ありません。

プルもこの際どうでもイイです、マージしましょう。

🔘 どんなマージか？

通常は、こちらの記事でご紹介したノンファストフォワード( Non Fast-Forward )マージを行います。

他にもないことはないのですが、少しややこしいのと別に使えなくても支障がないのでここでは無視します。
ローカルでのマージとは逆で、デフォルトは 『 --no-ff 』 マージとなる、で問題ありません。

🔘 実は・・・

以前にご紹介したこちらの記事で、master（ブランチ）の状態はローカルとリモートで揃っていました。

何を隠そう、実はプルリクエストを使ってマージしたあと、ローカルに git pull を行いリモートリポジトリの master の変更内容を取り込んだものだったのです。

① ローカルmaster をプッシュ
② ローカルmaster からブランチを切る
③ 切ったブランチをプッシュ
④ ローカルにて、切ったブランチでいくつかコミット
⑤ ローカルのそのコミットをプッシュ
⑥ プルリクにてマージ
⑦ リモートmaster をローカルmaster にマージ

で、そのローカルmaster からブランチを切った状態だったんですね。

A1、B1、C1 セルに数値が、D1 セルには関数（=SUM(A1:C1)）が入っています。
以前の記事：ホップ、ステップ、プッシュ‼ 『 git push 』どしどし押し出そう

という状態で『 --no-ff 』 マージが行われ新しいコミットが作られたわけですね。
これは Bitbucket の画面でして、「Message」のところに『プルリクエスト』という記載も見えると思います。このコミットはプルリクで作られたものだったのです。

そしてそのあと、git pull を実施しました。

master（ローカル）と origin/master（リモート）の状態が揃ったことと、このコミットがプルリクで作成されたものであることがわかります。

ちなみに、この画像で存在する develop ( origin/develop ) ブランチは削除し、ホップ、ステップ、プッシュ‼ 『 git push 』どしどし押し出そうの記事では再度 develop ( origin/develop ) という同じ名前のブランチを作成していたのでした。

🔘 実際にやってみる

ホップ、ステップ、プッシュ‼ 『 git push 』どしどし押し出そうの記事で、2つコミットを進めましたので、これをプルリクでマージしたいと思います。

プルリクエストを作成

Bitbucket にログインし、push 先となっているリポジトリページを開きます。そして、「プルリクエスト」➡「プルリクエストの作成」と進んで下さい。

すると

というページに遷移するので、どういったプルリクエストを作成するのか指定していきます。
『 Title 』と『説明』は今回は自動で入力されたものそのままで何もいじっていませんが、必要に応じて変更してください。
ブランチの閉鎖の✅もどちらでも構いませんが、マージしてしまえば基本的には不要なのでチェックをつけるで良いと思います。

で、「プルリクエストを作成」ボタンをクリックすると、プルリクが作成され『オープン』という状態になります。
まだマージはされていません。
レビュー（とマージ）のお願いが作成された、という状態です。

マージする

「プルリクエスト」の画面に先ほど作成したプルリクがあるので、開きます。本来は、レビューを依頼された人に通知がいき、その人がこのリクエストのケースを確認するのです。

『マージ』というボタンをクリックすれば、画面が遷移します。
『承認』は個人で利用している分にはクリック不要と思いますが、一応自分でもう一度見直してみて内容が問題ないと判断したら、見直したという意味を込めて承認状態にするのが良いと思います。

これで、マージ最終段階です。

マージ元と先のブランチが間違っていないか、など最終確認し、『マージ』ボタンをクリックです。
これで、マージ完了です。

ちなみに

『 Merge strategy 』という項目が、マージ作業最終画面にありました。デフォルトで選択されている Merge commit のままにしましたが、これが最初の方で記載した

他にもないことはないのですが、少しややこしいのと別に使えなくても支障がないのでここでは無視します。

の部分に関係します。

プルダウンを開くと

いくつか選択肢がでてきます。

Merge commit は『 git merge --no-ff 』、つまりノンファストフォワード( Non Fast-Forward )マージになっていますね。

今回はここまで 🔚

ローカル側でマージすればいいじゃん、なんでわざわざリモート側で？という意見もあると思いますが、大事な資料なんかは最後に見直ししますよね？

少し手間かもしれませんが、自分自身の最終確認の工程を挟むという意味でプルリクエストによるマージを行うと、致命的なミスなどを発見しやすくなるかもしれません。

ちなみに、今回ご紹介したプルリクエストが順当にいけば #2 になるはずが、#3 になっているのは #2 を却下したためです。
もしこの疑問をお持ちになった方、すごく真剣にこの記事を読んでいただきありがとうございます😀

最後までお読みいただきありがとうございました 😊

関連記事

#スキしてみて #いま私にできること #最近の学び #学び #これからの仕事術 #IT #学習 #パソコン #駆け出しエンジニア #ITエンジニア #PC #windows #Git #Sourcetree