Web・ITのブログ記事

スクリーンショット

サイジーサーチ-勉強会等イベント情報一括検索(ATND,connpass,etc.)


新しいコンテンツを公開しました。


最近はTwitter絡みのものが多かったですが、今回はまったく関係ありません。
お楽しみツールではなく、お役立ちツールです(役立つかな?)。


今回公開したのはサイジーサーチ-勉強会等イベント情報一括検索(ATND,connpass,etc.)


勉強会やセミナーの情報が集まったイベントサイトがたくさんありますが、それらを横断検索できるコンテンツです。


対応しているのはATNDeventATNDconnpassPARTAKEZusaarDoorkeeperの6サイトとなります。
年月指定での検索も可能です。


地域検索は検索ワードに地域名(東京、大阪等)を入れることで代替としてください。
簡易表示を選ぶことで日付が強調されますのでカレンダー的な見方ができます。


使い勝手が良いように少しずつバージョンアップしていきたいなと思っていますので、もしリクエスト等あればTwitterのリプライででもご連絡ください。
応えられるかは別としまして。


私自身がIT・プログラミング系の勉強会情報を調べるために作りました。
他にも同様の種類のサイトはたくさんあるんですが、自分好みのものがなかったので。


皆様の役に立つと嬉しいです。

キャプチャー

噂生成レシピ生成に続きまして、またまたTwitter診断コンテンツを作ってみました。

タイトルはTwitter つぶやきしりとり力測定-語彙力診断的ななにか-です。


ユーザー名を入れるとつぶやきから言葉を抜き出し、その言葉のみで行ったしりとりの結果を表示します。
このしりとりが長く続けば続くほど高いしりとり力が弾き出されるという仕組みです。
ネタです。


今回もYahoo!の日本語形態素解析APIを使わせてもらっています。
また返ってきた値をいじってはいますが。


Twitter診断系ばかり作っているなあという感じですが、まあ、好きなおかずばかり毎日食べたがるこどもみたいなものだと思って生温かい目で見守ってください。


Twitterアカウントをお持ちの方はぜひ遊んでみてくださいませ。

キャプチャー

先日のつぶやき噂生成に続きまして、またTwitter診断コンテンツを作ってみました。

タイトルはTwitter つぶやきレシピ生成-あなたがよくつぶやいている言葉たち-です。


噂生成と違って、遊び心的なものはほぼありません。
ただ、これまでTwitter診断絡みの中で最も解析をしているな〜という感じのコンテンツ(これまでに比べれば、ですからね)。


要はつぶやきを解析してよくつぶやかれている言葉を箇条書きで表示するというコンテンツ。
それを「何回」じゃなくて「何g(グラム)」で表記しているので、レシピ生成。


Yahoo!の日本語形態素解析APIを使わせてもらっています。
ただ、返ってきた結果をかなりいじくりまくっています。


この解析をつぶやき噂生成にも活かしています。
どちらも言葉を抽出するという点では兄弟・姉妹コンテンツみたいなものですので。


説明はともかく、Twitterアカウントをお持ちの方はぜひ使ってみてくださいませ。

