こんにちわ、スワンです。
さて、今回はGitとデザイナーの話。
ぎっとぎっとってWEBに関わってる方なら一度は聞いたことがある単語だと思います。
こんな感じの猫のような凧のようなキャラクターもエンジニアさんがPCにシール貼ってたりパーカー着てたりするので意外と馴染みはあるこいつ。
そしてみんな身に覚えのある、現場でよく耳にする言葉たち。
「レビューお願いします( 'ω')」
「マージしました( ੭˙꒳ ˙ )੭」
「プルリク溜まってきたぞー」
「ブランチ切りますねー」
入社したときから一体何の話してるんだろうなぁ…( 'ω')?
とエンジニアの会話に耳を傾けていたものの一向にわからないまま時間ばかりが過ぎました。ところが今関わっているプロジェクトでとあるデータをデザイナーとエンジニア共通でgitでデータを管理することになりました（正確に言うとgheなのですがここでは伏せておきます）
「こ、これが噂のぎっとかあ…」と恐る恐る触ってみたもののよくわからず。
試しに繋いでみてもエラーが出てきてパニック…！で解決方法もちんぷんかんだし、度々エンジニアさんに聞きに行ったりして（これがまた時間を取らせてしまい申し訳ない気持ちに…）「ココ押してココにコメント書いてこのボタン押したら更新されるよ！」って手順だけ教えていただいたり行き当たりばったりの日々でした。
でもGitってそもそもなんなのか？ってのをすっ飛ばしてるので何を聞いても理解が深まるはずもなく。そしてエラーが起きるたびにビクビクするのがいよいよ嫌になり
「分からないことほどストレスなことはない」
ということで思い切って、ちゃんと使い方とか全部勉強しちゃおうってことにしました。
ひとまず良さげな本をamazonでポチり
全部ググっても良かったんですが、gitはエンジニアライクなサービスであるせいかそもそもの話を丁寧に解説されていることが少なくデザイナーからするとなんのことやら…って記事やまとめが多かったので無知でも分かりそうな入門書を買うことにしました。（そして後日に著者の方を知ってビビる）
一通り読んで、実際に使っていじり倒したら「なんだ、Git怖くないじゃん超便利！！！」ってなったので是非みんなに知って欲しいなあと思いざっくりまとめてみようと思います。
そもそもGitって何？
Git(ギット)とは、プログラムソースなどの変更履歴を管理する分散型のバージョン管理システムのことです。簡単に言うと更新したデータの差分をログとして保存してくれて、それらをバージョンという単位で保存・管理していつでも取り出せる仕組みです。
GitとGithubの違い
そもそもごっちゃになってることが多いのですが、GitとGithubは違うものです。
Gitは先にも述べたようにそういう「システムの名称」です。そしてGitHub(ギットハブ)とはGitHub社という会社によって運営されているGitの仕組みを利用したウェブサービスです。例えるならこんな感じ↓
Git = チャットと通話ができる機能
Github = Skype（スカイプ）
「チャットや通話」という仕組みを利用して使い易いサービスとして提供している「スカイプ」のような関係（言ってみたはいいが余計わかりにくいか…笑）
さらに先ほど冒頭でも出てきたGHE（GitHub Enterprise）というものもありますが、これはGithubをクローズドに使用するための有料エンタープライズ版のGitのことです。
Gitを克服して良かったこと
非エンジニアでもGit使えるとメリットいっぱいでした、怖がってると何事も損ですね。
デザインもバージョン管理の方が便利
昔の話をするならデザインデータに日付で連番降って外付けHDDで管理したり（今思えば相当なデータ量の無駄）バックアップと名付けたフォルダにコピーしたファイルをいくつも突っ込んだりととにかく分かりにくくて無駄の多いデータ管理になりがちなデザインデータ。ですがGitに管理を集約したら管理の面でのコストが大幅ダウン。HDDの圧迫も減って嬉しい。もともとコード管理に特化してるサービスなので、まだまだ大きいデータをGit上で扱うにはちょっと手間が必要ですし、データの中まで差分取ってくれないので共同作業する場合は注意が必要ですがそれを凌ぐメリットの大きさです。
コミュニケーションコストが下がる
なにより専門性の違う職種同士が同じツールを使えるというのはコミュニケーションコストが圧倒的に下がります。直接データをzipで送る不毛さは誰しもが経験しているはずです（そしてどれが正解なのかわからなくなる）
コミットの履歴を追えば最新はどれか今どの段階なのか一目瞭然だし、エンジニアさんにお願いしなくてもこちらも自分で最新データとってこれる。
プロダクトや技術への関心が上がる
Gitを克服してからいろんなことに関心が高まりました。例えば自分の場合は担当しているサービスのプロジェクトをローカルに落としてきて、中をチラチラ覗き見しているうちにアプリの作り方が気になってまさにいまSwiftの勉強中だったり。やっとこの頃、細かい修正とかエンジニアさんに直接プルリク送れるようになって、よりプロダクトが自分ごと化できて愛が強まります。あとは巷のライブラリとかプラグインをとってきて覗く楽しみも増えました（これまた勉強になる）
あと逆にデザインデータ(Sketch)もGitで管理することにしてから、作りかけのUIもガンガン更新していくことで自然とエンジニアさんがチラ見してくれてコミュニケーションも増えたと思います。
初心者はGUIから始めてみよう
メリットを挙げた上で、その次に立ちはだかる壁は恐怖の黒い画面だと思います（笑）
gitについて調べるとコマンドの嵐が襲ってきます、ここで半分くらいのデザイナーが尻込みします…（笑）なので黒い画面になれるのも大事だけどいったんそいつにはいったん勘弁してもらって、親しみやすいGUIから使いましょう。ちなみに私はGitをSourcetreeというGUIツールを使用してます。最近は黒い画面も使い始めたけど、最初に使うものとしては何の処理が起きてるのか不明瞭過ぎてパニクるのでそれで諦めちゃうくらいなら別に画面黒くなくてもいいじゃない。
とっかかりとしては何でもいいと思うので各々で怖くないわかりやすい奴を選びましょう。そのあとに黒い画面でもなんでも最適なやつを覚えればいいともう。
おまけ：たぶんデザイナーが躓きやすいポイント
さくっと本を読んでなるほど！と思ったのですがいざ使ってみると？？？となりやすい（実際に自分もなった、笑）部分をおまけ程度にご紹介します。
1.ローカルとは
デザイナー「最新のデザインデータをコミットしときましたー」
エンジニア「ありがとー…ってあれ、更新されてないよ？まだローカル？」
デザイナー「え、ローカルをコミットしましたよ？？？」
エンジニア「…コミットをプッシュしないと反映されないよ」
デザイナー「え…？」
めちゃくちゃ当たり前なんだけどこんな感じで最初に意外と躓く。そもそもデザイナーの作業で特にこの概念があまり使われることが少ないせいもあると思いますが特にややこしかったのは"ローカル"という領域。
勘違いしやすいポイントは手元のデータとローカルは別物ってことです。
手元のデータ ≠ ローカル
ローカル ＝ gitにコミットしたの状態のデータ情報
sketchとかphotoshopで目の前でリアルタイムでいじっているデザインデータはその時点ではgitには反映されていません。その変更をGitにコミットして初めてローカルに反映されます。パソコンの手元にあるものを"ローカル"と同じ呼び名で指すことが多いので勘違いしやすいですが全く別物です、気をつけましょう。
2.コミットとプッシュの影響範囲
1の会話の続きで、コミットとプッシュの違いと影響範囲について。
コミット（commit）
準備段階のようなもの、自分の環境下だけの整理・変更がバージョンとして保存されている状態。クローズドなので他人はまだ見れない。
プッシュ（push）
ローカルのコミットの履歴をリモートへ反映させること。プッシュして初めて他の人に変更や履歴を共有できる。
要は、Gitは２段階のアクションを経て他人へ共有するシステムってことです。
この２つのポイントを図にするとこんな感じ↓
手元で作業 → ①ローカルへコミット → ②リモートへプッシュ
この３ん段階が基本の流れです。コミットとプッシュがごちゃ混ぜの認識の人が多い（どちらか一方で完了だと思い込むことが多い）ので気をつけましょう。
さらに余談ですが、Gitより先にsvn使ってるとコミットが直接リモートへ反映されるアクションなので適用範囲を勘違いしやすいのでさらに注意です。
実はこの記事を書きだしたのが３ヶ月前だったのですが（笑）
Gitがしどろもどろだった自分も現在はガンガン仕事でもプライベートでも使いまくってます。まじ便利。
非エンジニアにススメたいのは、とにかく怖がらず自分だけのレポジトリを作ってガンガンコミットしてみたりとにかく手を動かして一通りのをやってみること。既存のレポジトリとかだと流石に事故る場合もあるので（笑）他人に迷惑かけずに実験しまくると理解が圧倒的に早いです。
ブランチ切りまくってしまくってコミットしまくり！セルフマージからのセルフコンフリクトさせてセルフ解消！さらにローカルの履歴を取り消してみたり。。。と、とにかく何でもいいからやったほうがいいですマジで。ということで
Git全然怖くないヨ( ᐛ )
食わず嫌いはもったいない。
ではまた( 'ω')
0コメント