github:pagesはもう使っているか？ - Meltdown Countdown rev.
えんじにあ〜たるもの、自分が何をしているのか何をできるのか発信するのは大切なことです。 最後のRubyKaigiに参加し、いろいろなお話を聞いたのですが発表者の皆様の共通しているマインドとして「勉強しよう！発信しよう！」みたいなものを感じました。それからもちろん、楽しむことも大切ですね。 となると、Githubのアカウントは持っているべき。書いたコードを公開しよう。それが自己紹介の代わりともなっていくことでしょう。 それから、ネット上での各種活動もまとめておきたいですよね。そういったツールはすでに色々ありますが、もう少し技術寄りなまとめ静的ページを持っていてもいいかもしれません。かねてからSinatraでつくってherokuに置こうかなと思っていたのですが、もっと簡単な方法があります。それが、Github Pages なんですよ。 Github Pages marutanm/marutan
K8 カジノ - 「K8 カジノ」で勝利の興奮を味わおう！最高のゲームと魅力的なボーナスが待っています。リアルなカジノ体験を楽しんで、夢の一獲千金を目指そう！
The Best Fluffy Pancakes recipe you will fall in love with. Full of tips and tricks to help you make the best pancakes.
ぼくのかんがえたさいきょうのGit Repository Browser - ( ꒪⌓꒪) ゆるよろ日記
こんなヤツ デモサイトはこちら http://gitterb.yuroyoro.net/ Gitである程度運用してると、ブランチがいっぱいになっていつどこから生えたのかわからなくなったり、どのブランチがマージされてるか把握できなかったりとかがあると思う。 たとえばgit log --graph とかgit merge-baseとかコマンドで頑張ればいいんだけど、俺はあまり頭良くないし記憶力もないので、コミットのつながりをグラフィカルに表示してほしいと常々思っていたわけ。 たとえばGitXとかgitkとかGit Towerとかのツリー表示って、こんな感じじゃないですか。 これはこれでまぁいいんだけど、この程度ならlog --graphやtigを使えばいいのでわざわざGUI起動するまでもないし、そもそもあんまりグラフィカルじゃない。見たいのは、Pro Gitとかにあるようなコミットを○と矢印で
今こそ！git の branch を vim のステータスラインに表示！！するとき！！！ - Meltdown Countdown rev.
当然、ターミナルのプロンプトには表示させてますよね？zshならvcs_infoとか使えばいいですし。では、Vimはどうですか？各種git操作はVimからしないって？甘い、甘い。 git の branch を vim のステータスラインに表示 - #生存戦略 、それは - subtech 2008年3月のエントリですが、大変そうですね。でも今なら簡単です！fugitive を使えばいいんです！！ ギットギトなVimmerにはすっかりお馴染みかもしれないfugitiveです。それ自体は VimmerなGit使いはfugitive.vimを今すぐ入れたほうがいい - SELECT * FROM life; や Vim-users.jp - Hack #219: Gitを使う2 – Fugitive.vim あたりが詳しいです。 :Gstatusからのstage/unstageが便利すぎますね！
GitHub、プログラミング言語識別ライブラリ「Linguist」をオープンソースで公開 | OSDN Magazine
GitHubは6月27日、ファイル内に記述されているプログラム言語を識別するライブラリ「Linguist 1.0」を公開した。ライセンスはMIT License。 Linguistは、ファイルで使われているプログラム言語を識別する目的でGitHubが開発したライブラリ。ファイルの拡張子で言語を判別するだけでなく、拡張子のないスクリプトファイルや、C/C++/Objective-Cのような互換性を持つ言語については中身を調べる「ディープコンテンツインスペクション」により言語を検出する。これによって言語を検出し、Pythonシンタックスハイライター「Pygments」向けのRubyラッパー技術「Albino」によりシンタックスハイライト処理を行わせる、といった処理が可能。 このほか、MIMEタイプ検出、バイナリファイルのチェック、使われている言語のグラフ生成などの機能もある。ライセンスはMIT
デザイナーが RailsとGitのことを少し知ってると色々捗る
The document contains a series of dates from 2011-6-22 repeated many times. Between some of the dates are short phrases such as "Don't Repeat Yourself" and "Convention over Configuration". The overall document does not appear to have a clear purpose and consists primarily of a date repeated with occasional unrelated text fragments.Read less
Google Sites: Sign-in
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
gitやcurlやwgetでGitHubにアクセスするとcertification errorになる原因を調べてみた - このブログはURLが変更になりました
中の人に裏を取ったわけではなく私の推測です。間違っているかもしれません。 2010年11月から2011年5月末までの状況(gitやwgetでcertification error) 2010年11月頃、GitHubではすべてのアクセスにSSLを使うよう仕様が変わった。 この時、SSL証明書にはワイルドカード証明書(*.github.com)が使われていた。 *.github.comのワイルドカード証明書にgithub.comは含まれないのだが、SSL証明書にはX509v3 Subject Alternative Name(subjectAltName)が設定されている*1ため、subjectAltNameに対応したクライアントであれば問題ない。 しかし、wgetの最新版1.12はsubjectAltNameに未対応*2。wgetではcertification errorが出ていた。 参考
さくらVPS設定その3 Git+Ruby+Gem+Rails+Passenger - ✘╹◡╹✘
さくらVPS設定まとめ の子エントリになります。 目次 Git Ruby Gem Rails - RubyやRailsをバリバリ動かしたいので、それ関係のものを入れていきますよ。 Git バージョン管理には基本的にGitを使っています。バージョン管理に使わない場合でも、ライブラリ等がGitで公開されていることは多いので入れておくに越したことはありません。yum標準のレポジトリにgitが含まれていないようなので、仕方無くレポジトリを追加します。私自身yumを使い始めてまだ間もないので、デフォルトの状態での理解が深まる前に追加でレポジトリを入れてしまうのはあまり好ましくないのですが、ソースから入れるのも同じくらい怖いのでレポジトリを追加します。 # `uname -i`でx86_64が出力されます $ rpm -ivh http://repo.webtatic.com/yum/centos/5
それ etckeeper でできるよ - /etc 以下を Git で自動的にバージョン管理 - おいちゃんと呼ばれています
こんにちはこんにちは。一昨日、さくら VPS に Git をインストールするエントリーを書きましたが、実はバージョン管理は etckeeper にもお世話になっています。 etckeeper というのは、Git 等のバージョン管理ツールを用いて、/etc 以下をほぼ自動的に管理してくれる有り難いツールです。下記のタイミングで自動的にコミットしてくれます。手動で任意のタイミングでコミットすることもできます。 -yum コマンド実行の前後 -日付が新しくなったとき << 以下、さくら VPS（CentOS 5.5 -64bit）で etckeeper を使えるようになるまでの手順をまとめてみましたので、よろしければ参考にしてください。 *目次 Git のインストール etckeeper のダウンロード etckeeper の設定ファイルの編集 etckeeper のインストール etckeep
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
.gitconfigに設定してるaliasなどのまとめ - ( ꒪⌓꒪) ゆるよろ日記
22:56 @thinca さんからの指摘を追記 @yuroyoro あとお節介ですが、n個前とdiffなら HEAD^ より HEAD~ の方がいいと思いますよ。両者では若干意味が違います。~なら HEAD~3 と数字が書けるのも利点です。あと個人的にはwhatchangedよりlog --statの方が見やすくて好きです。 2010-10-08 22:30:52 via Tween to @yuroyoro @yuroyoro URL このgitconfigの記事に関して質問なのですが、core.excludesfile は $HOME で動きますか?以前試した時ダメで、~/ なら動いたのでこちらを使ってるんですが。 2010-10-08 22:20:49 via Tween to @yuroyoro 「そんな.gitconfigで大丈夫か?」 そんなわけで、仕事でもモリンモリンにgi
Repo と Git の使い方 (Using Repo and Git)
Android コードで作業するには, Git と Repo の両方を使う必要が出てくるでしょう。 Git は, 複数のリポジトリに分散した非常に大きなプロジェクト群を扱うために設計された, オープンソースのバージョン管理システムです. Android では, ローカルでのブランチ作成, コミット, 編集等のローカル操作で Git を使用します. Repo は Git 上に構築したツールです. Repo により, 多くの Git リポジトリ群の管理が容易になり, 私たちのリビジョン管理システムへアップロードが行え, Android 開発の作業手順が自動化できます. Repo は Git を置き換えることを意図したものではなく, Android 開発において, Git での作業をより容易にするためのものです. repo コマンドは, 実行可能 Python スクリプトで, 検索パスのどこにで
android gerrit / repoのハマりどころ - ものがたり(旧)
たかだかパッチを投げるだけなのに何でこんなハマるのか…ともあれ、id:atsushieno:20100305:p1のパッチは無事投げることが出来た。以下僕がハマったgerritとrepoの問題をまとめて置こうと思う。これとは別にgitとssh鍵の基本的な理解が必要になるので、分からない場合はsource.android.comの基本的な説明を読むと良いと思う。 androidのソースをチェックアウトするときにrepo initすると思うけど、この時にメールアドレスを訊かれる。単にチェックアウトしてビルドするだけなら何でも良いのだけど、パッチをcommitしてreviewに投げるとなると、そのアドレスが後でgerritで使われることになる。まずこのことに注意。 gerritに登録できるユーザ名にはアルファベット、数字、_ - など限られているのだけど、これは後でメールアドレスの@の左側と一致
Gitリポジトリにあるコードを追う / コードレビュー - Masatomo Nakano Blog
これまではcommitされたコードを、commit(push時)メールでなんとなく見ていたが、取りこぼしも多いし、忙しいと、つい見なくなってしまうので、なんかいい方法はないかなとここ数カ月くらいぼんやり考えていた。で、簡単なスクリプトでできそうと気づいたのでメモ。Githubに置いてあるようなオープンソースなコードとかも追いやすいんじゃないかなー。 ちなみに、このスクリプトを書く前に、コードレビューシステム的なのを導入しようかとGerritとか、Review Boardを少し試してはみた。でも、うちで使うにはちょっと大げさ過ぎるので、導入してもツールに踊らされる or 使わなくなる、という感じがしたので、とりあえずやめた。 いまいち気に入らない点としては、Gerritとかは完全にcommit単位でのレビューなんで、ちょっとしたパッチレベルならいいのだが、がりがり書いていく中ではちょっと現実
【翻訳】Gitをボトムアップから理解する
John Wiegleyさんの "Git from the bottom up" を翻訳しました。 元PDFはこちらからダウンロードできます： http://newartisans.com/2008/04/git-from-the-bottom-up/ 元記事のライセンスがクリエイティブコモンズのBY-SAであったため、この翻訳もBY-SAとなります。 ライセンスを守って自由にご利用ください。（詳しくは記事内の最初にも書いてあります） 翻訳ミスの指摘や改善の提案等があればブログコメントやTwitter(@oshow)などで遠慮なくどうぞ。 Git をボトムアップから理解する Wed, 2 Dec 2009 by John Wiegley 私が Git を理解しようと調査した時、高級なコマンドの視点から眺めるよりボトムアップ式に理解することが役立った。そしてボトムアップ視点で見る Git が
Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineering
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います： ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub for Windows
github/gitignore at master - GitHub
GitHub - bleis-tift/Git-Hooks at rewrite
