ここ数日、Gitの勉強をしています。参考にしてるのはWEB+DB PRESS Vol.50の特集記事で以前一度読みながら理解を深めようとしたけど、途中で断念した苦い思い出があって今回再びGit熱がメラメラと湧いてきたので頑張って勉強しようと思っています。ちなみに最近見つけたMUJI カフェの日比谷店で早朝から勉強しているのですが、ここはオトナな雰囲気で落ち着いて勉強出来るので最高な場所です!(欲をいえばここでhotspot使えれば文句ないんだけどねー)
2010年3月31日
日比谷のMUJIカフェで朝からGitの勉強。
自分で作ったツール類をしっかりバージョン管理したくなって、以前も一度Gitの勉強したけどどうもまだ手に馴染んでいないのでこれを機会に折角なので勉強
git diffは、まだgitに記録したいとリクエストしていない(git addしていない)変更点を出力しますから、今したばかりの価格訂正だけが出力されます。
一方、git diff HEADは、まだコミットしていない(git commitしていない)すべての変更点を出力します
WEB+DB PRESS Vol.50 64ページより
このあたりは以前にも勉強したのでスムーズに頭に入ったのでOK
2010年4月1日
68ページから再開
部分変更をどう管理するのかという部分について
論理的に関連のない複数の変更は別々のコミットとして記録するのが、お行儀の良いバージョン管理のコツです。(これはgitに限ったことではありません。)
WEB+DB PRESS Vol.50 69ページより
たしかに、いわれてみればそうだよね。
すべての変更点を管理するという視点に立って考えれば、関連性の無い変更が複数あって、それをひとまとめにしてcommitするのは、将来その箇所の部分に遡るような場合に何か不都合なことが生じそうだし。
本文中の例としては、対象となるHTMLファイルに対して
・head要素にtitleを追加
・お品書きに、1品追加
という状況を想定しておりその場合に
git commit -a
としないで、1つ1つの変更に対してcommitするようにしている。
作業的には
git add -p
とすると
Stage this hunk [y/n/a/d/s/e/?]?
と質問されるので、変更に加える個所を1つ1つ追加出来るので、作業していく
その上で、commitする時にも気をつけないといけないのは、
git commit -v
とvオプションをつけることで、git add -p でステージした状態かどうかを確認しながらcommit出来る
ただ本文通りにやったんだけど、2つのハンクが出てこないから
Stage this hunk [y/n/a/d/s/e/?]? y
としても結局1つ分の変更点をaddしているわけだから、わざわざpオプションを付けている意味がない・・・
その後のgit commit
2010年4月2日
いよいよ、歴史を振り返る、書き換えるというバージョン管理ならでは?の機能に突入
gitに限らず、こういうバージョン管理している醍醐味って、
「過去のxxやっぱ取りやめたいから、修正しといて」
みたいない時にサクっと作業が出来ることなのかもしれない。
まず、過去の変更履歴の検索については
・git log
・git log --grep=
・git blame
で探すやり方とあるみたい。最初のgit logはこれまでも何度か使っていたからそれほど難しくないし、grepオプションをつけるやり方もそんなに違和感はない。
で、最後のgit blameっていうのが、自分的にはちょっとした感動。
例えば
^988aae7 (xxxx 2010-03-31 07:34:17 +0900 1) <html> ^988aae7 (xxxx 2010-03-31 07:34:17 +0900 2) <head> 6c800ef2 (xxxx 2010-04-02 07:28:44 +0900 3) <<<<<<< HEAD:index.html dee53b14 (xxxx 2010-04-01 07:38:27 +0900 4) <title> dee53b14 (xxxx 2010-04-01 07:38:27 +0900 5) <meta name= fd00c4fb (xxxx 2010-04-01 08:02:30 +0900 6) <meta name= 96a63000 (xxxx 2010-04-01 07:51:16 +0900 7) <link rel=" ^988aae7 (xxxx 2010-03-31 07:34:17 +0900 8) </head> dee53b14 (xxxx 2010-04-01 07:38:27 +0900 9) <body> fd00c4fb (xxxx 2010-04-01 08:02:30 +0900 10) <h1><E3> dee53b14 (xxxx 2010-04-01 07:38:27 +0900 11) <p> fd00c4fb (xxxx 2010-04-01 08:02:30 +0900 12) <p> dee53b14 (xxxx 2010-04-01 07:38:27 +0900 13) <ul> dee53b14 (xxxx 2010-04-01 07:38:27 +0900 14) <li> dee53b14 (xxxx 2010-04-01 07:38:27 +0900 15) <li> 51716cc9 (xxxx 2010-04-02 07:34:58 +0900 16) <li> dee53b14 (xxxx 2010-04-01 07:38:27 +0900 17) <li> dee53b14 (xxxx 2010-04-01 07:38:27 +0900 18) </ul> dee53b14 (xxxx 2010-04-01 07:38:27 +0900 19) <p>tel:06-6415-xxxxx</p dee53b14 (xxxx 2010-04-01 07:38:27 +0900 20) </body> 6c800ef2 (xxxx 2010-04-02 07:28:44 +0900 21) ^988aae7 (xxxx 2010-03-31 07:34:17 +0900 22) </html>
という感じで、対象となるHTMLファイルの各行がどのコミットの分なのかが表示されて、これ見た瞬間
「githubでたしか見たやつだー」
と単純に感動した。githubが元々gitの機能をホストしているから当たり前なんだろうけどね
3種類のやり方で過去の変更履歴を検索したら、実際に変更を取り消す作業としては
git revert
をつかうみたいで
git revert 51716cc9
とすると、エディタが立ち上がるので、何故、それを取り消したのか理由を書いて保存したら、なんと16行目の