2014 9月4日 14:57
稀に今チェックアウトしてるところのコミットIDを知りたいときがある。 ぐぐったら下記のページがあったけど、grep やら awk やらつかっててずるい気がした。 gitリポジトリのリビジョン(コミットID)を取得するワンライナー | tomotaka-itoの日記 git log |grep '^commit' |head -1|awk '{print $2}' git コマンドだけで完結できる気がするので help を読んだりした。 以下に落ちついた。 git show -s --format=%H git log -n 1 --format=%H 関連 このコード書いた誰だよ! そんな時の git log -S でもしてみよう - そんなこと覚えてない Git で特定のコミットがどのタグに含まれているか確認する - そんなこと覚えてない
2014 7月7日 16:38
Atom Editor の Contributringをみてみると、「コミットメッセージの先頭に関係ある絵文字をいれろ」的なことが書いてある。 Git Commit Message - contributing - Atom :lipstick: when improving the format/structure of the code :racehorse: when improving performance :non-potable_water: when plugging memory leaks :memo: when writing docs :penguin: when fixing something on Linux :apple: when fixing something on Mac OS :checkered_flag: when fixing something on Windows :bug: when fixing a bug :fire: when removing code or files :green_heart: when fixing the CI build :white_check_mark: when
2014 5月28日 17:11
バグなどをみつけて原因のコミットをみつけたけど、バグというか自分が依存してるライブラリが古いせいだったりして、いつからじゃないと使えないですよーって伝えたい時に、どのタグに含まれてるコミットなのか調べたかった。 git tag コマンドの --contaions オプションが使える。 $ git tag -l --contains [コミットID] フィルターしたい場合は 引数にパターンが渡せる。 v4.0 系をみたいとかであれば $ git tag -l --contians [コミットID] `v4.0.*` みたいな感じ。 クオートしないとシェルに食われる。 パイプで grep してもいいけどね。 ブランチにも同様のオプションがある。 branch には似たようなものとして、ブランチにマージされてるかどうか調べる --merged とか --no-merged とかある。
2013 7月10日 01:54
Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 Araxis Merge を紹介します。 Cocoaアプリで表現も操作性も良いです。 だけど、値段を考えるとすこし残念な感じでした。 値段は 120ドルと Kaleidscopeの2倍近い値段です。 ちょっと高い。 マージモードなのに3カラムではなく、2カラムでどのようにマージされるのかわかりにくかったり、キーボードショートカット が fn + ↓ とかになっていて効かなかったりと、そのあたりが残念でした。 設定方法ですが、git にあらかじめ設定がもりこまれているため、インストールして、環境変数PATHを設定してやれば利用できます。 export PATH=/Applications/Araxis\ Merge.app/Contents/Utilities:$PATH ここもまた残念で、compare というコマンドで起動するようですが、 他にもcompareというコマンドがあると、これより先にコマンドがみつかるように PATH を設定する必要があります。 公式の設定だと PATH=$PATH:/Applications/Araxis\ Merge.app/Contents/Utilitiesとかかれていてハマりました。 あとは git mergetool -t araxis と、実行すると起動することができます。 常に Araxis を利用したい場合は git config --global merge.tool araxis としておくと -t araxis を省略できます。 画面左が現在のファイル内容で、画面右がマージしようとするブランチのファイルの内容になります。保存して画面を閉じれば左側の内容に決定したことになります。 左側がデフォルトで選択されていて、右側を採用したい場合は選んでいくという使い方になります。 TimeMachine との連携などもでき多機能で優秀なのですが、git mergetoolとして使うにはちょっと悩む感じでした。 有料だけあって、無料ツールよりはずっと使いやすいです。 関連 Mac で使える git mergetool をいろいろ試してみる - 準備編
2013 7月3日 21:27
Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 つづいて xxdiff を紹介したいと思います。 Ot で実装されているっぽいです。 マージ結果が常に表示されないため扱いにくいです。 また、Retina に対応していないみたいで、文字が読めませんでした。 あと、日本語が文字化けしました。 設定は不要で、 git mergetool -t xxdiff とすると起動できます。 また、常に xxdiff を利用したい場合は git config --global merge.tool xxdiff としておけばよいです。 画面左に現在のブランチのファイル、画面右にマージするブランチのファイルの内容が表示されます。 キーボードショーットカットは充実しているようですが、マージ結果をみる方法がわかりませんでした。 日本語はでないし、マージ結果の出し方がわからないということで利用は難しそうでした。 関連 Mac で使える git mergetool をいろいろ試してみる - 準備編
2013 7月3日 21:07
Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 tkdiff を紹介します。 名前のとおりツールキットは tk なのでマルチプラットフォームのアプリケーションです。 マージ結果が同時に表示されないので非常に使いにくいです。 最近は Mac で tk のアプリケーションの起動速度が早くなってるのに少し残念です。 ツールキットの都合、表示も他に比べると綺麗ではありません。 設定は不要で、 git mergetool -t tkdiff とすると起動できます。 また、常に tkdiff を利用したい場合は git config --global merge.tool tkdiff としておけばよいです。 画面左に現在のブランチのファイル、画面右にマージするブランチのファイルの内容が表示されます。 マージされる内容を表示するには、画面上部の緑の部分をクリックするとみることができます。 左や右やじるしをクリックすることで、変更を選択できます。 ツールキットの都合、使いにくいです。常用には耐えそうにありまんでした。 関連 Mac で使える git mergetool をいろいろ試してみる - 準備編
2013 7月3日 20:08
Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 Vimdiff2を紹介してみます。 emacs使いですが、 vimさえ入っていれば、設定不要で、「気軽に使えるかなぁ。」という目論見です。 vimdiff2 とかいてみましたか、vim の起動方法が違うだけのような感じでした。 よくわかりません。 vimdiff でも起動できます。 設定は不要で、 git mergetool -t vimdiff2 とすると起動できます。 また、常に vimdiff2 を利用したい場合は git config --global --global merge.tool vimdiff2 としておけばよいです。 ヘルプを見るには vim を起動した状態で ` :h vimdiff で help が出せました。 pecosantoyobeに教えてもらいました。 ありがとうございます。 画面左が現在のブランチのファイルの内容で、画面右がマージするブランチのファイル内容です。 中央にはコンフリクトしたファイルの内容がでており、修正することができます。 次のコンフリクト場所に移動するには ]c で移動することができます。 前のコンフリクト場所に移動するには [c で移動することができます。 コンフリクト場所に移動して、:diffget L と入力すると 左の内容を取り込むことができ、:diffget R と入力すると右の内容を取り込むことができます。 移動も含めてショートカットを用意すると、とても便利そうです。 終了の仕方がよくわかりませんでした。 ZZZZZZ として終了しました。 もっとよい方法があるような気がします。 終了すると次のファイルが自動的に開きました。 とても便利でした。 なんとなく emacs に渡せないときに使いたいと思います。 関連 Mac
2013 7月3日 19:16
Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 DeltaWalker を紹介します。 DeltaWalker 49ドル の有料アプリケーションで、見た感じ Eclipse と同じツールキットのようで、マルチプラットフォームを実現しているようです。 しかし、購入する際はOSを指定するので、OSごとにライセンスがいるのでしょうか。試用ができるので試してみました。 有料ツールの中では値段が安く、日本語を使用していても問題はおきてないです。 設定するには /Applications にインストールした場合は git config --global --add mergetool.dw.cmd '"/Applications/DeltaWalker.app/Contents/MacOS/git-merge" "$LOCAL" "$REMOTE" "$BASE" "$MERGED"' で設定できます。 起動するには git mergetool -t dw とするとできます。 デフォルトで起動するツールに設定したい場合は git config --global merge.tool dw で、設定することができます。 画面左にもとのブランチのファイル、画面右にマージするブランチのファイルが表示されます。中央にマージ結果が表示されています。 マージ方式は emacs の ediffと同じように、先にベースしたいほうを選びます。 そうすると細かいコンフリクト箇所が表示されるので、どちらを選択するか選ぶことができます 。 左を選ぶか、右を選ぶかを選択するための状態にもっていくのが少し扱いづらかったです。 なぜだかわからないですが、左しか選べない状態になったりしました。マウスクリックですることで直りました。 コンフリクトの修正後は、ウィンドウ閉じれば次へ勧みます。 他にコンフリクトするファイルがあれば続けて表示されます。 修正が終了するとコンフリクトしたときのファイルは .orig が末尾について保存されます。 気になる点は Java で実行するため、起動が少し遅いです。 関連 Mac で使える git mergetool をいろいろ試してみる - 準備編
2013 6月29日 22:58
Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 Kaleidoscope を紹介します。 Cocoaアプリということで、万人にに勧めたいという理由で一番注目しております。 Mac App Store で開く 有料アプリで金額は App Store では 6100円 です。 画面は圧倒的に綺麗でMacとの親和性が非常に高いです。 画像の差分も見れたりするので difftool としても気になります。 ただし、私の環境のせいなのか、トライアルバージョンで試しているのかわかりませんがgit mergetool から上手く扱えない。 製品版なら上手いこといくのか確認したいのです。 追記: 2013-07-10 tmux 上で実行していたら発生することがわかりました。 値段的にも、インターフェイス的にも一番デザイナーさんに勧められるツールです。 追記終了 設定はとても簡単です。 ダウンロードして、起動後に メニューから integration… を選択して設定します。 install と configure をクリックすれば完了です。 ここからが問題なのですが、git mergetool で起動しても画面が出ません。 起動はするのですが、起動していた状態でないと画面がでませんでした。 起動をすれば下記のような画面が出ます。 画面も3種類あり自由に切り替えたりすることができます。 左側がマージ前のファイルのもので、中央がマージ結果で、右がマージに指定したブランチのファイルの内容になります。 下部の右下のボタンで 競合場所を移動でき、下部中央のボタンでどちらを採用するか選択できます。 これらはキーボードショートカットで、コマンド + ↓、コマンド + ↑、で、コンフリクト箇所を移動することができ、コマンド + ←、コマンド→ でどちらを採用するか選択できます。 カーソルキーを普段使う人であれば使いやすいと思います。 修正を終了するには終了すれば、プロンプトが書いてきますが、失敗しているような挙動をしていてちょっと困っております。トライアルだからなるのか、バグなのか。 タブになっているのでコンフリクトしているファイルをまとめて開いて欲しいところです。 使い勝手はよさそうなので、購入してみて、バグレポートするか悩んでいるところです。 一番期待できるだけにちょっと残念です。 追記。直せたので再度試しました。 コンフリクト修正後は保存して、ウィンドウを閉じれば次に進めます。 見た目、操作性を考えると、さすが有料アプリといったクオリティだと思いました。周りに薦めていけるツールでした。 関連
2013 6月29日 19:27
Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 ediff は Emacs に添付されているマージツールです。 いつから添付されているのか調べてないですが最近のEmacsであれば標準で使えるはずです。 個人的には一番使いやすいと感じています。 git mergetool から ediff を起動するのはややめんどくさいです。 magitを使用していれば、コンフリクトしているファイルにカーソルを合わせて e を押すと起動できます。こちらのほうは設定いらずで楽ちんでした。 どうしても git mergetool から使いたい場合は git mergetoolでEmacsのediff-merge-files-with-ancestorを呼び出す - 工夫と趣向と分別と。 を参考にするとできました。 具体的には上記の記事で紹介されてる emacsc をclone してきて設定しました。 個人的な使い方の問題で emacsclient への引数を付加したかったので少しいじりました。 ediff を起動するとこのような画面になります。 配色設定を細かくやってないのでみづらいのは気にしないでください。 左が現在のブランチのファイルで、右がマージしようとするブランチのファイルになります。 下部がマージ結果になります。下部は直接編集することもできます。 a を入力すると 左側を選択できて、 b を入力すると右側を選択できて、下部に反映されます。 差分は2行あるのに、まとまってしまって不便に感じますが、どちらをベースするかという選択だと考えると良いことがわかりました。 その後 ! を入力すると細かく差分が表示され n や p で競合箇所を移動して a や b で選ぶことができます。 編集が終了したら q で終了できます。 magit から起動した場合は ステージングされないので注意してください。 再度 e を入力するとやりなおすこともできます。 emacs
2013 6月29日 18:58
Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 p4Merge を紹介します。 先に問題点などを書いておくと、日本語が利用されていると表示がずれてしまいます。 Qt が利用されているので Cocoa アプリに比べると動きは悪いですが、インターフェイスは使いやすいです。 インストールには、サイト下部の Download now をクリック後にOSなどを選択してダウンロードします。 ダウンロード後は/Application に配置します。 設定は以下のコマンドでできます。 git config --global mergetool.p4merge.path /Applications/p4merge.app/Contents/MacOS/p4merge git config --global mergetool.p4merge.keepTemporaries false git config --global mergetool.p4merge.trustExitCode false あとはコンフリクトした際に git mergetool -t p4merge と入力すると利用できます。 git mergetool だけで起動できるようにしたい場合は git config --global merge.tool p4merge としておくとよいです。 起動すると下記のような画面です。 画面中部に 左から マージしたいブランチのファイルの内容 枝わかれした時のファイルの内容 現在のファイルの内容 になってます。他とは左右が逆なので注意が必要です。 画面下部にはマージ結果の情報が出ています。 下部の右側のボタンを押すことでどちらの変更を使うか選択できます。 両方を選ぶことはできませんでした。 また、選択後に編集することもでき、アンドゥもすることができます。 ツールバー一番端で最初からやりなおすこともできて、良いと思いました。 編集後は p4merge を終了することで、次のファイルへ移行として同じ作業を繰返します。 マージする前のファイルが .ファイル名に .orig
2013 6月26日 21:10
Mac で使える git mergetool をいろいろ試してみる - 準備編 の続きです。 Xcode に標準添付されていた opendiff を紹介します。 Source Tree にもついてきていましたが、挙動が微妙に違いました。 設定は不要で git mergetool -t opendiff と入力すると利用できます。 git mergetool だけで起動できるようにしたい場合は git config --global merge.tool opendiff としておくとよいです。 日本語がまざっていると、 file are not ascii と メッセージ がでますが、 proceed anyway をクリックすると問題なく動きます。 opendiff で起動しますが FileMerge というアプリケーションのようです。 左側に checkout しているブランチのファイル、 右側に merge しようとするブランチのファイルが表示されます。 下側に マージ結果が表示されます。 デフォルトで 右側のものが選択されていました。 競合箇所をクリックして、画面右下の actions から選択することで、どちらの変更を使うか、両方を使うかなどが選べます。 競合箇所は真ん中の矢印がでている部分ではないと機能しないようでした。 キーボードで移動したい場合は command + d で次へ進み、 command + shift + d で前へ戻ります。 下部の部分は 編集可能で、修正を加えることもできます。 修正が修正したら、閉じてコマンラインに Was the merge successful?
2013 6月26日 19:08
この記事は すごい広島 #6 での活動の一部です。 Git で branch をマージしたときにコンフリクトが起きると、これを解消する必要があります。テキストエディタでがんばるのはつらいこともありますよね。 そんなとき、マージするためのツールを使いたい場合もあります。 Git に git mergetool というコマンドがあって、設定しておいたツールを起動することができます。 同様に 差分を見るのにGUIツールを使いたい場合などには git difftoolというコマンドもあります。 基本的には Mac で使えるものを紹介しますが、マルチプラットフォームのもあるので、別の環境でも使えるものもあります。 試したツール opendiff - 無料 Xcode に添付されている p4merge - 無料 Qt ediff(emacs) - 無料 Kaleidoscope - 有料 - Cocoa アプリ (Mac Only) deltawalker - 有料 マルチプラットフォーム vimdiff2(vim) - 無料 tkdiff - 無料 マルチプラットフォーム xxdiff - 無料 マルチプラットフォーム Araxis Merge - 有料 (Winあり) いろいろ試すために用意したもの いろいろ試すのになるべく楽をしたいので以下のリポジトリを用意しました。 Github eiel/git-merge-sandbox このリポジトリを clone して $
2013 6月5日 13:26
朝早く起きることができたら、QA@ITで、遊んでいます。 ざっと未解決の質問を見て、すぐわかりそうなものを試して解答をします。 今日は 「rails new project -d postgresql を指定した時に変更される部位」というのがあって、「試せばいいやーん」と思ったので、すぐに手を動かしてみました。 rails new project と rails new project -d postgresql の違いについて。 だいたい以下の操作をすれば違いはわかります。 rails new project mv project project_sqlite3 rails new project -d postgresql diff -ru project_sqlite3 project とすれば違いは簡単にわかります。 new の引数は同じ名前にしないと、余計な差分ができてしまうので、作成した後に リネームしています。 折角なので Git を絡めてみた Git のリポジトリって直接移動してもそのまま使えるんだぜ! rails new project mv project project_sqlite3 cd project_sqlite3 git init git add . git commit -m 'initial' cd .. rails new project -d postgresql mv project_sqlite3/.git project cd project git diff という、感じの解答をしてみました。 .git を移動をしてるのが味噌です。 リポジトリに対する物理的なワークツリーが変わっても簡単に認識してくれます。 このようにGitの理解が深まってくると応用力がついてきて、「subversion より Git 楽しいなぁ」と、個人的にはなります。 別解 git には リポジトリを指定するオプション --git-dir があります。 なので以下のような方法もあります。 rails new project mv project project_sqlite3 cd project_sqlite3 git init git add .
2013 6月4日 20:30
広島Git勉強会 で @pecosantoyobe が git log の使えるオプションについて語るというナイスなセッションがありました。 その中で git log -S の紹介がありましたが、説明が難しそうなので、さらっと流れてしました。 折角なので実例を紹介します。 複数人でプログラムを書いてると、「このコード書いたの誰だよwww」 的なことが稀にあります。 例えばこんなコードがあるとします。 class Sample def hoge hogehoge_gorogoro.to_sym.to_s end def hogehoge_gorogoro "hogehoge_gorogoro" end end 「hogehoge_gorogoro.to_sym.to_s ってなんだよ!! 意味あるのかよ!」 みたいなことがあると思います。 そんな時はすかさず git blame を利用します。 みやすさの都合上、emacs の magit-blame を利用します。 e92db224 で変更されていることがわかります。 ちょっとこの時のコミットを見てみましょう。 git show e92db224 インデントの修正されているだけで、大した情報が得られません。 こんなときに git log -S を使います。 git log -S 'hogehoge_gorogoro' --patch 変更内容が見たいので、 --patch をつけました。 「なんだよ。initial commit ではじめからそーなのかよ!!」 なんて展開でした。 ちょっと例が凝れてなくて便利さが伝わりにくいかもしれません。 diff の内容から更に git log -S で追ってみたりできます。 もし良いコミットログがあれば、コードの意図がわかったり チケットID などが記載されていれば、そちらを参照することになります。 「なんだよ。書いたのオレじゃねーか!!
2013 6月2日 21:14
書きわすれたことがあった。 ひとつ前のエントリはそれはそれで完結してるので、追記せず、別にしてみる。 そういえば、ひとつ前のエントリーうっかり Ruby勉強会って書いてました。見なかったことにしてください。 広島Git勉強会 の終了後に懇親会の代わりに、別の教室で Github Flow体験をしました。 やることの手順ははGistにかいてます そしてその成果物がこの辺です もし、やってみたい方がいれば気軽に挑戦してみてください。Issueにそれっぽいことを書いてもらえたら大丈夫です。 先に空のブログ記事をつくって pull request して、あとからブログに感想を書くなどでも大丈夫です。もっと面白いことが思いついたらそれでもOKです。 やってみて思ったことですが、Git普段使ってない人であれば、これだけでも結構難しいようでした。 次回やるときはもっと準備しておこうと思います。 関連リンク 広島Git勉強会 - 番外編 Github Flow してみる Github Pages について整理しておきます Github で Jekyll を使う時に調べたこと Git がわからなくても Github を利用しよう Github の楽しみ方
2013 6月2日 20:47
広島Git勉強会 に参加しました。 1セッション喋りました。 はじめからgit reset と git checkoutあたりを説明しようと思ってたのですが、「元に戻せること」を主眼においていろいろ考えました。 結果として、「危険」「少し危険」なコマンドを定義して、よくわからない時どうすればいいのか伝えられるか試みてみました。 「危険」なコマンドはワークツリーにした変更が消えてしまう恐れがあるもの。 「少し危険」なコマンドはgit reflogなどを利用しないと追えなくなるコミットができてしまうもの。 と定義して、そこを強調しながら説明してみました。 スライドはこちらに。 やりなおせる Git 入門 from Tomohiko Himura 結局、難しかったのか簡単だったのか、周りの空気を読む余裕が僕にはまだまだ足りなくて、「経験値を積まないといけないなぁ」と、思うのでした。 追記 ブクマのコメントなどなどに返信 「git commit の -m はそろそろ卒業しましょう」というのはどういうことなのかな？ -m って解説のために、そう書いてることが多いじゃないかと思う。スライド上でも -mを利用していますが、こ の場合はコミットログをタイトルしか書かない場合が予想できる。なので、「概要も書きましょう。」という話をするために書いています。 良いまとめ。だけど rm -rf .git ってそんなにカジュアルでいいのかなw すごく危険な操作なので、カジュアルにやるのはよくないですが、初回のコミットまでなら。という感じで口頭では伝えております。スライドにも入れればよかった。 関連リンク 広島Git勉強会 - 番外編 Github Flow してみる 岡山Git勉強会 - 20130223 - Git 仕組み入門 という話をしてきた Git がわからなくても Github を利用しよう Github の楽しみ方
2013 2月23日 21:24
岡山Git勉強会 20130223 で Git 仕組み 入門という話をしてきました。 トゥギャッター セキココ もっと簡単な内容にできるかな？っと思ってやってみたのですが、やっぱり難しめだったみたいです。 スライドだけでもある程度理解できるように細かめにつくってみました。 やりすぎた感が漂います。 Git 仕組み 入門 from Tomohiko Himura スライドをつくる際のメモなどもupしています。 この辺りの話を聞いたことがない方は手を動かしてみてはどうでしょうか。 話し忘れたこと 日頃使うツールはしっかり理解したほうがいいと思う tree オブジェクトに登場した mode は 666 とかよくパーミッションがどうこう言われるアレです。 このあたりの仕組みが入門書に出てくるあたりも Git の魅力なだと思います。 内容にあまり関係ないこと keynote の機能をいろいろためした もっとはやく勉強しておけばよかった。マスタースライドでスライドのテンプレートをつくっていじると、スライドのデザインをまとめていじれる。 背景色をうっすら変えてみた。 お洒落感が出るのか試してみたかった。結果はよくわからない。 ディスプレイでみるとわかる違いはプロジェクターでわかるかどうか怪しい。 keynote で アウトラインからスライドを作ると効率よさげ 前述のマスタースライドの機能がわかっていれば、わりといけます。 まとめ 話をするのは苦手で、相変わらず、反省点の多いセッションですが、話を聞いていただいてありがとうございました。良い経験になりました。
2012 12月22日 11:06
ソースコードよみたいなー。よみたいなーってことで、環境を整えていきたいと思います。ひらメソッドにも挑戦したい。 静的によむのも良いのですが、答え合わせができないと遠まわりです。デバッガを使って答え合わせできると効率がよいです。なので、ソースコードをDLして、動作確認するところまで試してみましょう。 Gitのソースコードは https://github.com/git/git とかにあります。 cloneしてみましょう。 $ git clone git://github.com/gitster/git.git $ cd git 別にどのバージョンにしてもいいのですが、自分が使っているバージョンでコードリーディングしていきたいと思います。 $ git --version git version 1.8.0.2 $ git checkout v1.8.0.2 これで v1.8.0.2 のソースコードになっています。デバッグ情報をもった状態でビルドしてみましょう。 $ make -d -d をつけることでOKです。 しばらく待つとバイナリが生成されますので、gdb をつかってみましょう。 $ gdb git (gdb) これで gdb が起動できます。プロンプトに (gdb)と表示されます。 この状態で r を入力すると実行ができます。 (gdb) r usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>] [-c name=value] [--help] <command> [<args>] The most commonly used git commands are: add Add file contents to the index bisect Find by binary search the change that introduced a bug branch List, create, or delete branches checkout Checkout a branch or paths to the working tree clone Clone a repository into a new directory commit Record changes to the repository diff Show changes between commits, commit and working tree, etc fetch Download objects and refs from another repository grep Print lines matching a pattern init Create an empty git repository or reinitialize an existing one log Show commit logs merge Join two or more development histories together mv Move or rename a file, a directory, or a symlink pull Fetch from and merge with another repository or a local branch push Update remote refs along with associated objects rebase Forward-port local commits to the updated upstream head reset Reset current HEAD to the specified state rm Remove files from the working tree and from the index show Show various types of objects status Show the working tree status tag Create, list, delete or verify a tag object signed with GPG See 'git help <command>' for more information on a specific command.
2012 11月20日 15:41
git の hooks の update hook の動作確認するのに使ってたワンナイナー。 update というのは リモートリポジトリに push したときに リモートで起動するスクリプト。 $ git commit --amend --no-edit; git push --force git commit --amend を使用してコミットの日付を変更しておけば新しい commit として認識してくれるので、–force オプションで無理矢理 push してやる。 コミットが新しくなるので hook が起動してくれます。 git push の部分は適宜好みに合わせて。
2012 6月13日 18:00
skypeでgitの説明していたときに gitxa って何？と問われた。単なるgitx --all のエイリアスです。 alias gitxa="gitx -all" Gitx Mac用のgitクライアントツールにGitxというものがあるのですが、コミットの機能なども備えていますが、私はgitkコマンドの代替として利用しています。 ただし、Gitxをインストールしただけでは gitx コマンドは使用できません。Gitxのメニュー内のEnabble Terminal Usaeg… をクリックすることで利用できるようになります。 gitxを引数になにもなしで、呼びだした場合、checkout している branchを表示します。--allを使用するとall branchesを選択した状態になります。 他にもときどき便利なのは gitx ブランチ名 や gitx -- ファイル名 などがあります。gitkを使う場合はさらにいろいろできます。詳細は man gitk にて。
2012 5月30日 17:55
共同作業ないし、自分が書いたコードでもここ変更したのいつだっけってことあるとgit blameを利用するんですが、emacs の magit についてる magit-brame-mode がみやすくて感動しました。 git blameがどのようなことをしてくれるのかは github でも特定のファイルを選択したときにもみることができます。 押すとこんな感じ。 すっきりみやすい。 端末で $ git blame conf/50-ruby.el するとこんな感じ。 文字ばっかり。 git-emacsの M-x git-blame-mode だとこんな感じ カラフル。細かい情報はミニバファにでます。そのまま編集できるのはナイスなのかもしれない。(重いですけど magitの M-x magit-blame-mode だとこんな感じ あれ、なんかみやすさが伝わない…。 80列におさまるのは嬉しいですね。 ゆっくりみる分には github が一番いんじゃないかということいわれてしまいそうです。