Github っていう超ベンリスーパークールサービスがあるんですけど、このサービスを使うと VPS のセットアップがすごく楽。 皆いろんなマシンとか持ってて SSH 鍵もいくつも持ってると思うんだけど、このサービスを使えば VPS のセットアップの時にいちいちいろんな公開鍵を集めて SCP で配置するみたいな手間がなくなる。 具体的には $ wget https://github.com/[username].keys $ mv [username].keys .ssh/authorized_keys $ chmod 600 .ssh/authorized_keys すると良い。 Github に登録してある公開鍵は上記の URL で取れるので、例えば友達と共有サーバーを作るみたいなときにも役に立つ。 ギッハブマジ便利だなー
2013.01.31 ITニュース いまやプログラマーの「必須プラットフォーム」となりつつあるGitHub。サービス開始からわずか5年で全世界にユーザーを獲得してきた同社は、独自の経営理念によって「プログラマー天国」を築き上げていると評判だ。その根底にある考え方や、組織運営のこだわりとは何なのか? 来日中のGitHub経営陣に、編集長の伊藤健吾が話を聞いた。 GitHub COOのPJ Hyett氏(左)と、CIOのScott Chacon氏(右)。多忙なスケジュールの中で取材に応じてくれた 「これからの時代、プログラマーをやりたい人にとって、GitHubアカウントを持たなくて済むのは小学生までとなるでしょう」 弊誌対談「小飼弾×増井雄一郎が大激論! 開発者「大増殖時代」の到来で、プログラマーの存在意義はどう変わる?」で小飼氏がこう述べるほど、世界中のプログラマーに利用されるようになった開
GitHub や GHE を使って多人数で開発していると,プルリクエストを横断して試す必要が頻繁に発生すると思います. プルリクエストを次々に試したり,#30 と #31 をマージした結果を試したい!なんてケースもあるのではないでしょうか. GitHub では git ls-remote すれば分かるように,プルリクエストの番号と対応したブランチがリモートに存在しているので,これを取得してみます. .git/config に追記(あるいは git remote add とかで適当に) [remote "pr"] url = git@github.com:yourusername/yourrepos.git fetch = +refs/pull/*:refs/remotes/pr/* あるいはこんな感じ(丸投げ): https://gist.github.com/3342247 git fe
github で git diff from..to を表示する - #生存戦略 、それは - subtech で text/plain な diff が表示される。.. じゃなくて ... 。 http://subtech.g.hatena.ne.jp/secondlife/20121225/1356421602 github のコミットページ URL は、実は凄く良く出来ている。 例えば pull request のページ Add each Gem bundled data pointer in mrb_state by masuidrive - Pull Request #605 - mruby/mruby - GitHub Showing 17 changed files with 183 additions and 36 deletions . Show Diff Stats H
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに1個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
GitHub Flow Scott Chacon on the Interwebs 31 Aug 2011 git-flowの問題点 (Issues with git-flow) 私は人々にGitを教えるためにあちこちを飛び回っているが、最近のほぼすべてのクラスやワークショップでgit-flowについてどう思うかを尋ねられた。私はいつも、git-flowは素晴らしいと思うと答えている。何百万ものワークフローを持ったシステム(Git)を提供し、ドキュメントもあるし、よくテストされている。フレキシブルなワークフローは、実に容易なやり方で多くの開発者の役に立つ。標準的なものになりつつあり、開発者はプロジェクトや企業の間を移動しつつこの標準的なワークフローに馴染むことができる。 しかしながら、それ故の問題も抱えている。新しいフィーチャーブランチをmasterではなくdevelopから開始するとか、
コードレビューについて Oh, you `re no (fun _ → more) より引用 単に普段の開発で使っている VCS でそれを行なっていました。 つまり、コードの中にコメントの形でレビューを書き、それをコミットする。 そしてそこから派生する議論も全てコード上のコメントで行います。 (もちろん複雑な話になった場合は直接の議論を行い、合議の結果だけを記しておく、なども当然あるでしょう。) レビューをソースコードのコメントとして直接書き込むのは、GHC の開発でも時々見かけますね。例えば、新機能の開発 branch を作って、新しい機能を開発している時とか。 2012-08-14 18:44:19 via OpenTween まあ、主に入った変更に Simon Peyton Jones が(ソースコード上で直接)コメントしそれに従ってソースコードを修正する形なので、レビューと言えるほ
■ [github][irc] gig(github irc gateway)を使い始めた 数日前から net-irc に添付されている gig.rb を使い始めている。使い方は ruby gig.rb だけでだいたい動く。オレはサーバー上で常駐させたいので、gig.rb の deamonize な処理をコメントアウトしてから OS の daemontools で起動するようにしている。 これを limechat の showTwitterAvatar で見ると画像のようになる。github の follow とか watch ってダッシュボードで見ると何が起きているのかよくわからないし、たまに開いた時にたまたま目に入ったものを追いかける程度の用途しかないけど、gig.rb で表示するようになるとこの世界がだいぶ変わる。具体的には rails/rails のように注目しているプロジェクトで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く