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.
Last updated June 30, 2026 Heroku integrates with GitHub to make it easy to deploy code living on GitHub to apps running on Heroku. When GitHub integration is configured for a Heroku app, Heroku can automatically build and release (if the build is successful) pushes to the specified GitHub repo. If you’re a Heroku Enterprise and GitHub Enterprise Server customer, you can also try the Heroku GitHub
最近は Gradle がとってもお気に入りなので プラグインの開発も少しずつ行っているのですが、 折角作成したプラグインやライブラリも Maven リポジトリで公開しないと利用しづらいので どこか公開できる場所がないか探していたところ Github を Maven 公開リポジトリにする という記事を見つけたので ソース管理と合わせて GitHub に Maven リポジトリを作成することにしました。 ただ無料版だと300MB しか利用できないので容量がちょっと心配だったのですが id:kimukou_26 さんのアドバイスによりあまり容量を気にする必要はないことがわかったので GitHub にしました。 それによく考えてみれば そもそも 300MB もコードが書けるほど時間に余裕はないですし... 上記の記事では Maven が使われていましたが、今回は Gradle を利用することもあり
# GitBook Setup Agent ## Task Take my docs and turn them into a live, published GitBook site. Go end-to-end — don't stop until it's live or you hit a step only I can do. ## Tooling You have two ways to work with GitBook. Check what's available and pick accordingly: 1. **GitBook MCP server** (preferred if already connected) — check your available tools for `gitbook-mcp`. If it's connected, use it.
皆さんお元気ですか?LINEサーバー開発室でサーバ開発を担当している崔珉秀と申します。 この記事ではLINEのサーバーの開発とリリースプロセスについて述べたいと思います。 LINEの開発者はどんな形で開発しているのか、サービスに変更事項をどのように適用しているのか、お互い協力してより良い開発環境を得るためにどんな努力をしているのかをお伝えする機会になったらいいなと思います。 ここで述べるリリースプロセスは、LINEのサーバ開発の流れとソース管理システムの運用方法、そして本番環境に変更事項を適用するまでの過程です。 LINEのServer Applicationはその役割とシステムの構成によって複数のServer Applicationに分かれて構成されています。 例えばNetwork通信及びProtocolなどを担当するApplication、messagingやsocial graph
「プライベートリポジトリ無料のCIサービス「Magnum CI」を使ってみた」の通り、Magnum CIはビルドログがネットに公開されちゃうので断念しました。 次に無料でGithubのプライベートリポジトリを使えるCIサービスとして、「Shippable」を試します。 ※他のCIサービスをお探しの方はこちらをどうぞ→「CI(継続的インテグレーション)サービスまとめ・14個!」 ShippableはGithubしか使えませんが、プライベートリポジトリも使えます。ただし、プライベートリポジトリは1つだけしか使えません。 まだ有償プランはありませんが、「FREE PLAN : Unlimited builds for all open source and one private project!! 」と書かれているので、おそらく1つだけはずっと無料でプライベートリポジトリを使えると思います。(
CI(継続的インテグレーション)サービスまとめ・14個!では、BitBucketで使えるCIサービスを探していましたが、時が経てば事情は変わり、Githubのプライベートリポジトリで無料で使えるのが必要になったので、前に紹介した「Magnum CI」を試しました。 Magnum CIはプライベートリポジトリがいくつでもなぜか完全無料。Betaとも書いてないけど、アカウント設定にフリープランと記載があるので、将来的に有償プランをやる気はあるようです。 なお、今回はGithubのプライベートリポジトリを使いますが、Magnum CIはBitBucketでも使えます。それだけじゃなく、GitLab、Beanstalk(知らない。AWSのではないらしい)、 自分で立てたgit, mercurial, subversionでも使えます。 今回対象とするプロジェクトはRailsアプリなんですが、以下の
はじめに 相変わらずブログ環境に悩んでいます。 前にも書きましたけど、私もブログを新しく作るにあたって流行りに乗ってMiddleman+Github Pagesでやろうかなあと思ったんです。 でも、めんどくさいんですよ。 エディタで書いて、git add、git commit、git push、Travis CIでビルドを自動化、middleman-deployとかもあるけど。。。いや、俺ブログにこんなに手を掛けたくない。。。ていうかブログ書くのに黒い画面使いたくない。 APIドキュメントとか会社サイトなら更新多いしGitで管理するのもいいけど、ブログはね。あんま編集しないし。 そういう人は静的サイトジェネレータ使うなとか言われそうですけど、 コンテンツが完全に自分のものになる(いつでも好きなところに引っ越せる) デザインは黒い画面でできて、どんなCSSもJavaScriptも書ける って
Manual or automatic deployments. Trigger a deployment whenever you’re ready or deploy on every push to a branch. Tools for multiple environments. Each deployment environment (like Production and Staging) can ship code from different branches to one or many servers simultaneously.
Discourse 今時のクールな掲示板を作れるRails製OSSディスカッションボード「Discourse」。 ユーザインタフェースが今時の物になっており、Likeボタンやお気に入り、Ajaxによる次ページ読込機能等、使いやすく、必要な物が揃ってる感じです。 社内のディスカッションボードなんかに使ってみるとよさそうです。 GitHubでソースコードが入手出来ます 関連エントリ コーディングもブラウザ上でできるオープンソースソフトウェア「Codiad」 オープンソースのHTML5お絵かきウィジェット「Literally Canvas」 Excelそっくりな表計算モジュールを実装可能なオープンソースモジュール「Gelsheet」
2013.01.31 ITニュース いまやプログラマーの「必須プラットフォーム」となりつつあるGitHub。サービス開始からわずか5年で全世界にユーザーを獲得してきた同社は、独自の経営理念によって「プログラマー天国」を築き上げていると評判だ。その根底にある考え方や、組織運営のこだわりとは何なのか? 来日中のGitHub経営陣に、編集長の伊藤健吾が話を聞いた。 GitHub COOのPJ Hyett氏(左)と、CIOのScott Chacon氏(右)。多忙なスケジュールの中で取材に応じてくれた 「これからの時代、プログラマーをやりたい人にとって、GitHubアカウントを持たなくて済むのは小学生までとなるでしょう」 弊誌対談「小飼弾×増井雄一郎が大激論! 開発者「大増殖時代」の到来で、プログラマーの存在意義はどう変わる?」で小飼氏がこう述べるほど、世界中のプログラマーに利用されるようになった開
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに1個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く