はじめに

こんにちは！nanapiデザイナーのyunicoです！「Git Advent Calendar 2014」の15日目を担当します（^o^）
今年はなんか色々GitGit言っていた年だったので、最後にアドベントカレンダーに参加しちゃいます！わいわい！去年からすると、まさか一年後にGitのアドベントカレンダーに参加しているとは思いもよりませんでした〜。感慨深いものです！よろしくお願いします＜(_ _)＞

前置きと今年やったことまとめ

TechBlogでGitについて書いた
nanapi勉強会でTL
GithubKaigiでTL
PatchworkTokyoでメンター&LT

Gitが大好きになった♡というブログを書いたら色々ご縁があり、3回ほど登壇しました(╹◡╹)
nanapi勉強会vol.2では「 GUIじゃなくてターミナルからコマンドでGit使うと便利！」という話、GithubKaigiでは「 Gitの概念の覚え方として郵便局を例えに使った郵便局メソッド」の話、 Patchwork TokyoではLTとワークショップのメンターをやらせていただきました。
色んな方と知り合えたりとか楽しいイベントに誘って頂けたりしたので、実際に使いこなせているかどうかは置いといて、面白そうなものには面白い！とか好きかも！とか言ってた方がいいな〜と思う今日この頃です。

本題：こうやって覚えてGitが大好きになったよ

さて本題。
「デザイナーさんだとGitはなかなかとっつきにくかったのではないですか？」とか「どうやって勉強したんですか？」とか聞かれることが多いので、今回は「どうやってGitを覚えた・好きになったか」について書きたいと思います！
これから勉強しようかな？って思ってる方、逆にお仕事のパートナーであるデザイナーにGit覚えてほしいなあ〜って思ってる人とかの参考になるとうれしいです（^o^）

その１：いきなりさわる！

nanapiでもGit導入しま〜す！となって、社内でGit勉強会がありました。勉強会というよりワークショップ？かな？もちろん先生は@kozyty。
まずはしのごの言わず、@kozytyの指示に従いGithubからリポジトリをcloneしてきて、みんなでひとつのファイルを自分のPCから更新したりしてみます。ファイルと内容はなんか適当です。たしかただのテキストファイルにうんこうんことか書いただけだったと思います。更新したら言われた通りにターミナルから「git add」と「git commit」と「git push」のコマンドを打ちpushします。今度は隣の人が@kozytyに言われた通り「git pull」して、わたしがpushしたファイルに「Hello World!」と付け加えます。それをpushし終わると隣の人の書いた「Hello World!」とわたしの書いた「うんこうんこ」が一緒になっている…！という具合でGitを触ったことがない人たちが集まり、いきなりみんなでひとつのファイルを触ります。
なるほど、Gitとはこういう風に複数人で同じものを編集するときに使うんだな〜！上書きをしてしまうとかもなく、しかも誰がどう更新したかの更新状況もわかる。バージョン管理便利〜！というのをまず体験。今度はみんなで同じ箇所を編集。またpush。当然コンフリクトが発生。こういうときもあるんだね〜とlogを見てみたりとか。
最初から超簡易的にでも本来の使い方のように何名かで実際に触ってみると、Gitがどういうもので何をしてくれてどういうところが便利なのか、が非常によくわかる。いきなりコマンドでしたが、まずは動きを知ろう〜！っていうのが目的、と事前に説明があったので、そこはあまり気にならなかったです。わからないまま触るのは怖い、と思っていたけど実はそこが一番近道だった、という感じ。

その２：置き換えて考えてみる！

何をしてくれてどう便利かはわかったけど、更新したファイルを保存して、そのままリポジトリにpushすればいいんじゃないの？どうしてわざわざadd したあとにcommitしてpushするの？みたいな疑問がいろいろ出てくる。わたしは何度もいきなりpushしてしまい、なかなかadd とcommitに慣れず。ステージングというものがよくわからない…！
そんなときに理解を助けてくれたのが「封筒メソッド（後の郵便局メソッド）」。ファイルを編集＝手紙を書く、に置き換え、まずはその手紙を封筒に入れ（git add）、封筒に入れたら今度はその封筒の封をする（git commit）、というもの。これはわかりやすい！確かに、手紙を出すのに書いた便せんを封筒にも入れずいきなり郵便局に持って行っても受け取ってもらえないよなあ(･∀･；)
意外とGitって郵便、とか手紙のあれこれに例えられるんじゃない？と深堀して作っていったのが「郵便局メソッド」。アホなのでビジュアルでイメージを掴めないと理解できないんですよねえ、、
初めて触る人から、なるほど！と言ってもらえたり、Github本社の方にもわかりやすい〜！と気に入っていただけたりしてうれしかったです！調子に乗って一枚絵にもしてみました（^o^）

