初めてコードレビューされる人のためのpull requestとcommitの作り方 - Qiita
pull requestの作り方について 作業途中でもpull request作ったほうがいい。 作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる タイトルに書くこと 作業の内容が分かるタイトル descriptionに書くこと WHY WHATを必ず書く Viewに変更がある場合は、スクリーンショットを貼る 関連のissueやpull reqeustへのリンクがあれば書く コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど) イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。 どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る git commitの方法について 僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書
今のコードレビューのやり方 - $shibayu36->blog;
コードレビュー - hitode909の日記 この話。 大体こういう風なやり方をしてる。Diffだけを見るんじゃなくて手元でもコードチェックアウトしてて、それとDiffを行ったり来たりしながらレビューすることが多い。こういう方法のほうがかっこいいよねみたいなのは書くけどその通りにしてもらうことを強制はしないというのも賛同。 逆にcommitの中身*1はあえて見ないようにしてる。僕はレビューする時に、そのコードについての学習が行われていない状態で見たほうが良いなと思っている。commitの中身を１つずつ見ていくと学習が進んでしまって、少しわかりづらいコードもあっても、学習が進んでいるせいで無意識に目からすり抜けてしまうという経験があったので、あえてcommitみないということをしてる。 例外もあって、少し大きめなリファクタリングが行われた時はcommitを１つずつ読んでいくことが多い。少し大
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
