日々常々

ふつうのプログラマがあたりまえにしたいこと。

Developer's Test 勉強会 第3回 のメモ #devst

1/14 の第3回devstは特別編として、SCMBCとのコラボ企画になりました。
第2回勉強会でGitHubを使用して共同作業を行おうとした際、色々あって、「まずGitを固めた方がいいんじゃね?」と思いました。devstは手を動かして現場で実践する技術を身につける勉強会です。そしてDVCSのハンズオンによる習得と言えばSCMBC。なので前回の懇親会のときにSCMBCを紹介して、それから色々あって、今回こういう形に。

時系列で書いていきます。

演習1

まず全員の環境を確認。Gitが使えること、GitHubが使えることを各々でポジションペーパーを書いて貰うことで確認しようと思いました。
ハンズオンで一番ネックに鳴るのは、各々の環境にどんなトラブルが潜んでいるか読めないことです。30人弱の参加者がいるとどうなるか正直わかりませんでしたが、皆さん準備してきてくださってたので、きっちり詰めてなかったせいで私がグダグダした以外は特に問題なく済んだと思います。

講演

@bleis さんにSCMBC第2回のをベースに、Gitの考え方の講演をしていただけました。
Gitは…

オブジェクトを理解し、
ブランチの考え方を理解し、
コミットグラフを頭に思い浮かべることができれば勝てる

SCMBC Git入門セッション発表資料

とのことらしいです。
操作しながら頭の中でコミットグラフを描いて、それを gitk や GitHub のグラフと突き合わせる。そうすることでGitは一気に理解出来ます。出来てるつもりです。出来てればいいなぁ。

演習2

課題もSCMBCと同じく、Gitのチートシート作成です。Gitのコマンドを調べながら使いながら出来る一石二鳥な感じ。
まずは同じリポジトリの同じブランチに push していく形で行います。push は、された側のブランチが fast-forward merge 出来るときしか受け入れられません。もっと簡単に言うと、誰かが push したら、他の人の push は reject されます。解決方法はいくつかありますが、まず今回は pull することでリモートのブランチをローカルのブランチに merge します。merge されれば fast-forward merge 出来るようになるので、push できるようになります。
文字で書いても分かりづらいのですが、とにかく他の人の commit を merge しながら進めていくって感じに鳴ります。同じリポジトリを使うために GitHub の Collaborators を使用します。ここに GitHub のアカウント名を入れると、その人が push 出来るようになります。

  • (ファイルを編集)
  • git add .
  • git commit -m'msg'
  • git push
    • (reject された場合のみ)
    • git pull
    • git push

演習3

一区切り入れて、ここから トピックブランチと rebase の演習になります。正直トピックブランチは私のいたテーブルでは上手く使えませんでした…ぐぬぬ。rebase で嬉しいことは、履歴が一本化できることらしいです。
演習2でやった内容では実際に加えた変更の commit と pull したときに行われる merge の commit が入り乱れて、コミットメッセージを見ないとどのコミットが重要か分かりづらいです。さらに親が複数になるために追いづらいというのもあります。

  • (ファイルを編集)
  • git add .
  • git commit -m'msg'
  • git pull--rebase
    • (競合が発生した場合のみ)
    • (競合したファイルを編集)
    • git add .
    • git rebase --continue
    • (完了するまで繰り返し)
  • git push


演習2と演習3で作られるコミットグラフは、実際やってみると明らかにかわってて面白いです。merge も rebase も使いどころ次第だと思うので、状況に合わせた方を選択出来るようになればいいと思います。機械的に作られるマージコミットはあまり価値はない気もしますが、競合したときとかには重要なのかもしれません。

感想

SCMBCは第1回にMercurialで参加しました。今回はGit限定での企画で、かつサポーターもSCMBCのように揃えるなんてのも無理な話だったので、せめて言い出しっぺだしある程度使えるようになっとこうと、前日まで必死にGitの勉強してました。勉強会駆動ですね。
実際のところ、コマンドとか使い方なんてのは一人でもやってれば覚えられるのですが、人に説明する段階になってやっと気づけることも沢山あるなーと改めて思いました。devstの目的の一つは「習得した技術を現場に展開出来るようになること」だったりもするので、これは非常に貴重な経験。特にGitを使わない状態でイメージする言葉と、Gitの言葉のズレを所々で感じたので、この辺りをきっちり整理できれば説明しやすくなるのかな、なんて思ったり。


コミットグラフはけっこう面白いことになってます。
https://github.com/devst/devst_honmachi/network

Gitはどの本がいいの?

Git本はいくつか出ていますが、評価がまちまちでおもしろ…どれを買ったらいいかよくわからない状況になっています。なのでその辺を聞いてみたのをぼんやりと書いておきます。何かの参考になれば。

実用Git

実用Git

私が買ったのです。感想はブクログにも書いているのですが、この本だけで勉強するのはちょっと厳しいんじゃないかと思いました。SCMBCで話を聞いたり、叩いたりしつつ、なんとか。理解出来るようになってくれば「あそこに書いてたのはああいうことか、なるほど…」ってなるんですけども。


入門Git

入門Git

「大文字の方」とか言われてます。読んでないので聞いた話になります。
Amazonなどでは低評価ですが、TLや勉強会では高評価の一冊。なぜそんなことになるのかというと、Gitの入門であってGitの使い方には入門ではない…とのこと。


入門git

入門git

「小文字の方」とか言われてます。これも読んでないので(略)
Amazonなどでは高評価ですが(略)どちらかというと使い方ベースなんでしょう。けれどもこれを買うなら、次の「Gitによるバージョン管理」がいい気がしてます。


Gitによるバージョン管理

Gitによるバージョン管理

この4冊の中では一番新しい本ですね。これも読んで(略)
Gitを使い方を軸に説明されている感じで、迷子にはならないと思います。弱点はコマンドのリファレンスとしては使いづらいことと、これに書かれている使い方しか出来なくなるかもしれない…とのこと。


今から買うなら 入門Git(大文字の方) でしょうかねー。