GitHub Next investigates the future of software development
ProductIntroducing draft pull requestsYou can now use draft pull requests to clearly tag when you’re coding a work in progress. At GitHub, we’ve always felt that you should be able to open a pull request to start a conversation with your collaborators as soon as your brilliant idea or code is ready to take shape. Even if you end up closing the pull request for something else, or refactoring the co
Rails Developers Meetup #4 でお話しした「プロを目指すRailsエンジニアのための公開コードレビュー」の続編として、すべての解答にコメントを入れてみました。 長いので前編と後編に分けてあります。 【前編】 - この動画の注意事項等 - 発表当日の内容のおさらい - #9 ebihara99999 - #10 ttwo32 - #11 cohakim - #12 sanfrecce-osaka - #14 yamotonalds - #16 ota42y - #17 itume - #18 yusuke319 - #19 bellwood4486 【後編】 https://youtu.be/yDxg0sXHXOo - #20 tsumuchan - #21 toyokappa - #22 ryu39 - #23
最近サーバサイドをやりつつiOSアプリ開発をやったり何でも屋になっている hilotter です。 GithubのPullRequestレビュー機能、便利ですね。 チーム開発においては相互レビューが非常に大事です。 今回は、レビュー依頼を行った際にSlackに自動通知するようにしたらより便利になったというお話を共有させていただきます。 SlackのGitHub連携の課題 Slack公式のGithub連携がありますが、こちらは以下の2点が課題となっていました。 1. メンション付きのコメントをしても、message-attachmentsの記法になっているため、うまく通知されずコメントを見落としてしまう このため、コメント後にSlackでも「コメントしました!」と2重で連絡をする必要がありました。 2. PullRequestのレビュー依頼を行ってもレビュアーへの通知が飛ばないため、レビュー
いざPull Requestのレビュー!と挑んだ瞬間、「ここタイポな」という先制パンチをくらうのはとても残念なことです。 また、これは指摘しているほうにとってもチェックが負担で、気が重いものです。 人間は人間にしかできないチェックに集中すべきですし、貴重なレビュー時間を誤字脱字の修正に使うのはもったいないです。そこで開発したのが、タイポの自動検知と修正を代行するBot。その名もtypotです。 chakki-works/typot こちらは先日公開がアナウンスされたGitHub Marketplaceと共に公開された、新しいGitHubアプリの形態であるGitHub Appsで作成しています(それまではWebhookかOAuthだった)。 GitHub AppsはOAuthのようにユーザーではなく、リポジトリにひもつく形態になります。そのため、管理者ユーザーがいなくなった(あるいは権限を失
こんにちはー!こねひとちほーのえんじにあのフレンズ@Utmrerだよー! 今回はPull Requestを自動でチェックしてくれるDangerについて紹介します。 Pull Requestでのコミュニケーション Pull Requestのレビューは不具合の指摘やコーディングスタイルの統一、より良いコードのための提案などのために行われます。 ですが、次のようなコミュニケーションをしたことはありませんか…? タイトルにIssue Idを含めてもらえますか? WIPみたいなんですがレビューして大丈夫ですか? Base branchが間違ってます、変更してください。 変更履歴のdocsを更新してください。 このような「実装とは関係のない指摘」はできるだけ減らし、自動化したいものです。それを実現するのがDangerです。 Dangerとは DangerのGitHubには次のように書かれています。 F
We review quite a few code diffs; it is our job. Often, when jumping on a new project, we start by reviewing pull requests. After years of this we have each developed a few tricks to find problematic areas when reviewing our first pull request on a legacy codebase. And so I present to you an unexplained, incomplete, and arbitrarily grouped list of keywords that will cause us to read your Rails cod
This content may be out of date. For the newest content, see the API posts on the GitHub Blog. All of GitHub's Docs are now in one place! You can see Apps, REST API, and GraphQL API on GitHub Docs. Today we're releasing a preview API for Pull Request Reviews! To access the Pull Request Reviews API during the Early Access period, you must provide a custom media type in the Accept header: applicatio
GitHub: haya14busa/reviewdog: A code review dog who keeps your codebase healthy 英語記事: reviewdog — A code review dog who keeps your codebase healthy – Medium reviewdog というlinter などのチェックツールの結果を自動で GitHub の Pull Request にコメントしたり, ローカルでも diff の結果から新たに導入されたエラーだけを表示するようにフィルタリングできるツールを作りました. 英語記事 を Medium に書いたし,README も書いたので 日本語記事はまぁいらないかなぁと思ったけど,柄にもなく Vim 関連以外で普通に便利ツールを書いてしまって,これは日本語でも簡単に共有しようかなぁと思いこの記事
be_a_rails_contributer.md これはなに Railsにプルリクストを送るときに知っておくと便利なお作法集 Railsにプルリクエストを送りたいけど何から始めたらいいのかわからない人向けの指針 お作法についてはRuby on Rails に貢献する方法 | Rails ガイドを参考にしています。 前提知識 Railsのコードを読むには、最低限次の二つの知識があったほうがよいです メタプログラミングRubyを読了した程度のRubyの知識 読もうとしている機能に関する知識をRuby on Rails ガイドなどで得ておく テスト環境 rails 自体のテストは rails-dev-box にある vagrant 環境越しにやります 基本的に各ライブラリ(例: activerecord)のディレクトリで rake test して実行します。全体は時間かかりすぎる>< rail
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く