昨今の開発では、git（バージョン管理）は切っても切れない存在で、
むしろ使っていないほうが珍しい、もはや常識のようなものなのだろうと思う。
（デザイナーでも使っている人は、今では増えてきているのかもしれない）

覚えたらきっと便利。
手放せなくなるくらい良いものだということは、頭ではわかっている。

......わかってはいるが、体が拒否反応を起こす。
そう、なぜならば──

ぶっちゃけ、あの黒い画面が怖い！

コマンドを叩くって何？
やだやだ！わかんないよ～！

......というのが、当時の正直な心の叫びだった。

加えて、忙しいことを理由に「おいおい......ね😅」と、
社内エンジニアからの「そろそろ覚えてくれ～」という圧からも、
うまいこと逃げ続けてきた私。
（新しいことを覚える心の余裕がなかった、というのも正直なところ）

そのうち......いずれは......
と思っていたら、ついにその時が来てしまった。

Webアプリケーションの大型開発である。

デザイナーの私は、デザインおよびコーディングを担当し、
フロントエンドエンジニアにファイルを受け渡す立場。
やはり取り扱うには、gitでのバージョン管理が必須だった。

そこで今回は、
gitやコマンド操作に苦手意識のあったデザイナーの私が、どのようにgitと向き合い、
最低限使えるようになったかの体験記をまとめてみた。

【目次】

• 制作環境の変更
• VSCodeを使って良かったこと
• gitで困ったこと　～用語がわからない～
• gitで困ったこと　～一番焦ったgit事件～
• gitで困ったこと　～PRの出し方編～（スクショで手順をメモして乗り切った話）
• 現在の私とgitの関係性

制作環境の変更

本題の前に、今回の開発では制作環境をがらっと一新した。
まずは、エディタをDreamweaverからVSCodeへ変更。

Dreamweaverにもgit機能がないわけではないが、
エンジニアの方々と開発環境を統一することで、
予期せぬトラブルを回避する目的があった。

Adobe CCを使っていることもあり、「せっかくならAdobe製品を使い倒そう」と
長いことDreamweaverを使い続けてきたが、VSCodeを試すには良い機会だったと思う。

VSCodeを使って良かったこと

• 動作がめっちゃ軽い！
• 複数のワークスペースを開ける
• とにかく軽い！
• 拡張機能が豊富で便利
• サクサク動く！

......いかにDreamweaverが重かったかを、身をもって実感した。
（起動が遅いし、よくフリーズするし......）

Dreamweaver特有のテンプレート機能なども使っていなかったため、
あとはSSIを使用しているサイトのプレビュー問題が解決できれば、
完全移行できるのでは？と思っている。


──閑話休題。
ここから本題のgitの話に入っていく。

gitで困ったこと　～用語がわからない～

gitには数々の専門用語が存在する。
最初はこの用語を理解するところからスタートした。

※以下は、gitを触り始めた当時の「自分なりの理解・解釈」の用語集です。

リポジトリ

最初に出てきた謎ワード。

「何か特別なもの」だと思っていたが、
gitで管理するための"作業フォルダ一式"
だと分かって、少し安心した。

ディレクトリとほぼ同義。
ただし、履歴がすべて記録される前提の箱、という認識。

ブランチ

一番イメージしづらかった言葉。

「なんでわざわざ分岐させるの？」
と思っていたが、
本線を汚さずに作業するための別ルート
と理解して、ようやく腑に落ちた。

「世界線を分ける」と言われて、
なるほど......？となった記憶がある。

コミット

「保存」とは違うらしい、という時点で混乱。

実際は、
作業の区切りを履歴として残すこと。

「どこまでやったらコミットしていいの？」
が、最初はまったく分からなかった。

ステージング

存在を知らずに、最初につまずいたポイント。

「コミットする前に、この変更を履歴に入れますよ、と指定する場所」
＝提出前の確認トレイ
くらいの認識で落ち着いた。

リモート／ローカル

なんとなく分かっているつもりで、 ちゃんと理解できていなかった言葉。

• ローカル：自分のPCの中
• リモート：みんなで共有している場所

自分の作業＝即共有されるわけではない
と分かってから、事故が減った。

プル／プッシュ／マージ／フェッチ

完全にカタカナ祭り。

最初は呪文にしか見えなかったが、

• プル：取り込む
• プッシュ：送る
• マージ：合体させる
• フェッチ：最新情報を見に行く

と、動詞として考えるようにしたら、少し楽になった。

プルリク（Pull Request）

「これ、いつ出すのが正解なの？」
という疑問をずっと抱えていた。

作業が一段落したので、
確認＆取り込みお願いします、という申請
だと理解してから、心理的ハードルが下がった。

Azure DevOps（Repos / Git）

gitそのものだと思っていたが、実は違った。

gitを使った開発をまとめて管理するための場所。

「ここは道具箱で、gitは中の道具」
という説明で、やっと理解できた。

.gitignore

事件のあとで存在の大切さを知ったファイル。

gitに管理させたくないファイルを指定するためのもの
だと後から知った。

先に知っていれば、
あんなに焦らずに済んだのに......という代表例。

gitで困ったこと　～一番焦ったgit事件～

VSCodeにも慣れてきた頃、
「毎回作業フォルダを開くのが面倒だな」「もっと効率よく作業したいな」
と思い、調べてみたところ、.code-workspace ファイルの存在を知った。

これを作成しておけば、
ファイルを開くだけで作業スペースが設定できる。
とても便利！

......と意気揚々としていたのだが、
作成タイミングが悪かったのか、
リモートファイルをプルした際にコンフリクトが発生したようで、
ローカルのファイルがすべて消え去ったように見えて、
本気で焦った。

結果的に、
.code-workspace など履歴として追跡しないファイルは
.gitignore に記載しておくことで、
gitのトラブルを防げると知った。

gitで困ったこと　～PRの出し方編～（スクショで手順をメモして乗り切った話）

PRの出し方には、細かいルールや手順があり、
頭では理解したつもりでも、いざ出そうとすると
「これで合っているんだっけ？」と毎回不安になる。

一度覚えてもすぐに忘れてしまい、
そのたびにエンジニアさんに
「すみません、PRのやり方教えてください......」

と聞くのも、さすがに忍びなくなり、
今回使用しているAzure DevOpsでのPRの手順を、
スクショを撮りながら自分用にメモすることにした。

• PRを出す手順
• セルフ承認のやり方
• マージ後にVSCodeで何をすればいいか

最低限この3つだけだが、
これがあるだけで安心感が全然違う。

デザイナーって（主語でか）、
文字だけの説明よりも、
ビジュアル化されているほうが理解しやすいところがあると思う。

gitも例外ではなく、
「分からない」から
「手順を見ればできる」
に変わったのは、自分の中では大きな進歩だった。

現在の私とgitの関係性

gitを完全に理解した、とはまだ言えない。
ただ、どんなものかは把握できたと感じている。

別の案件でも、
「できればgit環境を構築したい」
と思えるようになったほど、
使えば便利なものだということは身に染みて分かった。

怖いからといって、
便利なものを使わずにいるのは、やはりもったいない。

これからも新しい技術やツールを積極的に取り入れ、
効率よく開発・案件を進められるよう、精進していきたい。

※余談ですが、
デザイナーで「gitも任せて！」という方は、ぜひ弊社へご応募ください。