40歳からのキャリアチェンジ

20代はエンジニア・PM、30代はWeb系エンジニア向けのキャリアアドバイザー。40代の今はフリーランスで開発含めて色々やってます。技術ネタとしてはRuby/RailsとJavaScript関連あたり

Git入門

ここ数日、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 については、指定のファイルをcommitするというので理解しやすかったので、pオプションの所だけ再度勉強というか調べ直す必要ありそう。

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行目の

  • から始まる記述の部分の取り消しが出来た! スゲー
    WEB+DB PRESS Vol.50
    WEB+DB PRESS Vol.50
    posted with amazlet at 10.04.02
    WEB+DB PRESS編集部
    技術評論社
    売り上げランキング: 27688
    おすすめ度の平均: 4.5
    5 gitとWebKit
    4 森田創特集(?)
    5 perl, PHP, SQL