スクリーンショット
4月10日に公開しましたTwitter つぶやき噂生成-あなたのことをうわさしちゃいます-、たくさんの方に遊んでいただきました。
今もたくさんの方に遊んでいただいています。
ハッシュタグクラウドというハッシュタグランキングサイトの集計によりますと、公開1週間で本コンテンツのハッシュタグである#あなたの噂が30000回以上つぶやかれたそうです。
テレビ番組でも仲間探しでもなんでもない、とある一つのWebコンテンツのハッシュタグがここまで流れるのはそこそこ珍しいのではないかと思います。
↓は公開約一週間時点のハッシュタグクラウドのスクリーンショットです。
スクリーンショット
びっくりなことに公開10日後の4月20日にはTwitterのトレンド(日本)に載ってしまいました。
Twitter史に名を刻んだ気分ですね(大げさ)。
スクリーンショット
遊んでいただき心より感謝申し上げます。
正直ここまで遊んでもらえたのはかなりびっくりな結果でした。胸の高鳴りが一年分ぐらいまとめて押し寄せた感じです。
これまでに作った診断系(つぶやき時間帯分析つぶやきエンゲル係数診断つぶやき日本語力診断)よりも楽しさを重視したコンテンツにするという意識を持って作りましたが、それでもまさかここまでとは……嬉しい誤算です。
公開から数日は本当にばたばたしました。
ということで、せっかくなので、ばたばたしないために私がどんな準備をしてしかし結局ばたばたしてどういう対応をとったのか、それを時系列でまとめてみました。
Twitter関連でWebサービスを公開する人のためのノウハウ集!
と声高らかに宣言できればいいんですが、実際にはどたばたのすべてが私の準備、経験、知識の不足に帰結するという……恥ずかしさ満載!
まあ、同じ過ちを犯さずに済むようにという自戒も込めての公開です。
なにか疑問等あればTwitterの私のアカウントにお尋ねください。疑問無くても気軽に絡んでやってください。
ちなみに私の専門はFlashです。噂生成ではまったく使っていないですが。

コンテンツ概要

Twitterのアカウント名を入れるとつぶやきを引っ張ってきてキーフレーズ抽出してそれを文章に当てはめて表示、といういわゆる診断系?のコンテンツです。
ハッシュタグは#あなたの噂
処理は大まかに書くと下記の流れ。
  • クライアント側でTwitterのアカウント名を入力してサーバに送信。
  • サーバ側でそのアカウント名を元にTwitterのAPIを呼び、つぶやきを取得。
  • つぶやきをちょい加工してYahooのAPIを呼ぶ。
  • 返ってきたキーフレーズを元に生成した噂をクライアント側に返す。
  • 受け取った噂を表示する。
ユーザーの認証は求めません。
ユーザー認証有りにすればとれるつぶやきの数が増える等メリットはあるのですが、遊ぶ上でのハードルは下げたかったので。
「こんな怪しげなサイト、認証してまで遊ばない!」
と思う人、かなりいるでしょうし。

使用言語等

クライアント側の言語はHTML5、CSS、JavaScript(というかjQuery)です。
あとCSS FrameworkとしてBootstrapを使っています(デザイン能力が乏しい開発者の強い味方!)。
サーバ側はPHPとMySQLです。
OAuthやキャッシュの絡みでいくつかライブラリ使いました。
キーフレーズの抽出にはYahoo Developerのキーフレーズ抽出APIを使わせてもらっています。
Yahoo Developerが提供するAPIは種類が多い上にアクセス制限ゆるめなのでかなりお薦めです。

公開前

企画〜開発の段階で考えたことや取り組んだことは以下の通りです。
楽しめるコンテンツであること
使った人が楽しめるようにしたいと強く思いながら作りました。
これまで作った診断系は分析してそれをそのまま表示するだけで、楽しいという要素が薄かったので、私の中での新境地開拓的な気持ちで。
噂の内容の詳しい説明は遊ぶとき興醒めでしょうからやめておきます。
TwitterやYahoo!のAPI制限エラー対策
開発者の方々の多くはご存知でしょうが、TwitterにもYahooにもAPIの使用回数制限があります。
つぶやきの取得、TwitterアイコンURLの取得、つぶやきからのキーフレーズの取得それぞれ回数の上限があります。
ちなみに現在、Twitterのsearch APIは180回/15分、Yahooのキーフレーズ抽出APIは50000回/1日。
毎回毎回生成の度にAPIにアクセスしていたら、Yahooの方はともかく、Twitterの方はあっという間にこの回数制限に引っかかってしまいます。
ですので、一回噂生成のために必要なデータを取得したら、それは一定期間DBに保存するようにしました。
ユーザー名を入れる

