はじめに
今回の内容は、実際に会社でよく使われている手法や有名な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回は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からの通知を適宜チャットツールから見られるようにすると、開発効率が格段に上がります。