Multiple issue and pull request templates
ProductMultiple issue and pull request templatesIssue and pull request templates help teams gather the right information from the beginning of a thread, but sometimes one template just isn't enough. Now project maintainers can have and… Issue and pull request templates help teams gather the right information from the beginning of a thread, but sometimes one template just isn’t enough. Now project
peco、ghq、gh-openの組み合わせが捗る - Webtech Walker
それぞれのツールは以下を見ればどんなのかわかると思う。 peco（Simplistic interactive filtering tool）を作った話 : D-7 ghq: リモートリポジトリのローカルクローンをシンプルに管理する - 詩と創作・思索のひろば (Poetry, Writing and Contemplation) GitHubのレポジトリURLを開くgh-openコマンド - unknownplace.org pecoとghqを組み合わせる例はpecoのREADMEにあるようにかなり強力で、ghqで管理しているリポジトリのディレクトリにcdしたりするのに便利。 こんな感じ。 $ cd $(ghq list -p | peco) また、typester先生作のgh-openは指定したディレクトリのリポジトリをGitHubで開けるので、同じように使えばpecoでGitHubの
GitHub の Issue リンクをリッチにする Chrome 拡張 - おなか周りの脂肪がやばい
どうもこんにちは、今日は便利な Chrome 拡張のご紹介です。 これは GitHub 上の issue link （#666 とかっていうやつ）を情報量の多い、見やすいバッジに変換してくれる拡張です。 親イシューにいくつかイシューをまとめて管理したいときに、イシューの状態（open/close や assignee ）が一目でわかってとても便利。 Chrome 拡張の permission の関係で GitHub 用と GitHub Enterprise 用の二つをご用意しております GitHub Issue Badges - Chrome ウェブストア permission が https://github.com のみ GitHub Issue Badges (for Enterprise) - Chrome ウェブストア permission が https://*/* になってい
ストレスフリーなGitHubのIssue生活 - クックパッド開発者ブログ
こんにちは。サービス開発部の丸山@h13i32maruです。 今日はGitHub/GHE(GitHub Enterprise)で快適なIssue生活をおくるために作ったJasperというツールと、それを実際にどうやって使っているかを紹介させていただきます。 ストレス GitHub/GHEを日々の業務の中心として使っていると、すごくたくさんのIssueやPull Request(以下PR)が流れてきます。 これらのIssueを処理する方法としては主に「メール」と「通知ページ(github.com/notifications)」の2つだと思います。 僕もこれらの方法を使っていたのですが、以下の点ですごく困っていました。 多すぎてメンションされたものやコメントしたものを見逃してしまう あとで見ようと思って、忘れる ブラウザのタブを大量に開いた状態になる 知らないところのIssueで議論が進んでい
Git（GitHub）の運用で気をつけていること - えいのうにっき
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
Protected branches and required status checks
ProductProtected branches and required status checksIt’s all too easy to force push to the wrong branch, overwriting someone else’s changes with your own. Sometimes it results in losing work (unless you know how to undo… It’s all too easy to force push to the wrong branch, overwriting someone else’s changes with your own. Sometimes it results in losing work (unless you know how to undo almost anyt
2015年3月に発生したGithubへのDoS攻撃についてまとめてみた - piyolog
Githubが同社サービスに対してDoS攻撃が行われていることを発表しました。一連のDoS攻撃はGreatfire.orgに対して行われているものと考えられ、ここではGreatFire.orgに関係するDoS攻撃の情報をまとめます。 公式発表 GreatFire.org 2015年3月19日 We are under attack 2015年3月25日 (PDF) Using Baidu 百度 to steer millions of computers to launch denial of service attacks Github 公式Blog 2015年3月28日 Large Scale DDoS Attack on github.com · GitHub Github 公式Twitter The attack has ramped up again, and we're evo
GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita
はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です！ 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは
より良いプルリクエストのための10のヒント | Yakst
GitHubなどの普及により、プルリクエストを使った開発フローは非常に一般的になった。一方でプルリクエストの品質も色々だ。オープンソースプロジェクトや業務でたくさんのプルリクエストをレビューするMark Seemann氏から、良いプルリクエストを作り、スムーズにマージしてもらうための10のヒント。 原文 10 tips for better Pull Requests by Mark Seemann 良いプルリクエストを作ることには、良いコードを書くこと以上を含んでいる。 プルリクエストモデルは、チームでソフトウェアを開発するための素晴らしい方法になりつつある。チームメンバーが分散している場合は特にそうで、オープンソースの開発だけでなく、企業においてもそれは同じことだ。2010年頃から私は、オープンソースプロジェクトにおいてだけでなく、クローズドソースのソフトウェア開発のために内部的にプル
GitHubでの”Merge pull request”の弊害 | POSTD
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
[Git][GitHub]GitHubにPushする際に認証失敗する
GitHub で2段階認証の設定をしてから push 時に認証が失敗するようになりました。 いつもどおり以下のコマンドを実行すると ID/PW を聞かれます。 git push origin master Username for 'https://github.com': Password for 'https://github.com': remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/wada811/AndroidLibrary-wada811.git/' [Git][GitHub]やっておくと地味に便利なこと2つ | DevAchieve で .netrc に ID/PW を書いているので 聞かれるのはおかしいなぁと思いながら ID/PW を入力しま
![[Git][GitHub]GitHubにPushする際に認証失敗する](https://cdn-ak-scissors.b.st-hatena.com/image/square/6802b243ff4fc1f265d8d3549bbc4e582f9ffba8/height=288;version=1;width=512/https%3A%2F%2Fblogger.googleusercontent.com%2Fimg%2Fb%2FR29vZ2xl%2FAVvXsEgKURvR2tjLKSWN82-BWVBLQaJ4XUnSXSL_pXRNOgF4YYe_XGktvCtsAdlQHOi7Lp8m97Kcos1Wum9NXqN6JDqc29-E0ioWnL31yLtYSb59L_q9lwSY8Ytvl1wzbt7A1MFd0Hm05jBWYkA%2Fw1200-h630-p-k-no-nu%2FOctcat.png)
PSD Viewing & Diffing
ProductPSD Viewing & DiffingWe've supported image viewing and diffing for quite some time now, but today we're happy to announce that we're adding PSD files to the images we support for this. Any… We’ve supported image viewing and diffing for quite some time now, but today we’re happy to announce that we’re adding PSD files to the images we support for this. Any PSD assets in your repositories wil
CEOが自ら語った「イノベーションを起こすためのGithubの哲学」 デザイン会社 ビートラックス: ブログ
人材の移動の激しいスタートアップ業界にいながらも殆どの従業員が辞めないことが話題となっている、ソーシャルコーディングサービスGithubのCEO、Tom Preston Werner氏が「イノベーションを起こすためのGithubの哲学」について先日のOpenCoSFというイベントで語った。 「イノベーションとは新しく何かをはじめることだ、たとえ他の人がそれをクレイジーだと思っていても」サンフランシスコはイノベーションを起こすには最高の場所だ。何か新しいことをすることはリスクだ。何が起こるかわからない。イノベーティブになるには勇気がいる。 他の人が「こんなもんクレイジーだ！」って言ったとしてもこれをやるぞという強い意思が必要だ。実際にスタートアップはとても高い確率で失敗する。でもサンフランシスコの文化ではたとえ失敗したとしてもまったく問題ないんだ。 実際にたくさんの起業家が失敗しているし、新
Github Issues を利用したリリースマネージャのお仕事 - hakobera's blog
最近、Quipper という会社で「リリースマネージャ」という名前のお仕事をしています。開発以外の仕事は久しぶりだったので大変でしたが、最終的にそれなり上手く行った方法を振り返りとしてブログに書いておくことにします。 経緯 自分のチームとは別のチームが開発しているサービスのリリースが迫っている中、それまで開発者の1人がリリース管理っぽいことをやっていたのですが、さすがに開発と管理の二足のわらじが辛くなってきたとのことで、急遽サポート的に自分が「リリースマネージャ」という役割りで参加することになりました。 コンセプト コンセプトは「使用するツールを増やさない」です。 管理のために新しいツールを増やすと、その使い方を教えるなど新たなタスクが発生してしまいます。タスクを減らすためにタスクが増えるなんてナンセンスです。 ということでQuipper では普段の開発に Github を利用しているので
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログチームの開発フローとGitHub
How GitHub Works (GitHub Kaigi, Tokyo, 2014)
GitHubで雑誌・書籍を作る
https://github.com/hail2u/github-cheat-sheet/blob/master/README.ja.md
github を用いた開発フローテンプレート