※ あくまで「わかりやすい例え」なので概念の説明として正確かどうかはまた別の話…

↓中国語verもあるよ！

その３：GUIつかわない！

よっしゃー便利！と実際業務で使い始めてみてもやっぱり最初はいろんなエラーやトラブルが起きまくります。その度にエンジニアに助けてもらうことになるのですが、当時わたしはMacではなくWindowsだったのでTortoiseGitというクライアントからGitを使っていたのですよね亀。
エラー発生→エンジニアに聞く→エンジニアの人普段ツール使わないからTortoiseGitの使い方よくわからない→結局ターミナル開いてそこから解決→なんか解決してもらったからいいや→また同じエラー発生→TortoiseGitでの直し方結局わからないからまたエンジニアに聞く→TortoiseGitの使い方（以下略）みたいなことが起こりまくって、もはやコマンドで覚えた方がいいのでは…みたいになり結局コマンドで覚え直しました。

しかしこれが大正解！まずコマンド操作だとエンジニアとのコミュニケーションコストが圧倒的に少なく済む。一番はこれ！お互いストレスが少なくて済むのは良いことです。
あとは「黒い画面を使いこなせてる感」が気持ちいいのでもっとコマンド覚えたい！みたいな謎のモチベーションがUP。コミットコメントviで書いちゃうもんね！的な。（普段はSublimeText）

来年がんばりたいこと

もっと理解を深めたい

自分ではそこそこ分かってるんじゃねーの？と思っていたのに、10月のGithubのイベントでメンターをやってみたら、実は！全然！分かっていなかった！ことに思い知らされた！だから答えられないこともいっぱい…！逆に聞いちゃったりして本当におまえはメンターか…？レベルで死にたくなりました。それに加えて今回Gitアドベントカレンダーに登録してみたらまだまだ知らないことがマジでいっぱい…！
自分が業務で普通に使えてるだけでニコニコしてたらあっという間に置いてきぼりになってしまうこの業界のスピードの速さ。Gitはただのツールだけれど、せっかく好きになってたのしー！と思えたのだから、もっともっといっぱい使って、新たなトラブルにも出会って理解を深めていきたいなあと思っている所存であります。

チームにとって最善の使い方を模索

それまではプロジェクトのgitの使い方については、特に意志も持たずエンジニア任せになっていたというのが正直なところですが、小さなチームなので最良の選択をするために自分も知識を増やして提案や相談ができるようになりたいなあと思うようになりました。
branch切るタイミング、masterにmergeしたあとはbranch残す？tagにする？commitとpushの頻度はどーする？コミットコメントのルールは？など積極的に提案したりしていきたいです。それにはまずやっぱり理解を深めないとナ…！

おわりに

nanapiはみんな、わからないことがあって聞いたりするとめちゃくちゃ丁寧に教えてくれます。中でもGitはしょーもないエラーから、全く見たこともないエラーの対処まで、CTOを含めたエンジニアの皆さんに教えてもらいまくりました。みんな嫌な顔ひとつせず、作業の手を止めてでも教えてくれて、その度に「ちゃんと恩返しをしていこう…」と密かにずっと思っていました。
運良くGithubKaigiで話す機会が得られたので、LTのとき、弊社エンジニアたちが聞いてくれている前で「こういうLTできたのも弊社エンジニアのおかげ！」と言うことができてちょっとよかったです。Gitって自分ひとりのためのものっていうより、みんなが便利に開発できるよね〜っていうところに使う醍醐味があると思うので、学習コストはまああるとは思いますが、できるようになったらエンジニアもデザイナーもみーんなハッピーになれる！ヨ！

新しい技術がバンバン出てくるこの業界ですが、教えてくれる人に感謝を忘れず、日々新しいことにチャレンジしていきたいなあ、と思っています。来年もがんばるぞ！

おわり☆