はじめに

こんにちは。 Zaim で iOS エンジニアをしている @akatsuki174 です。

「デザイナーも git を使えた方がいいよ」

こんな言葉を一回くらい言われたことがあるんじゃないでしょうか。とはいえ git もなかなかとっつきにくいところがあると思います。そこで、比較的デザイナーに馴染みのある（と思われる）バージョン管理サービスである「Abstract」を例に取りつつ git の使い方を紹介しようと思います。

ちなみに一記事で終わらせようとしたんですが無理でした。 git 奥ゆかしい。ということで今回は git の基礎について、次回は実際に Abstract 上での git の操作方法について説明します。

バージョン管理ツールを使うメリット

そもそも（git に限らず）バージョン管理ツールを使うメリットが分からないと、わざわざ小難しいものを学ぶ気にならないと思います。そこで、まずはメリットについて説明しようと思います。

どれが最新版か見分けやすい

こんなフォルダ / ファイル群を見たことはないでしょうか？

icon_20181215
icon_20181215_2
icon_20181215_修正版
icon_20181215_最新
icon_20181215_最新（1）
icon_20181215_最新（1） のコピー

発狂モノですね（ ＾ν＾）（ ＾ν＾）（ ＾ν＾）

さて、どれが一番新しいものでしょうか？（考えたくない）

ファイルの更新日付を確認すれば分かると思いますが、ひと目で分からない名前なんて付けるもんじゃないですし、そもそも無駄なファイルがいっぱいできてエコロジーじゃありません。

git の場合、以下のようにキリのいいタイミングでコミット（後述）すれば、変更履歴を残せます。

これによって、どれが新しいのかすぐ分かるようになっています。

変更の合体がしやすい

こんな場面があったとします。

A さんは B さんが変更したということを知らなければ、B さんの変更分を反映しないまま本番にアップしてしまうことになります。デグレ（品質悪化）の瞬間です。 git のブランチ（後述）を使って、最終的に変更点を一つにまとめるようにしておくと、デグレが発生しにくくなります。

以前の状態に戻しやすい

「さっきリリースしたバージョンが、バグを引き起こしているらしい。どうやらこの変更がまずかったみたいだ」という時に、その部分だけ元の状態に戻すということがしやすいです。先述の日付名ファイルでの管理だったら、どの時点から直せばいいのか判断するのも一苦労、下手をすれば戻し漏れが発生してしまいます。

変更履歴をすべて残せる

誰がどんな変更をいつ行ったのかが残せます。メッセージも付け加えられるので、どんな意図で変更したのかを書いておくことも可能です。

git の基本用語

エンジニアが使う git 用語はもっとたくさんあるのですが、 Abstract 上では最低限、以下の用語を覚えておけば大丈夫そうです。

ブランチ

ほぼその言葉通りで、枝葉のことを指します。

一人は新規画面のデザイン作成、一人は既存画面のデザイン修正というように、最終的には同じプロジェクトに統合するものの、別々に作業したい時に活用します。ブランチを使うことで、自分の作業が他者に悪影響を与えてしまうことを回避できます。

安定版として本流ブランチ（master という名前の場合が多い）を基準としつつ、作業ごとにブランチを作って、最後は一つのブランチにまとめるというのが主流の使い方です。

コミット

ある程度、まとまった単位でデザインを変更したら「コミット」という記録作業をします。ゲームでデータをセーブするイメージです（しかし最近のゲームでは、もしかしてセーブの概念がない…？）。

コミットをする粒度に関しては諸説あるため、チームでの合意形成が必要になると思います。基本的には「あ、戻したいな」と思った時にすっきり戻せるよう、変更した内容を一言で表しきれるくらいが良いと思います。

ちなみにコミットするタイミングでコメントを付けておくことが可能です。ぜひ、分わかりやすいコメントを残しておいてください。変えた箇所は差分を見れば分かるので、「仕様変更のため」や「他画面との整合性を取るため」といったように、変えた理由を中心に書いておくと良いです。

マージ

自分の変更を、別のブランチ（本流のブランチなど）に統合する作業のことを指します。

レビュー

変更した箇所が、要件を満たしているか、余計なものを含んでいないかをチェックし、別ブランチにマージしていいかどうかを第三者に判断してもらう作業のことを言います。言葉通りですね。エンジニア界隈では Pull Request、Merge Request という言葉を使ったりします。

コンフリクト

別ブランチで似たような箇所を変更していた場合、マージしようとした時にシステム側が混乱して自動でマージできない状態になることがあります。これがコンフリクトです。

機械で判定できないとなったら、あとは人間の目で判断するしかありません。地道に「こっちの変更を取り込んでおくれ」と指示を出します。

まとめ

git を使うと

・複数人でのデザイン作成時に困りにくくなる
・変更の軌跡を残せる

というメリットがあってハッピーになれます。

とはいえ実際に使ってみないとよく分かんないですよね。私もそう思います。ということで次回は Abstract を使って操作方法の確認、git のメリットのおさらいをしていこうかと思います。

P.S.

↓ポチッと、とりあえず踏んでみよう。

※3/7追記

後編はこちら。