Github Flow × WIP PR開発フローを考えた。

きっかけ

開発フローが中途半端に定まってない。
社内で何か知識共有をしたかった
WIPでプルリク出すとか、なんかかっこいい。
slideshipでスライド作ってみたかった。

スライド作った。

良かったら見てってくださいな。
slideship使って作ったけどもう使いたくない。

以下

スライドのダイジェスト版です。時間がない人用。

Github Flowとは

Git/Githubを利用して開発を進めていく流れ。
シンプルにいうと、「開発 → プルリクエスト → レビュー → デプロイ & マージ」

大原則「master ブランチはいつでもデプロイ可能」

WIP PR (Work In Progress Pull Request)

GithubのPull Requestを開発途中で行う。作業途中のトピックブランチを PR することによって以下のような利点がある。

早期にコードレビューのプロセスをまわせるので仕様誤認や設計不備があった場合の修正コストが比較的低い
修正コストが低いため、レビュワーも気兼ねなく指摘することができる
作業に着手した段階で PR が作成されるので進捗を追いやすい / 他のメンバーが何をやっているか可視化される

トピックブランチ名はこうしたい

[tag名]/# [issue番号] + 動詞 + 目的語

ex)

feature/#1-modify_upload_dest_of_image_file
hotfix/#48-fix_user_local_validation_error

タスクリストの利用

Github Favored Markdownでは、タスクリスト機能が使える。

こうかくと↓

- [ ] test
- [x] test

こうなる↓

開発者側、依頼者側から見た作業フロー

依頼者側

issueを立てて、開発者に依頼する。issueは、可能な限り具体性のある内容にする。
進捗の確認は [WIP] のついてるプルリクエストから行う。
開発者からのレビュー依頼がきたら、もしくは [WIP] の外れているプルリクエストがあったらレビューを行う。
問題なければLGTM (Looks Good To Me) コメントをし、プルリクエトを承認。developブランチにマージする。
マージ後のトピックブランチは削除する。
定期的にdevelopブランチをmasterブランチにマージ（もしくはリベース）する。

開発者（作業開始）

作業開始時にdevelop ブランチからトピックブランチを切り、空コミットを作成する。
作業内容を細分化し、タスクリストにまとめた内容を記述した空プルリクエストを送った後に作業を開始する。

開発者（作業中）

空コミットは後で見たとき綺麗な履歴となるようにgit commit --amendで上書きする。
ローカルのトピックブランチで開発、コミット。タスクリストの作業が終わるたびにpushし、プルリクエスト中のタスクリストにチェックを入れる。
基本的にはissueの中身にしか対応しない。追加で変更点があった場合はその内容をプルリクエストに追記する。

開発者（作業終了後）

プルリクエストのタイトルから[WIP]を外し、右上のReviewer欄でレビュワーを指定する。コメント欄でメンションとともに、レビューの依頼を行う。
レビューの依頼は、変更箇所、レビュワーに見て欲しいところを具体的に明示した上で行う。

実際のコマンド（開発者側）

# developブランチに移動
git checkout develop

# developブランチを最新にする
git pull origin develop
 
# 新しい作業ブランチを作成
git checkout -b feature/#1-modify_upload_dest_of_image_file

# 空コミットを作る
git commit --allow-empty -m "[WIP] Add user notice" # 最初の作業内容。

# push 
git push origin feature/#1-modify_upload_dest_of_image_file

プルリクエストの作成

注意点

タイトルの先頭に[WIP]を入れる
送り先のブランチはdevelopにする
タスクリストを利用する。

懸念点

いちいちissue立てるのがめんどくなる
issue以外の変更点はどうする？
単に作業を分割したい場合にどうする？

おまけ

hubの利用

githubのプラグイン的なもの。

https://github.com/github/hub

git pull-request -m "[WIP] ${PR 名}" -b ${送り先のブランチ}

コマンドでプルリクエストが送れたりする。

aliasの作成

.gitconfig 内でaliasを指定できる。

ex)ブランチを切り、空プルリクエストまでを自動化

[alias]
    ec = commit --allow-empty -m \"[WIP] First commit\"
    mkpr = !"f() { git checkout -b $1; git ec; git push -u origin $1; open $(hub pull-request -m "$1"); }; f"

こんな感じに使う。

git mkpr feature/#1-modify_upload_dest_of_image_file

Templateの利用

gitリポジトリのルート直下で .github/PULL_REQUEST_TEMPLATE.mdというファイルを作成しておけば、プルリクエスト作成時にテンプレートとして利用することができる。

→ pull requestにおけるフォーマットのばらつき、情報不足を防げる。

commitメッセージの修正法

--amendをつけてもう一度commitするだけ。

git commit --amend -m "修正メッセージ"

First commit をgithubの履歴に含めたくない場合、最初の細分化されたタスク終了時に、これを用いたcommitを行う。

→ githubの履歴を綺麗にしたい場合、有用。

logをもっと見やすく

エイリアスを作っておく。

git config --global alias.lg 'log --graph --decorate --color --oneline'