Sorry. This site has been closed. Please use the Search for commit messages on GitHub instead. The original source code is available at minamijoyo/commit-m.
シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン(規律)の存在」や「General Electric(GE)やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/
経緯 個人的にgit commit -m " うっ、英語でなんて書けばよいんだろう。。。。ってなることが多くて、GitHubの公式の検索ってソースコードは検索できても、コミットメッセージをリポジトリ横断的に検索したいなんてことはできないんですよねぇ。まぁネイティブな人にはそんなこと思いもしないのかも知んないですが。調べてみたらGitHub APIでコミットメッセージ取れるようなので、現場のリアルな生の文例を集めて検索できるようにすればよくね?ということで勉強がてら作ってみたので、需要あるか分からないけど同じこと思ってた人のために晒す。 作ったもの http://commit-m.minamijoyo.com/ 使い方 テキストボックスにキーワード「fix bug」などを入力してSearchボタン押すと検索結果が表示される。以上。 機能の補足説明 キーワードはスペース区切りでAND検索になる
At GitHub, we use Elasticsearch as the main technology backing our search services. In order to administer our clusters, we use ChatOps via Hubot. As of 2017, those commands were a collection of Bash and Ruby-based scripts. Since the beta release of GitHub Actions last October, thousands of users have added workflow files to their repositories. But until now, those files only work with the tools G
GitHub の Deployments API を使うと Web アプリケーションのリリース (デプロイ) に関わるワークフローをより便利にできそうだったので、試したことを記録する。 Deployments API でできること Deployments | GitHub API すべてドキュメントに書いてあるが、かいつまむと: 「デプロイ」を表現するイベントを作ることができる 進捗 (e.g. 成功、実行中, etc.) を表現できる (「デプロイ」を表現するイベントに紐付くメタデータ (e.g. 説明、payload) を作ることができる) ……という具合である。 つまり GitHub の API は具体的なデプロイのタスクについて責務を負うことはなく、「デプロイ」というイベントをリポジトリにアーカイブしそれらを通知する責務のみを負う、ということになる。Webhook のひとつと言い換
技術部 id:sora_h です。今回は v2 より AWS 上での運用に対応した GitHub Enterprise を、オフィスにある既存の環境から AWS へスムーズに移行した話について説明します。 GitHub Enterprise v2 GitHub Enterprise (以下 GHE) とは、github.com を自前の環境で運用できるアプライアンスです。クックパッドでは主に GHE 上で開発を行っています。 従来まで GHE の実行環境として VMware vSphere, VirtualBox 上の実行しかサポートされていませんでしたが、11 月にリリースされたアップデート v2 より、AWS での実行がサポートされました。 クックパッドでは全面的に AWS を利用していますが、いままで GHE を AWS 上で動作させる事はできませんでした。そのため、オフィス内に E
コマンドラインからgithubを検索してgit cloneをする with ghs, peco and ghqGoGitGitHubPecoGhq ghqとpecoを組み合わせてGithubリポジトリを簡単に取得するために、Githubリポジトリをコマンドラインから検索するghsコマンドを作りました。 sonatard/ghs トライアルページ ghs - CodePicnic 更新履歴 2017/04/15 0.0.10リリース 依存ライブラリのgo-githubの下位互換性がなくなったため、ビルドできなくなっていたバグを修正しました 2016/05/14 0.0.9リリース -k, --forkオプションを追加しました 検索結果にforkしたリポジトリを含める(true)、含めない(false),forkしたリポジトリだけ表示(only)を指定することができます。 検索結果が0件だった
これです。 ちゃんと社労士チェックを入れて、2014年時点の法運用Validな感じにしてあるので、下手な中小企業はおろか、ろくにメンテされていない大企業の就業規則よりマトモな内容になっているはずです。 なんで就業規則を公開したのか マトモな規則が作ってあれば公開しても特にデメリットはない むしろマトモな会社アピールができてよい 個人的には「無限RedBullです!!!!」みたいな事をアピールする会社よりマトモな広報・求人活動の一環だと思っている 自分で就業規則を作ろうにも、良いサンプルがなかった(後述あり) いわゆるOSS的な話。就業規則にも再利用性が合っても良いはず これを書いてて、就業規則にライセンスを明示するのを忘れていたことに気が付いた GitHubだと、就業規則の改定にプルリクを飛ばせて楽しいし、改定履歴も一目瞭然 零細企業に就業規則って要らないんじゃないの? 従業員が10人未満
HerokuとGithubを使った統一的なツール配布 Go言語ではクロスコンパイルがとても簡単で,複数プラットフォーム向けのバイナリをつくってそれを配布するというのがさらっとできる. 単純にやるなら, クロスコンパイルした各バイナリをzip等に固める Github Releaseやbintray,Dorone.ioなどにホストする そして,ユーザには自分のプラットフォームに合ったものをダウンロード/展開してPATHの通ったところに置いてもらう. 開発者からすると,すごい簡単.ホストするまで完全に自動化できる.でも,ユーザからすると若干めんどくさい. もっとツールを使い初めてもらうまでの敷居を下げたい. TL;DR 全プラットフォーム共通で以下のようにツールをインストールできるようにする.若干長いが1コマンド! $ L=/usr/local/bin/ghr && curl -sL -A "`
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション (寄与貢献)を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
人間とウェブの未来(旧) 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 Docker Hub公開のアナウンスがあったので、早速Docker HubとGitHubを連携させてmod_mrubyの実行環境をDockerイメージとして作った上で、それをMac上のVagrantで動くCoreOS内のDocker環境にデプロイしてみました。 本エントリではmod_mrubyとしていますがここは重要ではなく、自身が開発しているGitHubのアプリケーションに置き換えて読んで頂けると、便利さが見えてくるかと思います。 試してみると、非常に簡単にDockerイメージを作成できた上に、迅速にmod_mrubyの軽量な実行環境をデプロイできたので、その流れを簡単に紹介したいと思います。 Docker Hubにアカウントを作ってGit
AI is radically changing the way that we build software. Yet the way we manage software projects still looks a lot like it did twenty years ago. Engineering teams are still spending hours manually updating project management tools, leading to messy, inaccurate project data. This leaves engineering leaders without a clear view of progress, making it difficult to know whether projects will be deli
問題 プルリクエストのレビュー、動作確認をするためにローカルでcheckoutしたいが、ブランチ名を調べて入力するのが面倒くさい。別名をつけてcheckoutできるようにする方法があるが、プルリクエストの番号を調べる必要があってそれも面倒。 もっと簡単にcheckoutしたい!!! 解決策 プルリクエストの一覧からブランチを選択してcheckoutできるようにしました。 1. プルリクエスト一覧を取得する まずプルリクエスト一覧を取得します。そのためにprfetchというスクリプトを書きました。 手っ取り早く下記でインストールできます。 wget https://raw.githubusercontent.com/yuku-t/dotfiles/master/bin/prfetch chmod +x prfetch mv prfetch ~/bin # ~/bin はPATHに入っていると
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く