search
LoginSignup
106

More than 3 years have passed since last update.

posted at

updated at

GitHubでPullRequestを使った開発フロー

はじめに

今回の内容は、実際に会社でよく使われている手法や有名なOSSのリポジトリなどで使われている手法を、私個人の考えで合成したものです。
ですが、実際の仕事で使っているフローと変わりませんので、実用的なものになっていると思います。
場合によってところどころ合わないなと思うところがあれば、適宜省いたり付け足したりして実用していただければ幸いです。

今回重要な用語

  • issue (問題定義)
  • branch (調べて!)
  • merge (branch同士の変更点を結合する)
  • push (ローカルで作業した内容を、リモートに反映させる)
  • pull request (GitHub上でのMerge要求)
  • commit (変更の確定をリポジトリに含める)

流れ

issue -> branch -> 開発 -> push -> pull request

流れの詳細

issue

全体の開発工程から、できる限り小さな問題に切り出し、その問題をissueとして定義作成します。
例) ログインパスワードに8文字以上しか設定できないようにする

issueの粒度はプロジェクトの開発段階によって変わります。
開発初期であればissueの粒度は大きくなり、リリース後であれば1つのバグ対応のみといった小さな粒度になることが多いです。

プロジェクトによっては、GitHubのProject機能を使う場合もあります。
カンバン方式を使用して、タスクをissueよりもまとまった形で整理できます。
Project機能には、カンバンに書かれたタスクをissueとして作成することができます。
そのため、Project機能を使用してタスクをまとめて書き出し(WBSなど)、issueに変換し作業を開始するといった方法が取られます。

branch

issueを作成したら、それに対応したbranchを作成。(ローカルでの作業)
branch名には作業内容を簡潔に表す名前をつけ、名前の最後に対応するissue番号を付属させます。
例) git checkout -b valid_password#1

ブランチを作成したら、そのブランチをリモートにPush。
これによってチームの人が、作業の開始を把握できます。
例) git push origin valid_password#1

開発

先ほど作成したbranchで作業を始めます。
作業をすると変更をcommitする必要があります。
この時、Gitに慣れていない人は、作業が終わった後に一括でcommitしがちです。
しかし、commitの粒度が大きいとコードレビューをする時などに非常に見づらく、大変です。
最初の間は目安として、1ファイルを編集するとcommit、1ファイルの変更が多くなる場合は1機能ごとにcommitなど、とにかくcommit間隔を狭めることを意識しましょう。

commit間隔の他に、commitメッセージもかなり重要です。
コミットメッセージを後から見直した時に、メッセージから作業内容がだいたい分かるようにすべきです。
先頭から作業内容の対応するissue番号、
作業の方向性を表すAdd Update Move Remove Change Rename等の動詞、
作業内容の説明(外部に公開する場合は英語)、
を元にメッセージを組み立てます。
例) #1 Add パスワードのバリデーションを追加

push

作業が終わったらローカルの変更をpushしましょう。
pushするためには、自分の派生元のbranchの最新の変更をpullしましょう。
pullが正常に完了すればGitHubにpushします。

作業完了のpush以外にも、作業がある程度進めば定期的にpushすべきです。
定期的にpushすることで、全員の作業の進捗状況が把握できたり、分からないところがあった場合にGitHubを見せることによっていつでも質問できる、といった利点があります。
作業進捗が少しでもあった場合、できれば1日1回はPushしましょう。

pull request

作業したbranchをGitHubにpushしていれば、pull request(以下pullreq)が送れます。
pullreqを送ることによって、結合元branchと結合先branchの変更点や、commitログ、pullreqメッセージをまとめたmerge申請を作成することができます。
そのpullreqは履歴として残るので、後から見直したい時にも便利です。

pullreqの詳細画面には緑色のmergeボタンがあります。
小さなプロジェクトでは自分でmergeしてしまうことも多々あります。
しかし、コードレビューをする場合や、リポジトリの設定で一部の人しかmergeできないようにしている場合もあります。
その場合、mergeしてくれるのを待ちましょう。
mergeしたら結合先の変更をpullでローカルに反映させましょう。
その後、開発フローの先頭に戻ってissueから始めましょう。

応用編(小ネタ)

  • pullreqのメッセージにclose #1みたいに書いておくと、mergeされた時勝手にissueがcloseされます。
  • CIツールをGitHubと連携させると、pushやpullreqを送った時などに自動的にテストを走らせ、GitHub上でも表示されるようになります。
  • pullreqやissueなどのテンプレートをリポジトリに含めることによって、作成時にテンプレートが自動入力された状態から書き始めることができます。
  • Slackなどのチャットツールと連携し、GitHubからの通知を適宜チャットツールから見られるようにすると、開発効率が格段に上がります。

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
What you can do with signing up
106