レビューアーはプルリクエストをレビューします。GitHubを利用した場合、プルリクエストによるmasterブランチの差分をWeb画面から確認することもできます(図3下)。
また、変更点の任意の場所にレビューコメントを追加できます。
プルリクエストを作成した担当者は、レビューアーのコメントを受け、修正した変更をリポジトリへプッシュします。コミットプッシュは、下記のように、プルリクエストを送ったブランチを修正し、そのままプッシュするだけです。特別な作業は必要ありません。
以下は、new-featブランチでの作業例です。
$ git commit -m "アイコン位置の指定にcenterを追加"
[new-feat 51635a3] アイコン位置の指定にcenterを追加
1 file changed, 1 insertion(+)
$ git push
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 439 bytes | 0 bytes/s, done.
Total 4 (delta 3), reused 0 (delta 0)
To https://github.com/okamototk/test
801a44e..51635a3 new-feat -> new-feat
修正したプッシュは、自動的にプルリクエストに反映されます。
追加のコミットもプルリクエスト上で管理されるので、プルリクエストの画面を見れば、誰がどのようなコメントを行い、どのような修正がなされたか確認できます。
レビューアーから承認が得られたら、作業用ブランチをmasterブランチへマージし、プルリクエストをクローズします。
マージは、レビューが完了したのを受けて担当者が行ってもよいです。また、リーダー、あるいはレビューアーの承認の下でブランチをmasterへマージする場合には、ブランチをmasterブランチへマージする担当者を決めておいてもよいでしょう。
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff new-feat
Merge made by the 'recursive' strategy.
04_Button/button-iconpos.html | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 04_Button/button-iconpos.html
上記の例では、プルリクエストのマージ点が分かるように「--no-ff」を付けて、ファーストフォワードでないマージを利用しています。マージが完了したら、Gitリポジトリへプッシュを行うと、プルリクエストにマージされた記録が残り、自動的にクローズされます。
不要になったブランチは、上記画面の「Delete branch」ボタンから削除することもできます。
本連載では、4回に渡りGitブランチの運用フローとして注目を浴びているgit-flowとGitHub Flowを紹介してきましたが、いかがでしたでしょうか。
git-flowもGitHub Flowも一長一短です。開発中のブランチとリリースされたリソースをきちんと分けてプロジェクトを管理したい場合は、git-flowの方が合っているでしょうし、簡単なフローで、インクリメンタルに素早くサービスを更新していくようなプロジェクトではGitHub Flowの方がフィットするでしょう。
また、git-flowやGitHub Flowの運用フローは、git-flowやGitHub Flowを採用しないと使えないものではなく、部分的に既存の運用フローに参考にできるものもあります。もちろん、各運用フローをカスタマイズして利用することも可能です。git-flow、GitHub Flowを手掛かりにブランチ運用の改善を行い、皆さんのプロジェクトに合わせてカスタマイズしていくと、より効率的なフローになっていくと思います。
最後になりますが、本稿執筆に当たりレビューいただいた@sinsoku_listyさんに感謝します。
Copyright © ITmedia, Inc. All Rights Reserved.