Ruby on RailsによるWebアプリ開発記(03)

前回
Ruby on RailsによるWebアプリ開発記(01) - メモ置き場
 Ruby on RailsによるWebアプリ開発記(02) - メモ置き場

ルールは決まったけど、やっぱりちょっとやりにくい

これまで、「作業が完了したらPull Requestを作成してコードレビュー」という方針で実施してきたが、下記の問題が多々発生した。

Pull Requestが作成されるまでは、各自の作業状況が把握しにくい
- commitログを見ればどんな変更を行っているかは一応把握できるが、全作業の何%が終わっているのかがわからない。
意識相違やミスがキャッチできない
- Pull Requestでのソースレビュー時に「ここはこういう書き方にすべき」などの指摘が入った場合、大きな手戻りが発生してしまう。
(その機能実装についての)悩みや疑問がうまく共有できない
- 質疑応答や議論は、別途「CircleBoard」で行っていたが、質問内容が分散したり、また後々になって探す手間がかかったり、細かい悩みはあった。(CircleBoard自体は優秀な掲示板ツールではある)

WIP PR導入

「WIP PR(Work In Progress Pull Request)」という方式がイイという噂を聞き、試しに導入してみたところ、とても素晴らしかったので、本格導入することになった。

WIP PRとは

「git commit --allow-empty を使った WIP PR ワークフロー - Qiita」にあるように、“作業途中で出すPull Request”を使うワークフローとのこと。
通常のPRに比べ、レビューを早期に行えるので、修正コストが低かったり、作業進捗が把握しやすかったりするメリットがある。デメリットとしては、commitやpushに一工夫必要なので、慣れないうちは少し難しい、くらいであると感じた。

やりかた

作業開始時

1. ブランチ作成

$ git cehckout master
$ git pull
$ git checkout -b ブランチ名
$ git commit --allow-empty -m '作業開始っぽいメッセージ'
$ git push origin ブランチ名

2. タイトル頭に「[WIP]」をつけ、Pull Requestを作成

作業中

1. 聞きたいことや言いたいことがあれば、作成したPull Request上にコメントを残していく

他のメンバーにはGitHubから通知が行くので、(おおむね)すぐに気づいてもらえる

2. いつも通りcommit&pushを行う

高頻度で行う(前回記事参照)

作業終了時

1. Pull Request名変更

Pull Request名から「[WIP]」を外し、レビューを依頼

2. masterへのmerge(レビュー完了後)

commit履歴の整理(作業開始時/作業完了時以外にcommitを行った場合、masterにmergeする際に邪魔になるので、消去)

$ git log                    # ブランチ作成時の最初のコミット番号を控える(xxxxxxx)
$ git rebase -i xxxxxxx      # 最新のコミットのみ「pick」のこりは「squash」を選択する
$ git push -f origin ブランチ名

GitHub画面からのmerge

conflictにより自動mergeできない場合、ローカルで実施する

$ git checkout master
$ git pull
$ git merge ブランチ名      # -> CONFLICT (content): Merge conflict in xxxxxx と出たものを、エディタで修正
$ git commit -m 'ブランチmergeっぽいメッセージ'
$ git push origin master

3. ブランチ削除

$ git checkout master
$ git branch -d ブランチ名            # ローカルブランチ削除
$ git push --delete origin ブランチ名 # リモートブランチ削除

導入後

ちょっとわかりにくい内容ではあるが、やってみるとこれがかなり便利であると実感した。

ひとりひとりの作業が独立している
対面で話す機会が少ない
個々の能力があまり高くない(ので、指摘が多い)

といったプロジェクトには、かなり効果が高いのではないだろうか。