2018-10-30に更新

一人プルリクエストのすゝめ

プルリクエストといえばGitHub等で業務の際やOSSに貢献する際などに利用する、自分の対応したブランチを取り込んでもらうための仕組みですが、何気に一人で使うのにもメリットがあったりします。どういったメリットがあるのか紹介します。

とりあえずGitHubでプルリクエストを作成してみる

何にしろまずプルリクエストをGitHub上で作成してみます。ちなみにGitHubだけでなく、BitBucketやGitLab等でも同様のことは可能です。

ブランチを作成

まずはブランチを作成します。エディタやGitクライアントの機能でも良いですし、コマンドラインで作成する場合は下記のように実行します。

git branch prtest

これで現在のブランチを基底にしたprtestというブランチが作成されます。作業ブランチをこのprtestに切り替えておきます。

git checkout prtest

ブランチにコミットする

適当に何かのファイルを編集し、コミットします。今回はREADME.mdを更新しました。

git add README.md
git commit -m "Update README"

GitHubにpushする

pushしてGitHubのリポジトリを更新します。

git push origin prtest

すると、この時点でGitHubのリポジトリを見てみると下記の画像の様に黄色背景のところのような感じで、最近pushしたブランチが表示されています。このようにして簡単にプルリクエストを作成できるようになっています。ここの「Compare & pull request」ボタンを押してプルリクエストの作成画面へ移動しましょう。(プルリクエスト一覧ページからでも作成できます)

prnotify.png

プルリクエストを作成する

ボタンを押すと下記のような画面が表示されます。

pr.png

色々と入力欄がありますが、一人でやっている場合はとりあえずわかりやすい件名を入れておけば十分でしょう。あとは整理したければ気分で色々と入力しておいてください。必要な箇所を入力したら「Create pull request」を実行します。

プルリクエスト詳細画面

作成すると、下記のようなプルリクエストの詳細画面にアクセスすることができるようになります。

prdetail.png

この画面では、先程追加したコミットが表示されています。今後このブランチにコミットを行うと、ここに列挙されます。そのため、このブランチで何をやっているかというのが非常にわかりやすくなります。

コミットの粒度

Gitについて調べた方の中には、「コミットの粒度」がどうとか、というのを見たことがある人もいるのではないかと思います。このプルリクエスト画面を見ると、どういったコミットが積まれているかをわかりやすく見ることができますので、なんとなくいい感じに並べてみたい気分になったりしませんか?

一人でやっている場合は恐らくセーブ感覚で適当なところで「ひとまずセーブ」みたいな感じでコミットしている場合も多いかもしれませんが、せっかくなので各コミットで何をやっているかをわかりやすく書いてコミットしてきましょう。「投稿機能を追加」とか、「トップページのデザインを変更」のような感じです。OSSにも貢献してみたい場合などは英語で練習しておいても良いと思います。

File Changed

File Changed画面も非常に有用です。開いてみると下記のような画面が表示されます。

filechanged.png

このように、このプルリクエストの差分を見やすく表示してくれます。今まではコンソール上でgit diff等で差分を確認していた方もいると思いますが、このようにGitHub上で確認ができると便利です。マージ前に自分でざっとセルフレビューして変なデバッグ処理が混じってしまっていたりしないかなどを見ることができますし、このプルリクエストはマージしてプルリクエストがクローズされた後も閲覧できますので、「あの時のプルリクエストって何を変更してたっけな~」という場合にもブラウザだけで非常に簡単に確認しやすいです。

ただ、ここもファイル数や行数がとんでもない量になるとカクカクになってしまいますので、プルリクエスト自体もなるべく必要最低限の粒度に調整することが、綺麗なプルリクエストの運用の仕方になります。

マージする

最初の画面にあった、「Merge pull request」ボタンを押すとここでいうprtestブランチがmasterブランチにマージされます。ブランチを削除するかどうか聞かれますので、削除しましょう。この対応に対して修正が必要な場合はこのブランチ内で修正するのではなく、別途修正用のブランチを作成して別のプルリクエストを作成します。もったいないからと残しておく必要はありません。だらだらと残しておくとよく分からないブランチが溜まっていきますので、終わったら即削除です。

基本的にはこれで完了です。masterにはマージコミットだけが残りますので、万が一差し戻しなどが必要になった時なども簡単にrevertできます。masterブランチにCIを入れている場合はこのタイミングで実行されると思いますのでデプロイもCIに組み込んでいる場合などはGitHubの画面上だけでデプロイができます。

コンフリクトした場合は

色々やり方はあると思いますが、とりあえずローカルで該当ブランチに切り替えている状態でgit rebase masterし、コンフリクトを解消してからgit push origin prtest --forceみたいな感じでpushし直せば良いと思います。

forceはしちゃいけない、みたいな記述を見たことがある方もいるかもしれませんが、それはあくまでもmasterブランチや、どこかで稼働させているブランチなどに対してのことです。今回のような何かの対応用のトピックブランチは自分しか使うことはなく何にも影響を与えることは無いのでマージするまでは割と適当でOKですので、force pushしてしまって問題ないです。(ただし操作ミスで間違えてmasterにforce pushしないようにしましょう)

まとめ

とにかく、プルリクエスト画面自体が非常に便利なものなので、今まで仕事じゃないし関係ないや、と思って使っていなかった方も、是非使ってみた方が楽しいと思います。

一人プルリクエストはオススメです。


だら@Crieit開発者

Crieitの開発者です。 主にLAMPで開発しているWebエンジニアです(在宅)。大体10年程。 記事でわかりにくいところがあればDMで質問していただくか、案件発注してください。 業務依頼、同業種の方からのコンタクトなどお気軽にご連絡ください。 業務経験有:PHP, MySQL, Laravel5, CakePHP3, JavaScript, RoR 趣味:Elixir, Phoenix, Node, Nuxt, Express, Vue等色々

Crieitはαバージョンで開発中です。進捗は公式Twitterアカウントをフォローして確認してください。 興味がある方は是非記事の投稿もお願いします! どんな軽い内容でも嬉しいです。
なぜCrieitを作ろうと思ったか
関連記事

コメント