今こそデザイナーもGitと向き合う時代

デザイナーの皆さんこんにちは、フロントエンドエンジニアしてます石橋です。

今やGitは開発のスタンダードですが、未だデザイナーには浸透しきっていない現実があります。
しかしHTMLなどのコードを触る以上、デザイナーであってもGitを覚えてしまえば効率的な業務遂行がきっと出来るはず！私はそう信じてます！

今回はそんな「覚えてみたいけどよーわからん」デザイナーに向けて、１記事書いてみたいと思います。

メリットを知る

まずはGitを使うことで何が良いのか？を理解することが大事です。
ここがわからないまま学んでも、ただ面倒な作業が増えるだけでいずれ元に戻るのは想像に難しくありません。

ファイルの巻き戻し

図のようにファイルをコピーしてやりくりをしている人がいるかもしれません。

時代遅れだ！

こんなことをする原因は、あとからロールバックが出来ないことにあります。
Gitならコピーを残しておかなくてもファイルそのものを以前の状態に簡単に戻せます！
革命だ革命！

変更点の共有

はい、面倒ですね。

Git（というかGitHubのようなホスティングサービス）を使えば、ファイルの送受信も不要ですし、変更点もコードベースでやり取りが出来るようになります。
これも革命だ革命！！

並行作業からの合体

自分の知らないところでAさんが同じファイルを触っていた。
Aさんは何もしらずに上書き保存ボタンを押してしまった（！）

「あ”ーーーー（絶望）」

こんな悪しき思い出もGitがあればチョチョイのチョイです。
前述のようにファイルの巻き戻しも出来ますが、もともとGitには並行作業を効率的にする方法があるんです。
同じファイルを仮想的に別のものとして編集していって、あとからその２つをなんかこう…うまい感じで合体してくれる超絶機能が備わっています。
もはや革命以外の何者でもありません！！

仕組みを知る

さてそんな革命的なことが出来ると知ったら、デザイナーのあなたも是非使ってみたいと思いませんか？
じゃあさっそく触って……の前に、どうしてそんな魔法みたいなことが出来るのかを知ってからでも遅くはありませんよ。

ファイルの変更履歴を保存している

Gitに限らずSubversionやCVSといったバージョン管理システムは、「いつ」「誰が」「何を変更したか」を記録してくれます。

勘の良い人はもうわかりましたか？

そうです、いつでもその記録を辿って戻ることが出来るんです。 先ほどのやりとりでも、エンジニアさんにこの記録を見せてあげるだけで変更点も一目瞭然ですね。

専用の場所で作業できる

Gitは自分用の作業場（ブランチと言います）をつくって、そこで作業ができます。 つまり触るファイルは同じだけど、触ってる環境は全然違うんです。

当たり前な話ですが、FTPでファイルをダウンロードして、ローカルで編集してもサーバー上のファイルには変更がかかりませんよね。
それと同じで、別のブランチで作業していれば他にはまったく影響が無いんです。

そこでダダダーっと手を加えてから、みんなの共用の場所にまるっと合体（merge）することが出来ます。

そのmergeのタイミングで、もし同じ箇所に対して別の人が変更を加えていたら、Gitが「あ、衝突してるんで確認してもらっていいですか」って言ってくれます。
Gitっていい奴です。

GUIで触る

Gitへの恐怖感はやっぱりあの真っ黒なアイツが一端を担っていると思います。
でも今の時代はもっとわかりやすいソフトがあるので安心してください。

Windows と Mac に対応した Mercurial/Git 無料クライアント | Atlassian

これはGUIベースで簡単にGitが使えるソフトです。
まずはここから入るのがオススメです。
ソフト自体の詳しい使い方は、細かく説明しているページがたくさんあるので是非そちらを参考にしてください。

複数人で１つのファイルを更新していこう

使い方を覚えるにはテキストファイルを１つ作るところから始めるのがお手軽だと思います。
友達と計画している旅行メモでもいいし、好きなインディーズバンドの新曲の歌詞でもいいです。

まず始める手順はこれだけ

これでテキストファイルがGit管理されました。
友達も同じファイルが見たい場合、リポジトリのURLを教えてあげるだけでOK！

友達「例の旅行メモ、良いスポット見つけたから行き先足しておいたよー」
ファイルに変更がありました！これを自分の環境にも反映しましょう。

はいこれだけです。

これで旅行メモが友達が編集したものに更新されました。


ここからさらに自分で追加編集がしたい場合は、またこちらからadd＋pushをすればOKです。
このようにお互いにpushとpullをしあって開発を進めていきます。
友達が２日目分の旅行メモ（新規ファイル）を追加していた場合も、pullするだけで一緒に持ってきてくれます。

いざ本格活用！

さて今度は実際の業務に、この仕組みを持ってきてみましょう。

問題発生

少しコーディングが出来るデザイナーAさんが、頑張ってJSファイルmain.jsを作りました。
これを前段のとおりにリポジトリを作って設置しました。
その後処理を少し書き換えてやる必要があったので、main.jsに手を加えてpushしておきました。

ところが開発を進めていくうちによくわからない不具合を見つけたので、とても優秀なエンジニアのBさんに助けてもらうことにしました。

他の人が触る

BさんはリポジトリのURLを教えてもらい、最新のソースをcloneしてローカル環境で確認しました。
調査したところ、簡単な分岐処理の修正をすれば直りそうです。
ここでBさんは自分用のブランチを作ってmain.jsを修正し、pushしました。
その後問題なさそうだったのでmain.jsをmergeしておきました。

問題解決

Bさんから修正した連絡をもらい、Aさんはすぐにリポジトリをpullして再度確認をしてみます。
素敵！直ってる！ありがとうBさん！

どうでしょうか？なんだかとっても効率化されたやり取りに見えませんか？
実際この事例でかかったコミュニケーションコストは

• AさんがBさんに不具合を知らせる
• リポジトリのURLを共有
• 修正が完了した連絡
• Bさんへのお礼

これだけです。

必要最低限のコストは開発のスピードアップに直結します。
さらにキモなのはGitを使っていることにより、この修正対応がいつ行われたか、誰が対応したか、どんな内容だったのかがログとして残ります。
もしも１ヶ月後に同じ箇所で不具合が出たとしても、迅速且つ正確な対応ができますね。

もう１つの利点は、Bさんは別ブランチで対応しているので、並行してAさんも作業を進めることが出来ます。

まとめ

Gitへの抵抗を減らすためにだいぶ端折って説明しましたが、使うことで何が起こるのかを中心にまとめてみました。
何はともあれ勇気を持って触ってみないことには始まりません！

Gitはミスを許容してくれる素敵なシステムだと思います。

失敗は成功の素。