そのユーザー名で過去の一定期間内に利用がなければAPI通信、利用があれば取得済みのデータを使う
という流れです(本当はもうちょっとだけやっていることありますが、ざっと説明すると)。
先頭に@が入っていても結果を出す
Twitterユーザの性質なのでしょうが、アカウント名の入力で頭に@を入れる人がけっこう多い(これまでの診断系コンテンツの運営で気づいたこと)。
ですので、@が先頭に入っていてもそれを無視するようにしました。
他にもRTのつぶやきは生成からはずすとか、細かい処理は色々と挟んでいます。
適切な表示情報量
最初は一回の生成で一個の噂を表示するように作っていました。
ただ、意味が通る噂と意味が通らない噂が混在しているので、一個ずつだとコンテンツの意図が伝わりづらいというか「なにこれ意味不明」と思われて終わる可能性が高いような……。
ということで、一度に三個ずつ表示するようにしました。
試してみると一個だと少ない、五個だと多いと感じたので。

公開初日(2013.4.10 水曜)

公開したのはこの日の午後8時30分頃でした。
さあ、ついに公開!
ちょっとは使ってもらえると嬉しいな〜と思いながらGoogleのリアルタイム検索を見ていると、ぷよぷよの連鎖を思わせるつぶやきの連鎖で訪問者数がぐんぐんと上昇上昇急上昇。
ファイヤー!
アイスストーム!!
ダイアキュート!!!
Twitterすごい!
Twitter恐い!
リアルタイム検索って3桁になることあるんですね!
スクリーンショット
前にこの英語学習記事ではてなブックマークのホットエントリーに載って1000ブクマしていただいたときと同じぐらい、あるいはそれ以上?の勢いに到達。
他コンテンツでのcronの呼び出し回数調整
診断系コンテンツ以外にも、Twitter絡みでももクロシングル曲ランキング47都道府県名つぶやき数ランキング東京23区名つぶやき数ランキングといったコンテンツを運営しています。
これらはcron(設定しておくと定期的に自動でプログラムを動かしてくれるやつ)を使ってTwitterからつぶやきの取得を行うことで結果を表示しています。
そこそこ頻繁にcronでの取得を行っていたんですが、その取得間隔見直しを行いました。
なにか問題があったわけではないのですが、通信処理は早いうちに減らしておきたかったので。

公開2日目(2013.4.11 木曜)

Twitterで盛り上がるのなんてせいぜい1日だろうと考えていたのですが、2日目以降もアクセス数は減らず。
というか、どんどん増えました。
噂のパターン追加
嬉しいことに十個も二十個も噂をつぶやいてくださる人が多数いました。
これだけたくさん遊んでいただくと、噂のパターンがあっという間に枯渇してしまう!
ということで噂の文章の追加を開始しました(以降ほぼ毎日追加中)。
HTML/JavaScriptのバグ修正
コードのケアレスミスがいくつかあったので修正。
指摘してくださった方々本当にありがとうございます。
IEこそ念入りにチェックしなければいけないとわかっていながらもなかなか……。

公開3日目(2013.4.12 金曜)

#あなたの噂、がついているつぶやきを対象から削除
噂を生成する際、あなたの噂のハッシュタグがついたつぶやきをはずすようにしました。
そうしないと、延々と同じワードばかりが抽出されてしまうので(抽出されたワードが本コンテンツ経由でつぶやかれることでさらに抽出されやすくなってしまうということ)。
データ保存絡みのミスを修正
データを保存する際、最初の一回だけ保存しておけばいいものを二回目以降も保存しているケースがあったのでそれを修正。
保存されていることの確認はしていても、上書きされていないことの確認は怠っていたんです。

公開4日目(2013.4.13 土曜)

