pull requestの作り方について
作業途中でもpull request作ったほうがいい。
作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる
タイトルに書くこと
- 作業の内容が分かるタイトル
descriptionに書くこと
- WHY WHATを必ず書く
- Viewに変更がある場合は、スクリーンショットを貼る
- 関連のissueやpull reqeustへのリンクがあれば書く
- コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど)
- イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。
- どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る
git commitの方法について
僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書いてます。
できるだけ小さい単位でcommitする。
- いろいろな作業を同時にせずにひとつひとつ作業する
- モデルを作るとか、モデルのあるメソッドを実装するとか
- モデルのあるメソッドとそのテストを実装するとか
- あるコマンドを実行してファイルを生成したとか(rails g ~~)
- あとでcommitとコメント見ると、なにをしたか分かるってのをできるだけ目指す
- ひとつひとつ小さい単位でコードを書く方が綺麗なコードになりやすい。
- commitを見て、分かりにくい箇所はコード上にコメントもしくは、参考にしたリンクを貼るといい
- イメージは、commitはよりレビューをしやすくするためのもので、そのためにひとつひとつの作業の内容と作業の流れが分かるように作るって感じ。
できるだけバグがないcommit
- 理想はそれぞれのcommitで動くほうがいい
- (fixのcommitはどうしても発生してしまうけど)
実装している途中に間違えたとき
- 本当に全部削除するなら、commitごとなくすのがいい
- fixであれば、本当に読む人のことを考えるとrebaseして修正とかもできるけど、そこまでせずに、fixのcommitをすればいい
レビューの指摘の修正をするとき
- それぞれのcommentに対してcommitを作る。
- 特にレビューの指摘が治ったか見るときは、commitを見て治ったか確認するほうが楽なため。
- commentしたのに漏れることもあるため、修正したらgithubのコメントに対してコメントを返す。治したとか簡単でいいので。
- 追加で修正したいことなどある場合は、pull requestへのcommentでタスクリスト作るといい。
そもそも
- あまり大きなpull requestは作らないほうがいい
- 巨大pull requestを避ける9個のポイント http://qiita.com/reikubonaga/items/ac123bed89cf2b55a510
インターン生・未経験者向け投稿
以下も同じように、これからスキルを身につけたい人向けに開発インターンで役立つことを書いています。
- 開発インターンで気をつける5つのポイント http://qiita.com/reikubonaga/items/d00c179957d57f48bf73
- rails開発に加わる前に学んで欲しいこと http://qiita.com/reikubonaga/items/60b4f6ee0a86ed06e83b
- 技術面接を受ける前に確認しておくといいこと https://www.wantedly.com/companies/wantedly/post_articles/42207