Introducing draft pull requests
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
チーム開発におけるプルリクの作法 - Qiita
僕の考える、GitHubでチーム開発をする際のプルリクエスト（プルリク）の作法を書いてみました。プルリクという名前から当たり前ですがGitHubを使うことを想定してます。 十分小さくプルリクを作ろう プルリクが小さいと、レビューが簡単になり、変更がすばやく中央のブランチに取り込まれるため、レビューの精度が高くなり開発スピードも早くなります。 タスクやIssueが一つで表現されていても、やりたいことを予めいくつかに分けて、それに対して一つプルリクを出しましょう。コードレビュー中に他にやりたいことややるべきことが出てきたら、同じプルリクで作業せずに別のプルリクで行いましょう。 プルリクを出す前に「これとこれとこれのプルリクを出します」とIssueなどで宣言されている状態がベストです。プルリクの分け方に不安があるならこの状態でもレビューをもらっておくと良いでしょう。 単体でリリースできる単位でプ
Force push timeline event
November 15, 2018 When you force push to a branch GitHub now displays the force push event in the “Conversation” timeline of your pull request. Clicking the “force-pushed” link will show a two dot comparison between the two commits. Learn more about pull requests The release of GitHub Desktop 1.5 includes three important improvements: You can now easily initiate a merge from the branch dropdown, a
Pull Requestに動作確認方法を書け - 橋本商会
ある程度アプリケーションの規模が大きくなってくると、ある変更がどこまでの影響範囲だと思っているのかがコミュニケーションにおいて重要
GitHub で新しく作ったブランチへ push すると Pull Request のリンクが表示される - アルパカ三銃士
GitHub の公式ブログにも出てる。 blog.github.com 実際に local でブランチ切って push するとこんな感じ ❯❯❯ git push origin $(git b) Counting objects: 5, done. Delta compression using up to 8 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 982 bytes | 982.00 KiB/s, done. Total 5 (delta 3), reused 0 (delta 0) remote: Resolving deltas: 100% (3/3), completed with 3 local objects. remote: remote: Create a p
プロダクトのドキュメントにプルリクエストを送れる仕組みがすごい - Qiita
これ↓なんですけど、意外と RT や Like が付いてたので、ちゃんと書きますね。 しっかしMicrosoftのドキュメントシステム良く出来てるなー。右のEditボタン押すとGitHubが開いてすぐPR送れる。あちらでマージされれば即サイトに反映される。Contiributorsに自分のアイコンが増えた♪ これはフィードバックするのに「面倒」は理由にできないですぞ。https://t.co/9KhAwhV5PP pic.twitter.com/r46zFUvkEp — あめいぱわーにおまかせろ! (@amay077) 2018年6月12日 このツイは Microsoft の製品やサービスのドキュメントについてなんですが、 Microsoft Docs というポータルがありまして、同社のサービスの多くはここでドキュメント公開されている模様です。 ここで公開されているドキュメント群は、バック
レビューをもらいやすい細かい プルリクの切り分け方 at PHPerKaigi 2018 - Speaker Deck
All slide content and descriptions are owned by their creators.
Jasper - A flexible and powerful issue reader for GitHub
You will be able to read, track and discover many active issues very flexibly by using Jasper in GitHub. It is enabled by a powerful function called "Stream" of Jasper. example repo:nodejs/node is:issue label:bug You can use the GitHub Search query to create various criteria, such as issues I created, pull requests of nodejs/node, bug labeled issues, etc. to view issues and receive update notifica
GitHub のプルリクで blame する ghpr-blame.vim つくった - はやくプログラムになりたい
先日 kazuho さんが git blame でプルリクを表示するスクリプトをつくってらっしゃって，便利そうだったので Vim プラグインをつくってみました． ファイルの各行がどのプルリクで変更されたかを確認し，気になるプルリクはその場で詳細を確認することもできます． github.com 使い方 インストールはお好みの Vim プラグインマネージャを使うなどしてください． 1. ファイルを開いて :GHPRBlame を実行 :GHPRBlame を実行すると裏で git-blame が走り，カレントバッファのファイルの各行のプルリク情報を git blame --line-porcelain で引っ張ってきます． 引っ張ってきた情報を元にカレントバッファの左に細長い一時バッファが開き，そこに各行に紐付いたプルリク番号が表示されます（プルリクに紐付いていない行は何も表示されません）．
GitHubのWebhook活用
2017年7月からGMOアドマーケティングのSSP開発チームにJoinしたKA.Mです。 先日、試用期間も無事終え落ち着きました。 GMOアドパートナーズグループには、住宅補助手当という オフィスビル近隣に住んでいる人が対象となる福利厚生があるので、 そろそろオフィスビル近くに引越かと考えています。 早速本題です。 Webhookってなに? Webhookとは特定の条件を満たした際に他のアプリケーション/URLへリクエストする仕組みとなります。 SSP開発チームでは今回紹介するGitHubの他にSlackのWebhookも活用しています。 活用事例 SSP開発チームはGitHubのレビュー機能を利用したGitHubフローで開発しています。 Pull Request = レビュー依頼ではないため、レビュー依頼はラベル機能を利用していますが、 レビューNGとなった場合、主に3つ問題がありました
Android開発のコードレビューbotを乗り換えた話 - クックパッド開発者ブログ
モバイル開発で利用しているコードレビューbotを最近乗り換えた話をします。 コードレビューbotとは コードレビューbotはPull Request(以下PR)に対して、静的解析した結果などをコメントする機能を持つプログラムの事を指します。 コードレビューbotを導入すると、些末な内容はbotが勝手に指摘してくれるため、レビューワーがより重要な内容のレビューに時間を使うことが期待できます。 有名なサービスにHoundやSideCIなどがあります。 Android開発でのレビューbotの役割 CookpadのAndroid開発では、下記の項目をPR毎に実行しています。 PRのマイルストーンチェック FindBugsを利用した静的解析 AndroidLintを利用した静的解析 license-tools-pluginを利用したOSSライセンス情報のチェック アプリのビルド deploygate
GitHub初心者はForkしない方のPull Requestから入門しよう // qnyp blog
2013/08/13 GitHubの新デザインに対応するために記事内容・画像をアップデートしました。 こんにちは、ブログ記事を書くのが約2年ぶりのruedapです。 さっそくですが、Pull Request（プルリクエスト）機能を使ったことはありますか？ GitHubの代表的な機能で、「pull req」や「PR」とも略されたりして、名前はよく聞きますよね。 この記事は、Gitはいちおう入門済みで、GitHubも使い始めたけど、Pull Request機能はまだ使ったことがない、そんな人に向けた 簡単な方のPull Request の入門記事です。 もう1つのPull Requestについて Pull Request機能の解説としてよくあるのは「他の人のリポジトリを自分のGitHubアカウントにFork（コピー）してきて、変更を加えて、それを元のリポジトリに取り込んでもらうようにリクエスト
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
Pull Requestに潜むタイポを自動的に検出し、修正を代行するBot - Qiita
いざPull Requestのレビュー！と挑んだ瞬間、「ここタイポな」という先制パンチをくらうのはとても残念なことです。 また、これは指摘しているほうにとってもチェックが負担で、気が重いものです。 人間は人間にしかできないチェックに集中すべきですし、貴重なレビュー時間を誤字脱字の修正に使うのはもったいないです。そこで開発したのが、タイポの自動検知と修正を代行するBot。その名もtypotです。 chakki-works/typot こちらは先日公開がアナウンスされたGitHub Marketplaceと共に公開された、新しいGitHubアプリの形態であるGitHub Appsで作成しています(それまではWebhookかOAuthだった)。 GitHub AppsはOAuthのようにユーザーではなく、リポジトリにひもつく形態になります。そのため、管理者ユーザーがいなくなった(あるいは権限を失
GitHub を使いやすくする Chrome Extension 5 選 - Qiita
Pretty Pull Requests (Github) Chromeウェブストア - Pretty Pull Requests (Github) Pull Request を読むときに便利なエクステンション。 ファイルをアコーディオンで開閉したり、追加された行または削除された行のみを表示することができる。 長い PR を読むときに特に便利。 GitHub Wiki Search Chromeウェブストア - GitHub Wiki Search GitHub Wiki を検索するためのエクステンション。シンプルで使いやすい。 検索語をハイライトしてくれたり、検索中はプログレスバーがでたりと気が効いている。 これを使わずに検索しようとすると GitHub Wiki の git リポジトリをクローンして、 git grep するはめになる。 GitHub.Expandinizr Chrom
Pull Request発行時にそのコミットIDでデプロイされた環境を自動構築してレビュー時/マージ前に確認しやすくする仕組み - トレタ開発者ブログ
インフラをアレしてる佐野です。Pull Request(以下、p-r)が発行されると、そのp-rのコミットIDでデプロイされた環境を自動構築する仕組みを作ったので、今日はそれについて。マージ直前の環境が立ち上がるのでレビューアはレビュー時にコードを追うだけでなく、ブラウザ/アプリの接続先をこの環境に向きかえることで実際のアプリケーションの動作も確認できるようになります。レビューが非常に捗ります。 動作 仕組み GitHubのWebhookについて 自動構築の処理 Dockerの活用 tmpfsの活用 まとめ 1. 動作 こんな感じです。ここで、この通知するボットおよびこの仕組みを以下、シャイニング・ウィザードと呼ぶことにします。シャイニング・ウィザードというのは好きなプロレスの技でして最初はこの基盤の仮名だったのですが、チーム内で定着してしまったのでもうこれでいいや的な…。ちなみに、Ama
GitHubで自動生成コードをDiffに表示しない方法 - Qiita
結論 ここに書いてある 注意事項 だいぶ懐かしい記事ですが…突然、「Diffに表示しないなんてGitHubの価値を損なうものだから記事を非公開にするべきだ」というご指摘をいただいたので、念のため追記。 Diffに表示しない、ってことは当然PRにも見えません。 レビューされない怪しいコードが紛れ込むリスクを抱えることになります。 せいぜい自動生成分だけを非表示にして、CIの中で再生成、差分が出ないチェックを入れるなど、ガードの手は考えておいたほうが良いでしょうね。はい。ご利用は計画的に。 背景 mockeryだったり、swagger-codegenだったり、go-bindataだったり… GitHub上に自動生成されたコードを載せている場合、PRやcommitの詳細画面でDiffが邪魔になることがあります。 .gitignoreでそもそも自動生成コードをリポジトリに載せない generate
エンジニア立ち居振舞い：自分のタスクよりメンバーのコードレビューを優先する - koogawa blog
お題「エンジニア立ち居振舞い」 ということで自分も書きます。 以前、Twitterにつぶやいたのですが 自分のタスクよりメンバーのコードレビューを優先するの、自分の作業は止まるけどトータルで見るとスピードが上がる、と信じたい— Og🌗エンジニア🏝宮崎 (@koogawa) 2016年7月25日 自分のタスクに着手する前に、チームメンバーのコードレビューをするように心掛けています。 コードレビューが滞ると、次のような悪影響があると思っています。 他のメンバーが次のタスクに着手できない プルリクエストが消化されないうちにもメインのブランチはどんどん進んでいるのでコンフリクトが起こる →コンフリクトを直す手間が増える 誰が何をしているか把握しにくくなる 当然、自分の作業は止まってしまいますが、それよりも上に書いた悪影響の方がまずいと思っていて、ここを解決することで全体的には開発スピードが上が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
あるgit commitがどのpull requestでmergeされているかをAPIでシュッと取ってくる方法 - その手の平は尻もつかめるさ