エラー発生時にページのリロードを求めない
噂生成プログラムの呼び出し失敗、DBへの保存失敗、TwitterAPIとの接続エラー、YahooAPIとの接続エラー等、想定されるエラーは多数あります。
それらが発生した際、ページをリロードしなくとも生成するのボタンを押すだけで済むように改善しました。
ユーザのストレスを軽減させられるかなと。
Yahoo APIへの送信エラー修正
Yahoo APIへのデータの送信でエラーを発見してそれを修正しました。
送信するデータがフォーマットに適さないことがあるという初歩的なものでした。
ページのデザイン変更
「公開して4日目でもうかよ!」
とつっこまれるの覚悟の上でページのデザインを修正しました。
デザイン面についてちゃんと考えていなかったのばればれですね。
スクリーンショット
噂の生成部分はいじらず、その下にある説明部分の右カラムにTwitterのタイムラインを入れてみました。
あと、他のページに誘導できるようにリンクを増やしてもみました。
せっかく来てくれたのだから他のコンテンツも見てもらいたいし、せっかく来てくれたのだからまた来てほしいし。
「訪問者が一見さんで終わらないための方策なんて企画の段階で考えておくべきことだろう!」
と自らをつっこみながら対応しました。
「たくさん人が来てくれるにはどうしたらいいか」 は作るときにけっこう考えるんですけど……
「たくさん人が来てくれた後にどうするか」 はなかなか考えが及ばないものですよね(言い訳)。
保存データの自動削除
アイコンのURLとか、噂を生成するための元データとか、いろいろとサーバで保持しているのですが、訪問者の上昇に合わせてこれらのデータ件数ももちろん上昇!
こんな勢いで増えることは想定していなかった!!
そりゃあ、万単位のアカウントで遊んでいただいていればデータ数もそれ相応になりますよね。
一定期間を過ぎたデータは流用しない仕組みですが、流用しなくなった不要なデータの削除処理をまだ組み込んでいませんでした。
基本的にAPIで取って来られる機密性がないデータだけで、しかも期間過ぎたデータはアクセスもされないので、削除については後で考えればいいやと思っていたんです。
(鍵付きアカウントの人がこのアプリで遊ぶためだけ一時的に鍵をはずして再び鍵をかけた後に気にすることはあるでしょうが)
「早急に対応しないとまずい!」
というところまでは全然行っていなかったですが、忘れた頃にまずくなりそうなので自動削除に着手しました。

公開5日目(2013.4.14 日曜)

データベースアクセス順序の修正
これまでデータの取得と保存は以下の順序で行っていました。
  • 該当アカウントのつぶやきデータの有無をデータベースに確認
  • なければTwitterから取得して保存
  • 噂用のキーフレーズ有無をデータベースに確認
  • なければつぶやきデータをYahoo APIに送信して噂用のキーフレーズを取得して保存
けど、最終的な噂用のキーフレーズがすでにある状況では途中のつぶやきデータいらないんですよね。
データベースを見に行く必要すらない。
ですので、まずは噂用のキーフレーズの有無を最初に確認し、無いときだけつぶやきデータを取得しに行くように変えました。
データベースへのアクセス部分は翌日さらに手を加えています。
他の診断コンテンツからリンク
過去に作った他の診断コンテンツから噂生成へのリンクを貼りました。
噂生成から他の診断コンテンツに行ってくださる人が多くて、そういう人たちはまた噂生成に戻りたいケースもあるでしょうから。
本当はコンテンツが増えたら自動で関連ページも更新されるようにしなきゃですよね。
それぞれのコンテンツが構造上分断されている現状をしっかり直したい……。

公開6日目(2013.4.15 月曜)

生成時にサーバからまとめてデータを渡すように変更
生成ボタンを押してサーバから返ってくる噂は、もともと3つ(表示1回分)だけでした。
けれどこの日からまとめて返すようにしました(いくつ返すかはまだ調整中ですが、30回分程度)。
返ってきた噂を順番に表示し、すべて表示しきってストックが空になった段階で再度サーバとの通信を行います。
来訪者が生成を一度しか行わなければむしろ通信量増えて改悪なのですが、多くの方々は生成ボタンを何度も押してくれていそうなので。
この対応で何度も生成を行った際の通信回数を激減できるようになりました。
前から「いずれこうしたい」と思っていた仕様をやっと実装できた感じです。
生成ボタンを押す度に通信があると、連打した場合サーバにかなり負荷かかってしまうので。
リリース前に実装しておけよって話ですね。
データベースへの保存処理改善
前日の項に書きました通り、つぶやき取得時と噂用のキーフレーズ取得時の二回、データベースへの保存を行っていました。
これを噂用のキーフレーズのみの保存へと変えました。
最終的なキーフレーズさえあればつぶやきそのものは不要なので。
入力フォームの表示をJavaScriptファイルの読み込み完了まで待つ
サーバとの通信はJavaScriptで行っています。
JavaScriptのファイルがロード完了していない段階で生成するのボタンを押しても動作しません。
ですのでロードが完了するまでは入力フォームを表示しないようにしました。
ボタンだけ消しても良かったのですが、表示されるまでの秒数はかなり微々たるもの(おそらくだいたいの環境で1秒未満)ですし、フォームがまとめて出た方が出現に気づきそうなのでこうしました。

