チーム開発におけるプルリクの作法 - Qiita
僕の考える、GitHubでチーム開発をする際のプルリクエスト（プルリク）の作法を書いてみました。プルリクという名前から当たり前ですがGitHubを使うことを想定してます。 十分小さくプルリクを作ろう プルリクが小さいと、レビューが簡単になり、変更がすばやく中央のブランチに取り込まれるため、レビューの精度が高くなり開発スピードも早くなります。 タスクやIssueが一つで表現されていても、やりたいことを予めいくつかに分けて、それに対して一つプルリクを出しましょう。コードレビュー中に他にやりたいことややるべきことが出てきたら、同じプルリクで作業せずに別のプルリクで行いましょう。 プルリクを出す前に「これとこれとこれのプルリクを出します」とIssueなどで宣言されている状態がベストです。プルリクの分け方に不安があるならこの状態でもレビューをもらっておくと良いでしょう。 単体でリリースできる単位でプ
Pull Requestのレビューが辛くて会社をやめたい
私はプログラマに向いていないのかもしれない。 うちのチームではコミットをmasterブランチへマージする前に、Pull Requestを出してそれをリーダーや他の人がレビューすることになっている。（たぶんよくあるフロー？） そのPull Requestでもらうコメントを見ると死にたくなってくる。特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。 レビューにおいてそういった強い言葉がときとして必要なことは理解している（そういえばこなものもあったなと思い出した http://cpplover.blogspot.jp/2013/07/linuxml.html ）。またそういったコメントを残す相手との仲が険悪なわけでもない。またよいと思ってくれたらしいところは褒めてくれたりLGTMしてくれたりもする。 だけどそれでも辛い。きつい言葉を向けられる
GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita
はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です！ 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
