FigmaからGitHub管理へつなげる時の考え方

デザインとコードは同じ管理ができない

デザインファイルをコードと同じように扱おうとすると、うまくいきません。性質が違うためです。

• コード — 行単位で差分が取れる。分岐して合流できる
• デザイン — 画像に近い。差分が人間に読める形にならない

そのため、デザイン側の履歴管理はツール内の機能で行い、コード側とは別に管理するのが現実的です。両方を1つの仕組みに入れようとすると、どちらの運用も窮屈になります。

つなぐのは「履歴」ではなく「対応関係」です。どのデザインがどの実装に対応しているかが分かれば足ります。

対応関係をどこに書くか

デザインと実装の対応は、次のどこかに書いておくと迷いません。

1. プルリクエストの説明 — その変更が対応するデザインのURL
2. デザイン側のフレーム名 — 実装側の画面名と揃える
3. 課題管理のチケット — 両方のURLを1か所に

1番目が最も手間が少なく、後から追えます。レビューする人は、コードだけ見ても「これで合っているか」が判断できません。デザインのURLが説明にあれば、その場で見比べられます。

画像や書き出しファイルの扱い

デザインから書き出した画像をどこに置くかは、先に決めておいてください。

• コードと一緒に管理する — 版がずれない。ただし容量が増えます
• 別の場所に置いて参照する — 軽いが、差し替え時に気づけないことがあります

どちらでも構いませんが、途中で方針を変えないでください。混在すると「どちらが最新か」が分からなくなります。

また、書き出したファイル名に日付や版番号を入れる運用は、後から見た時に効きます。「最終」「最終2」のような名前は、数か月後の自分が読めません。

どこまでを1つの単位にするか

デザインと実装をつなぐ時、粒度が揃っていないと対応が取れません。

• 画面単位 — 分かりやすいが、小さな修正でも全体が動きます
• 部品単位 — 再利用しやすいが、全体の見え方が確認しにくい

実務では画面単位で管理し、部品は画面の中で参照する形が扱いやすくなります。粒度は途中で変えないでください。混在すると、どこを見れば最新か分からなくなります。