今いるブランチをプロンプトに表示する。
そもそも、なんで間違ったブランチで作業してしまうのか
ありがちな理由：今、どこのブランチにいるのかわからない
からだと思います。これ表示できたら便利ですよね。 て、毎回思ってたのですが、結局やらず終いになっていたので、いい加減やりました。
参考にしたのは、次の2サイト。
http://mironal-memo.blogspot.jp/2012/08/git-completion.bash.html http://d.hatena.ne.jp/deeeki/20110402/git_branch_ps1
やり方はすごい簡単。
1. 移動
cd ~
2. git-completionをDL
wget https://raw.github.com/git/git/master/contrib/completion/git-completion.bash wget https://raw.github.com/git/git/master/contrib/completion/git-prompt.sh
3. 隠しファイルに設定する。
mv git-completion.bash .git-completion.bash
mv git-prompt.sh .git-prompt.sh
4. .bashrcの設定
vim .bashrc から
if [ -f ~/.git-completion.bash ]; then source ~/.git-completion.bash fi if [ -f ~/.git-prompt.sh ]; then source ~/.git-prompt.sh fi PS1='\[\033[01;32m\]\u@\h\[\033[01;33m\] \w$(__git_ps1) \n\[\033[01;34m\]\$\[\033[00m\] '
を追加
色とかはPS1で好みに設定して下さい。
注意：git completionのoptionとして渡す環境変数によっては恐ろしく悪くなりますがデフォルトでは普通なので、安心してください。下が恐ろしくなる可能性のある環境変数です。
#GIT_PS1_SHOWDIRTYSTATE=1
by 同僚からのアドバイス
参考まで
違うブランチで作業していた時の解決策
あるあるです。
違うブランチで作業してしまっていた時、
（´-`）.｡oO（やっちまったー。今日やった変更箇所、あっちのブランチにくっつけたいー）
とか思いますよね。
いつも自分の解決策は、
方法1. とりあえずaddしてcommitして、cherry-pickする。
が第一の方法、commitした後、git logでcommitハッシュとってきて、それを正しいブランチでgit cherry-pickします。その後、間違えた方のブランチへ戻り、git reset --hard HEAD^ で一個前の履歴へ戻り、解決です。
方法2. git stashからのpop
まだcommitしてなければ、今回の変更点をgit stashで一時保存した後、正しいブランチに切り替えてgit stash popする。
自分がやるのはこの位です。他にいい方法があったら教えて下さい。orz
テストコードを一括でテストする。
タイトル通りです。
作ったテストコードを、prove -v ファイル名
ok ok ok
テスト完了！
よし、次のファイル
と、沢山のテストコードをテストしていて、思いました。
（´-`）.｡oO（一括でテストできないかな）
結果、すごい簡単でした。
テストしたいファイル一覧があるディレクトリごと
prove すれば、一括でテストができるんですね。
参考まで
git cherry-pickで起きてしまったconflictの解消方法【--ours、--theirs】
タイトル通り
git cherry-pickってすごい便利ですよね。
ご存知の通り、"git cherry-pick コミット名" で他のブランチのcommitでも、自分のブランチに付けちゃうことができます。 まさしく、さくらんぼをつまんで、自分の枝に付けるといったイメージです。ネーミングセンス抜群ですね。
ですが、これって良くコンフリクト起きます。
今回はそれについてのお話です。
1. とりあえずgit status 話はそれからだ。
とりあえずgit statusしてみてください。
そうすると、conflictしているファイルがあります。
そこでコンフリクトしているファイルを開いて、>>>>HEADから<<<<までを編集するのが普段の流れでしたね。
でも、これ一個、一個コンフリクト解消するためにファイルを直すのって結構、手間なんですよ。 もちろんファイルを見るのは必須ですが、
このファイルは、cherry-pick前の内容を優先したい、このファイルは、cherry-pick後の内容を優先したいなどがある時があります。
そういう時には、git checkout --ours と git checkout --theirsを使うといいと思います。
git checkout --ours ファイル名
まず、git checkout --oursですが、こちらはgit checkout --ours ファイル名 で指定したファイルでconflictが起きた場所をcherry-pick前の内容に優先して書き換えてくれます。
git checkout --theirs ファイル名
一方、git checkout --theirsはgit checkout --theirs ファイル名 ですが、こちらは指定したファイルでconflictが起きた場所をcherry-pick後の内容に優先して書き換えてくれます。
補足ですが、こちら両方ともスペースをあけてファイル名を指定すれば複数のファイルを一括変換できます。
覚えておいて損は無いコマンドだと思います。参考まで
SQL::Absract のselectのwhere句に空のリストを入れた時の挙動
SQL::Abstractは本当に便利。
http://search.cpan.org/~ribasushi/SQL-Abstract-1.77/lib/SQL/Abstract.pm
（´-`）.｡oO（引き数渡したら、自動的にSQL文作ってくれないかな）
と、思っていても大抵のことはできちゃいます。ですが、便利だけど
魔法の箱
になりがちです。
引き数によってどういったSQL文が生成されるかについて、出力される$stmt、@bindの値を心配ならprintなりして、見ておいた方がいいです。（ソースコードも）
SQL::Abstractのselectですが、非常に便利でwhere句に指定した値で自動的にSQL文を生成してくれます。
例：
# 引き数にユーザー情報(例：$users = [1,2,3]
$users = shift;
my %where = (
user_id => $users, #( usersにはuser_id = 1, 2, 3 が入る)
);
my($stmt, @bind) = $sql->select('table', '*', \%where);
上の例は次のようになる：
$stmt = "SELECT * FROM table WHERE
( user_id = ? OR user_id = ? OR user_id = ? )";
@bind = (1, 2, 3);
便利ですね
ですが、ここで、usersに空のリストが入ってきた時、どういったSQL文が生成されるか気になりました。というのは、whereでuser_idが指定されない場合、DBを全部参照してしまうのかも、、と不安があったからです。（例：$stmt = "SELECT * FROM table"）
結果は、 "SELECT * FROM table WHERE ( 0=1 )"; となり、空振りするようになりました。 これであれば問題ないですね。参考までに
# 引き数に空のリスト(例：$users = [];
$users = shift;
my %where = (
user_id => $users, #( usersには[] が入る)
);
my($stmt, @bind) = $sql->select('table', '*', \%where);
上の例は次のようになる：
$stmt = "SELECT * FROM table WHERE
( 0=1 )";
@bind = ();
ステータスコード302と303の違い
今日ステータスコード200と302の説明を少し受けたので補足。
wikiより、http://ja.wikipedia.org/wiki/HTTPステータスコード
302 Found
発見した。リクエストしたリソースが一時的に移動されているときに返される。Location:ヘッダに移動先のURLが示されている。 元々はMoved Temporarily（一時的に移動した）で、本来はリクエストしたリソースが一時的にそのURLに存在せず、別のURLにある場合に使用するステータスコードであった。しかし、例えば掲示板やWikiなどで投稿後にブラウザを他のURLに転送したいときにもこのコードが使用されるようになったため、302はFoundになり、新たに303,307が作成された。
303 See Other
他を参照せよ。リクエストに対するレスポンスが他のURLに存在するときに返される。Location:ヘッダに移動先のURLが示されている。 リクエストしたリソースは確かにそのURLにあるが、他のリソースをもってレスポンスとするような場合に使用する。302の説明で挙げたような、掲示板やWikiなどで投稿後にブラウザを他のURLに転送したいときに使われるべきコードとして導入された。
ん？リダイレクトは302は使っていて・・あれ？302と303の使い分けがわからない。
ってことで調べてみた
簡単に302と303の違いについて
http://www.onflow.jp/cyano/archives/161
お、書いてありました
GET動詞（aタグのリンクをクリックしたときなどですね）でリクエストされたリソースのURIが一時的に変更になった場合は、『302 Found』か『307 Temporary Redirect』を返すと良いそうです。『302 Moved Temporarily』が返された場合、リクエストに使った動詞（GETとかPOSTとか）を変更してはいけないがルールだそうです。
うーん。これ大事なのか・・どっちでもいい気が