公開7日目(2013.4.16 火曜)

ブックマークのリンク先修正
本コンテンツはURLの後ろに?userid=というパラメータをつけることでそのユーザーの生成結果を表示することができます。
「この噂をつぶやく」のボタンを押すとこのユーザーID付きURLでTwitterにつぶやかれます。
本コンテンツの上部についているはてなブックマークやEvernoteへの登録ボタン(↓のスクリーンショット)はAddThisというサービスを利用させてもらっています。
スクリーンショット
AddThisはURLを自動で設定してくれます。
そのため、Twitterのつぶやきからたどってたどり着いた場合、これらの登録がユーザーID付きURL(たとえばhttp://www.paper-glasses.com/twirumor/index?userid=katan_t)で行われていました。
「今後仕様変更してパラメータが変わることもあるかもしれない」
「ブックマークサービスでの登録数がURL毎に分散してほしくない」

といった理由があり、常にパラメータ無しのURL(http://www.paper-glasses.com/twirumor/)を返すように変更しました。

最後に

ということで公開前から公開1週間までの対応内容をざっとまとめてみました。
別に公開1週間で落ち着いたわけではなく、むしろこの頃よりもこの後にアクセスが急増してまた色々と対応したのですが、まあ書きすぎると取り留めがなくなってしまいますので。
(機会があれば別のタイミングで書くかも?)
今回のコンテンツリリースにおいて、なによりもTwitter上で数えきれないほど多くの方々が楽しんでいる様子を見ることができて嬉しかったです。
プログラミングをしてきてよかったと心底思うことができました。
心より感謝申し上げます。

キャプチャー


Twitterのつぶやきを元にした診断コンテンツをまた作ってみました。

Twitter つぶやき噂生成-あなたのことをうわさしちゃいます-です。

ユーザー名を入れると、その人のつぶやきを元にして噂を作るコンテンツです。


と書いてもわかりづらいですよね。
ということで以下、私のアカウントkatan_tで試してみた場合の実際の例文です。


「@katan_tから緊張の解消法教えてもらったよ」「俺にも教えてよ」「プリキュアって手の平に三回書いて飲み込むんだって」


「なんで@katan_tってあんなになっちゃったの?」「プログラミングにのめり込みすぎたんだってさ」


「修学旅行で@katan_tと同室なの嫌だな」「なんで?」「だって、寝言でダイキュウワダイキュウワつぶやいて恐いんだもん」


「@katan_tさん、あれ、なんの写真集見てるの?」「直球表題ロボットアニメの写真集らしいよ」「相変わらずね」


「@katan_tのやつ、OAuthが口癖だってまだ気づいてないよね」「ふれずにおきましょう、そのことには」


お遊びコンテンツですのでまじめなつっこみはなしでお願いします!

楽しんで使っていただけたなら嬉しいです。


過去のTwitter診断系コンテンツもよろしくお願いします。

キャプチャー

もうすでに四月だってのにまだ今年二度目のblog記事ですね。
ご無沙汰しております。

プロ野球も開幕し、新社会人が働き始め、私もアグレッシブな姿を見せつけなくては!!
ということで、Profile Image API For Twitterを公開してみました。


ユーザー名とサイズを指定するとTwitterのアイコン画像を返すAPIです。
imgタグの中に埋め込めばTwitterのアイコン画像を表示できます。
使うのに特別な知識はいりません。


これまでいくつかTwitter関連コンテンツを開発してきましたが、その中で制作したものとなります。


つい先日行われたTwitterのAPIバージョンアップ(1.0→1.1)でOAuth認証を経なければアイコンURLを取得できなくなりました。
開発者にとってはともかく、そうでないサイト運営者にとってはかなり面倒な変更ではないかと。


ですので、使う人もいるかもしれないなということで本APIを公開しました。


よければご利用ください。


これまでに作った他のものたちもここをクリックしてどうぞよろしくです。


皆様、良い春をお過ごしください!

キャプチャー

東京23区名つぶやき数ランキング47都道府県名つぶやき数ランキングに続きまして、今週三つ目のコンテンツを公開しました。
怒濤の年末ラッシュです。とは言っても、すべて同じ構造ですが。


今回公開したのは、これ!
ももクロシングル曲Twitter人気ランキング(動画付き)


ももクロのシングル曲名人気ランキングです。Twitterにて曲名で検索した際の結果を集計してランク付けしています(検索ワードは引っかかりやすいように多少加工しています)。
動画(MV/PV)と最新のつぶやきもセットで表示します。
ももいろクローバーZ時代、ももいろクローバー時代の両方が対象です。


今年一年、ももクロの曲にかなり励まされ、支えられててきのたで、その恩返しに少しでもなればいいなとか考えながら作ってみました。
紅白歌合戦出場おめでとう、そして、ありがとう! ということで。
色々な意味で今年の集大成的コンテンツかも。


このコンテンツがももクロ人気がさらに広がるきっかけになると嬉しい。


よければぜひご覧下さいませ!
そしてお気に入りの曲をつぶやきで応援ください!!

キャプチャー


先日の東京23区名つぶやき数ランキングの47都道府県版を公開しました。


47都道府県名つぶやき数ランキング


Twitterで47都道府県名が含まれるつぶやきを自動取得、それをランク付けしたコンテンツです。


位置情報を使用しているわけではなく、都道府県名で検索してみた結果の単純集計です。
最新のつぶやきと特産品一覧も表示します。


よければご覧下さいませ。
そして自分の好きな都道府県、それが必ずしも出身地や居住地じゃなくとも、ぜひ応援つぶやきを!

キャプチャー

久々に新しいコンテンツを公開してみました。

東京23区名つぶやき数ランキング

Twitterで東京23区名が含まれるつぶやきを自動取得、それをランク付けしたコンテンツです。

位置情報を使用しているわけではなく、区名で検索してみた結果の単純集計です。
最新のつぶやきと駅名一覧も表示します。

Twitterでデータ検索→加工というのはスマイルプリキュア!放送時のTwitterでの盛り上がりを再現してみたでもやりましたが、それをさらにちょっと進めた感じです。

せっかくなのでこれを活かして違うこともやってみたい。
都道府県版や都内鉄道版とか。

もう少し大きめなものも作ってみたい。

昔は使っていなかったのに、なくても平気だったのに、今ではなくてはならない私のパートナー、バージョン管理ツールGit(ギット)。
使い始めたときはその便利さに腰が抜けそうになるほど感動しました。
ということで、自分が好きなものは人に薦めたいという原始的感情に基づき、Gitがどういうツールなのか、今さらの今さらの今さらながら簡単にご紹介。
初心者向けというより、これからGitを使ってみようと思っている、勉強しようと思っているGitを知らない人向け。
Gitをインストールして一通りこの手順をなぞるとGitのさわりがわかるようにって意識して書いたつもりです。
(インストール方法はMacなら最速で Git を Mac にインストールして基本的なコマンドを使う方法 | ウェブル、WinならmsysGitのインストール - ふってもハレてもあたりを参照すれば良いかと)
行頭に > がついている行がターミナル(Mac)やコマンドプロンプト(Win)で入力する部分となります。
CUIベースです。登場するコマンドはinit、add、commit、log、reset、reflog、branch、checkout、merge。
リポジトリの複製には触れていないためcloneコマンドも出てきません。
「git-commit --amendぐらいは使えよ!」「そんな効率悪い使い方するな!」「環境を分散させろ、分散!」「Gitの価値は複数人での共有にこそあるだろう!」「ツールじゃなくてシステムって呼べ!」等々、言いたいことは多数あるかと思いますが、導入記事ということでご容赦くださいませ。
みんなGit使おうよ!

まずはinitでリポジトリの作成

まずは、リポジトリってものを生成します。
リポジトリとは、要は情報を管理するものです。
たとえば、ユーザールートのDocuments配下にgittestというディレクトリがあって、そこを管理対象にしたいとします。
> cd ~/Documents/gittest/
にて移動して(説明不要かと思いますが、↑はgitのコマンドではないですよ)
> git init
initコマンド実行!
Initialized empty git repository in /Users/hoge/Documents/gittest/.git/
こう画面に表示されます。
はい、これだけでリポジトリできました。
配下のディレクトリも管理対象になります。

ファイルつくってcommitしてみよう

このディレクトリに新しく、text.txtというテキストファイルを作ったとします。
中身は↓
テストデータだよ。
この時点でコミットしてみます。
コミットっていうのは超端的に言えば状態の記録。
> git add .
> git commit -m "最初のコミットだよ!"
commitコマンド実行!
commitの前のaddはどのファイルを対象とするかの指定なのですが、 .(半角スペースと.)とすることで全ファイルを対象とできます。
"〜"の中身はなにをしたコミットか後でわかるようにするためのコメントです。
[master (root-commit) e8c1294] 最初のコミットだよ! 1 file changed, 1 insertion(+) create mode 100644 test.txt
画面には何個のファイルをどれだけ変更したかの情報が表示されます。
これで現在の状態が記録されました。

logで履歴の確認

ここで
> git log
って打つと
commit e8c129432853bc0f4e3c7d74e6d0b6888982731b
Author: TaguchiKatan
Date: Sat Sep 29 00:55:00 2012 +0900

最初のコミットだよ!
という風に履歴確認できます。
このときにcommitの後ろに表示される文字列は、特定のコミットまで戻したいとき等に使用します(後述しますが、全桁はいらないです)。

やっぱり今のコミットなしなし! そんなときはreset --soft

たとえば、ファイルの変更とコミットを繰り返したとします。
テストデータだよ。お腹空いたよ。
> git add .
> git commit -m "二度目のコミットだよ!"
テストデータだよ。お腹空いたよ。眠いよ。
> git add .
> git commit -m "三度目のコミットだよ!"
テストデータだよ。お腹空いたよ。眠いよ。秋だね。
> git add .
> git commit -m "四度目のコミットだよ!"
git便利でお腹がすいた。
> git add .
> git commit -m "五度目のコミットだよ!"
いったん履歴を見てみましょう。
履歴を見るのはlogコマンドですが、オプションを指定すると省略形で見やすくなります。
> git log --oneline
0ba26ab 五度目のコミットだよ!
715a0e6 四度目のコミットだよ!
4a8fc57 三度目のコミットだよ!
2d82027 二度目のコミットだよ!
e8c1294 最初のコミットだよ!
オプションは色々あるので、複雑な開発をするときは調べてみると良いですよ!
さて、この状態で最後にしたコミットを取り消したいときはreset!
> git reset --soft HEAD^
これで五度目のコミットはなかったことに!
logを見てみると
> git log --oneline
715a0e6 四度目のコミットだよ!
4a8fc57 三度目のコミットだよ!
2d82027 二度目のコミットだよ!
e8c1294 最初のコミットだよ!
こう変わってます。
コマンドで使用したHEADは最新のコミットを意味します。
HEADの後ろの^はいくつ前かを意味します。
HEAD^ならHEADの一つ前。
HEAD^^ならHEADの二つ前。
つまり、上のコマンドは、最新のコミットの一つ前にsoftに(ファイルはいじらずコミットの記録だけ)戻す、って意味です。
ファイルそのものは変わっていません。
このHEAD^の部分にはlogコマンドで取得した文字列を指定することもできます。
文字列全部を入力せず、--onelineを指定したときに出た先頭数桁だけで大丈夫です。

ファイルそのもの元に戻したい! そんなときはreset --hard

ファイルそのものを二度目のコミットまで戻したい。
そんなときは、softではなくhard!
今は四度目のコミット時点にいるので、二度目のコミットまで戻すには^が二つ。
> git reset --hard HEAD^^
test.txtを開くと
テストデータだよ。お腹空いたよ。
二度目のコミット時点のデータまで戻った!
ちなみに、^を一つもつけなければ最新のコミットに戻ります。
最後のコミット以降の変更をすべて削除したいときにどうぞ。

ファイルを元に戻しすぎちゃった! そんなときはreflog

本当に戻したかったのは二度目じゃなくて三度目のコミットだった!
というときはまずreflogコマンド。
> git reflog
2d82027 HEAD@{0}: reset: moving to HEAD^^
715a0e6 HEAD@{1}: reset: moving to HEAD^
0ba26ab HEAD@{2}: commit: 五度目のコミットだよ!
715a0e6 HEAD@{3}: commit: 四度目のコミットだよ!
4a8fc57 HEAD@{4}: commit: 三度目のコミットだよ!
2d82027 HEAD@{5}: commit: 二度目のコミットだよ!
e8c1294 HEAD@{6}: commit (initial): 最初のコミットだよ!
はい、これまでやったことが全部出ました。
三度目のコミットはHEAD@{4}なので
> git reset --hard HEAD@{4}
test.txtを開くと
テストデータだよ。お腹空いたよ。眠いよ。
はい、元通り!

branchで枝分かれ

gitにはブランチというものがあります。
一言で言うなら枝分かれ。
要は今のファイル構成を複製した別環境を用意すること。
> git branch
と入力すると
* master
こう表示されました。
これは、今masterというブランチにいるよという意味です。
branchの後ろになにもつけないと今いるブランチが確認できます。
masterブランチはデフォルトで作られます。
> git branch master_temp
と入力すると新たにmaster_tempというブランチが作られ
> git branch
* master
master_temp
状態はこうなります。
> git checkout master_temp
と入力するとmaster_tempに移動します。
現在の状態を確認すると
> git branch
master
* master_temp
こうなります。
*の位置がmaster_tempに変わりました。
master_tempの中身はmasterと現時点では同じです。
さて、master_tempに移った状態で、test.txtを
テストデータだよ。お腹空いたよ。眠いよ。
から
中身を変えてみたよ。
こう変えて
> git add .
> git commit -m "大幅に変えてみたよ!"
コミット実行!
このコミットはmaster_tempで行われたもののため、masterには影響していません。
> git checkout master
masterに戻って、test.txtを見ると
テストデータだよ。お腹空いたよ。眠いよ。
はい、変わっていません!

mergeでブランチの内容を適用!

masterにmaster_tempで行った変更を適用したいときは
> git branch
* master
master_temp
今masterにいることを念のため確認してから
> git merge master_temp
test.txtを開くと
中身を変えてみたよ。
となります!
不要になったブランチを削除するなら
> git branch -d master_temp
-dと削除するブランチ名をつけてbranch実行。
状態を確認すると
> git branch
* master
ばっちり消えました!

最後に

まだまだGitの魅力の1/100も伝えられていません!
続きはぜひ使ってあなた自身の目で、身体で、気持ちで感じてください!
GitHubについてや複数人での使用についてもそのうちまとめたいところ。
みんなGit使おうよ!(二度目)
前へ 1 2 3 4 5 6 7 8 9 10 次へ

概要

青春B運営メンバー多口カタンによる雑記blogです。
自己紹介はこちら。開発物をまとめたものはこちら
 
ヘッダーイラストはkojiさん制作です。
感想・意見・要望等ありましたら気軽にフォームにてコンタクトくださいませ。
 
Twitterはじめましたので誰でも気軽に声かけてくださいね。