私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
今日はこのあと Github の Tokyo Drinkup January 2014 に行くのだが、先方から、もしかしたら 10分ほど Github について話してもらうかも、と打診された。話すか話さないかわからないが、もし話すとしたらと仮定し内容の整理も兼ねて以下「Github を使って雑誌原稿を書く」ということについて書いてみようと思う。 「Github を使って雑誌原稿を書く」もしくは「Github を使った雑誌編集者とのコラボレーション」について、である。 Web+DB PRESS の連載 ご存知の方もいるかもしれないが、このところ技術評論社の Web+DB PRESS で連載をしている。連載を始めて、もう一年近く経った。以前にも Perl に関する連載をしていて、そのときも数年ぐらい続けたので、間があきつつも、なんだかんだでそれぐらいの付き合いになる。 最近は特にテーマは決めず
というのを作ったました。ちょこちょこ機能改善してます。 yuroyoro/git-issue · GitHub git-issue | RubyGems.org | your community gem host 仕事では、異臭管理システムはRedmineを使っていて、作業はsshでサーバに入ってコード書いてるわけです。 で、次どのチケットやろうか、とか今やってるチケットの細かい仕様どうだっけ？みたいなときに、 いちいちブラウザに切り替えて目的のチケットを検索するのタルすぎて死ねる。 もうターミナルから離れたくないんだ俺は。 そこで、'git issue 1000'ってやると1000番のチケットを見ることができるようにした。 $ git issue 15 [open] #15 Issueをadd/updateするときに引数で全部渡すのタルい ------------------------
defunkt/hub - GitHub github用にhubというgitのラッパーコマンドがあることを会社で教えてもらって 使ってみたら、当然の如くzshの補完が効かなくてコマンドの使い方もよく分からなかったので、 コマンド理解とzsh補完関数の書き方の勉強も兼ねて自分で作ってみた。 最初はhubコマンドの補完関数を作ってたんですが、利用方法としてaliasを充てて gitの代わりに使うことが推奨されており、そもそもgitのラッパーで gitコマンドの補完も出来ないと意味が無いので、gitの補完関数自体に 手を入れて、hubのカスタムコマンドも利用出来るようにした。 検証環境は下記 Mac OSX 10.7.3, Scientific Linux 6.1 git version 1.7.7.5 hub version 1.8.2 zsh 4.3.11, 4.3.12 /usr/loca
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
GitHubにリポジトリを置いてる人はみんなプルリクエストを待っています。けどプルリクエスト用にフォークした自分のリポジトリを保守する方法が途中でわからなくなって...という人が案外多いんじゃないかなと思ったり。なので、ちょっとメモ置いときます。って、人のためみたいな言い方ですが、まあ自分用のメモです。 まずこうしたほうがいいという原則。masterブランチはフォーク元から変更せず、かならず自分用のブランチを作る。これは、masterを作業の同期用に置いておくためです。 自分のブランチでコミットしたあと、フォーク元のmasterが進んでないかのチェックは必ずすること。 もし進んでいたら自分のmasterに元作者のコミットを取り込んで自分のGitHubでのフォークが最新と同期してる状態にしましょう。で、元作者のコミットログを確認して何が起こったのかを理解しましょう。 $ git checko
GitHub がオープンソースの場として魅力的な理由は、Git という優れた分散・協調型リビジョン管理システムのリポジトリー・ザーバーとして誰でも利用できるということはもちろん、README などのドキュメント生成機能やコメンティング機能、問題のトラッキング機能など、Git を補助し、オープンな分散・協調開発を支えるサブシステムが充実している点が挙げられるでしょう。無料でもかなりのことができるのに、ビジネスとしてもちゃんと成立している理由はこんなところにあるように思います。 ただ、同種サービスの Google Code や Bitbucket と決定的に異なり、GitHub の最大の魅力となっているのは、GitHub Pages という1種のホスティング・サービスではないかと思います。成果物をただずらずらと味気ないページに並べるのではなく、趣向を凝らした紹介ページを自由に作り、プロジェクト
Webサーバに Subversion のサーバを立てておき、HTML や CSS を commit することでWebサイトを更新する方法は、良く知られているテクニック、らしいですね*1。更新の履歴を残すことができるし、ましてチマチマとFTPやsftpでアップロードするよりずっと簡単です。 しかし SVN の代わりに git を使おうとすると、pushしてもリポートリポジトリではファイルを更新してくれません。 また、リポジトリはWebサーバ上に作るよりも、便利な管理インタフェースがある github（や噂のgitosis）に置いておきたいところです。 そこで、github の Post-Receive Hook を使うと、リポジトリに変更を push すると同時に、Webサーバにも同期させることができます*2。 Webサーバに同期する前に、Sphinxでドキュメントを整形したり、SassをC
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
昨年末から仕事で使い始めて以来、すっかりGitHubがお気に入りになってしまった。 GitHubが素敵なのは、今でも日々進化を続けているというところだ。例えば、先日実装されたcommit閲覧における画像ビューの機能拡張なども、なんだかすごいことになっている。 Behold: Image view modes - GitHub Blog 新しい画像ビューでは、コミットによる更新内容を４つのモードで確認できるようになっている。例えば"Swipe"モードでは、画像の上をドラッグすることで２つの画像をめくるように見ることができる。 “Difference"モードでは、２つの画像における差分を視覚化して表示する。これは変更の度合いが小さい場合にとても便利な機能だ。 実際にデモを触ってみると、機能の内容がよく分かると思う。 個人的には、これらの機能はデザイナーさんと連携をするにあたって、とてもありがた
思うところがあって${HOME}/.vimを整理したりその他環境をキレイにしていて試したらうまくいったtipsです。 vimでRailsアプリの開発をしている人はほぼ間違いなく tpope先生のお世話になってることと思います。rails.vimの作者の方ですね。 rails.vimはvim.orgから落とせるから手で入れるなりGLVSで入れるなりすればいいんですが、先生はほかにもvim-cucumberとかvim-hamlとか使わずにはいられないプラグインも作ってらして、しかしそれらはvim.orgにはまだ来ていない、と。それをいい感じに追いかけて管理する方法を思いついたので書いてみます。 前提として、~/.vimがGitリポジトリである必要があります。上位ディレクトリ、たとえば~/の場合は出来なそうなので、分割するといいと思います。私は今回の件で~/.*全般から~/.vim(と~/.zs
2009-09-29追記 ssh-keyの追加に関する記述が誤っていたのを修正 2009-10-01追記 多環境間のリポジトリのマージについて追記 最近趣味開発で、Eclipce上からgithubとGAE/Jを使って開発する環境を作りました。 こいつが実に素敵滅法なので簡単にまとめたいと思います。 いろいろスッ飛ばしていますがご了承下さい・・・ GAE/Jって何さ EclipseでJava版App Engineを始めるための基礎知識 (1/4)：Google App Engineで手軽に試すJavaクラウド（1） - ＠IT Google App Engineという、Googleが提供するレンタルサーバーみたいなものです。 （レンタルサーバーほど自由度はありませんが簡単で、レンタルサーブレットコンテナといった感じです） インターネット上でJavaアプリケーションをデプロイして、簡単にWeb
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
