Draft Pull Requestをリリースしました
素晴らしいアイディアやコードが形になる準備ができたらすぐに、コラボレーターとの会話をスタートするPull Requestを開ける機能があれば良い、とGitHubでは常に思っていました。結果的にPull Requestをクローズすることになったとしても、またはコード全体をリファクタリングすることになってしまったとしても、Pull Requestはコードそのものと同じくらい重要なコラボレーションの要素なのです。 一方で、コードの完成度はまだ高くないけれど、コラボレーションをスタートするための会話としてPull Requestを使用したいと思ったことはないでしょうか？例えば、ハッカソンのプロジェクトでは、このような場面が想定できます。マージするためではなく、他のメンバーにローカルで確認してフィードバックをもらいたい場合、あるいはディスカッションを開始するために、コードを記載しないでPull Re
落ちていたitamaeのintegration specを直しました | うなすけとあれこれ
master build failed itamaeの名前を久々に聞いたのは、昨年11月に行なわれた福岡Ruby会議02でのことでした。前夜祭でのまなてぃさんの発表でitamaeを使っているとの話を聞き、また、懇親会でまなてぃさんがPullRequsetを出したがテストが通らずmergeもしてもらえないという話を聞き、それからずっとitamaeのことがどこか頭の片隅にありました。 その後、転職記事でも触れましたが、業務でpuppetを置き替えることになったときに、ここはitamaeを使ってみようと考えました。そこでitamae-kitchen/itamaeを見に行くと、そもそもmaster branchのでのCIが(2017年3月から)failedになっていることに気づきました。 cookpadでの採用実績や、gihyoでの解説記事、バージョンも1.9を迎えるなどそれなりに成熟しているOS
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
なぜあなたのPull Requestは読まれないのか - Qiita
Pull Requestを出してレビューしてもらってから反映。 どこにでもあるありふれた開発フローに付きまとう、どこにでもあるありふれた問題。 「Pull Requestがレビューされない」 もちろん開発フローにレビューが含まれている以上、レビューをしないメンバーにも非がないとは言えませんが、多くの場合はレビューされないPRには問題があるものです。 デカい 兎にも角にもデカいPRは読むのがつらいです。 もちろん要件が明記されていないなど、他にもPRが読みにくくなる原因はたくさんありますが、一番はこれです。 極端な話、1行変更のPRは他に何も書かれていなくても実装内容を察することができますが、10ファイル100行の差分と箇条書き20点の要件が書かれたPRは内容を把握するだけで一苦労です。 しかし、このこと自体は数カ月でもコードを書いていれば自然と勘づくもの。 問題はなぜPRが大きくなってしま
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
Getting Set Up
There are 5 steps involved in getting Danger running: Include Danger. Creating a Dangerfile and adding a few simple rules. Creating an account for Danger to use. Setting up an access token for Danger with that account. Setting up Danger to run on your CI. #Including Danger We recommend you install Danger via Bundler + a Gemfile. This means that your version of Danger and your plugins are all versi
Dangerで始めるPull Requestチェック自動化 - コネヒト開発者ブログ
こんにちはー！こねひとちほーのえんじにあのフレンズ@Utmrerだよー！ 今回はPull Requestを自動でチェックしてくれるDangerについて紹介します。 Pull Requestでのコミュニケーション Pull Requestのレビューは不具合の指摘やコーディングスタイルの統一、より良いコードのための提案などのために行われます。 ですが、次のようなコミュニケーションをしたことはありませんか…？ タイトルにIssue Idを含めてもらえますか？ WIPみたいなんですがレビューして大丈夫ですか？ Base branchが間違ってます、変更してください。 変更履歴のdocsを更新してください。 このような「実装とは関係のない指摘」はできるだけ減らし、自動化したいものです。それを実現するのがDangerです。 Dangerとは DangerのGitHubには次のように書かれています。 F
「速」を落とさないコードレビュー
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/Read less
GitベースのコードリーディングTips - クックパッド開発者ブログ
こんにちは、投稿推進部の森川 (@morishin127) です。 エンジニアが既存のプロダクトの開発に携わる際、他人の書いたソースコードを読み解くところから始まります。過去に書かれたコードの意図を理解することは自分が書いたものでもしばしば難しく、他人が書いたものならなおさらです。この記事では過去に書かれたコードを理解するための工夫についてお話したいと思います。 なお、この記事ではプロダクトのソースコードはgitおよびGitHubのPull Requestを利用して開発が進められていることを前提としています。 特定の行から関連するPull Requestページを開く クックパッドのソースコードには概してコメントがあまり書かれておらず、見ただけでは理解しづらいような特殊な方法をとっている場合のみコメントを書いている印象です。基本的に実装に関する説明はソースコード中ではなく、GitHubのPu
WIP Pull Request Unhighlignter for GitHub - Chrome Web Store
Unhighlignt WIP, DO NOT MERGE pull requests on GitHub. Demo page: https://github.com/kyanny/chrome-ext-wip-pull-request-unhighlighter-for-github/pulls (visit this page after install this extension) Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/
Sqwiggle が良いという話、またはリモートでアジャイル開発をどう進めるか - naoyaのはてなダイアリー
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Changing the base branch of a pull request - GitHub Docs
Dockerlize and migrate to TravisCI by sue445 · Pull Request #258 · itamae-kitchen/itamae
GitHub - taichi/ci-yarn-upgrade: Keep NPM dependencies up-to-date with CI, providing version-to-version diff for each library
Markdown Pull Request Templates aren't supported when using `hub pull-request` · Issue #1247 · mislav/hub
GitHub - danger/danger: 🚫 Stop saying "you forgot to …" in code review (in Ruby)
GitHub - kyanny/chrome-ext-wip-pull-request-unhighlighter-for-github: Unhighlignt WIP, DO NOT MERGE pull requests on GitHub.
Dependency Update as a Service - Tachikoma.io