フロントエンド開発におけるGitの管理対象について

Question

メタ言語を用いて開発を行うsrcディレクトリと、そこから出力されたファイルを保存するdistディレクトリがあります。
これまで両方をGitで管理してきましたが、distディレクトリにおいてadd忘れやコンフリクトなど何かと問題が多発していたので、管理対象から外したいと思いました。
ただ、これだと場合によっては出力されるファイルに差異が出来るのではないかという懸念があります。
実際の現場ではどのように管理しているのでしょうか。

Comments

[miyabi-sun]

> ただ、これだと場合によっては出力されるファイルに差異が出来るのではないかという懸念があります。

えっ？そもそもsrcとツールが同じであれば、
何度実行しても同じdistが得られる前提でPugやSASS等を使ってきたのではないのですか？

何が実行されて何が払い出されるか分からない謎の物体を使い続けて来たんですか？
そこを信じられないなら即刻そんなヤバイツールは捨てて、
生のHTML、CSS、JSファイルで管理した方が良いと思いますよ。

[toromou]

環境によっては出力されるdistが異なる場合があるのではないか、という思い込みがありました。
まだ勉強中の身なので、その辺りはご容赦下さい…

[miyabi-sun]

なるほど、その辺承知しました。
さらっと書いていきますね。

Answer 1

ただ、これだと場合によっては出力されるファイルに差異が出来るのではないかという懸念があります。

実際の現場ではどのように管理しているのでしょうか。

Gemfile.lockやyarn.lockといった、パッケージマネージャのロックファイルをGit管理に入れておきます。

ツール類も厳密にバージョン管理されることになるので、（何かでリポジトリから取り下げになるような特殊な事態が起きない限り）同じ結果を生成できるようになります。

Comments

[toromou]

ご回答ありがとうございます。
自分の環境ではpackage-lock.jsonがありますが、これがロックファイルということでよろしいですよね。
つまるところ、ロックファイルや設定ファイル(webpack.config.jsなど)がGitで管理されていれば、出力されるファイルの管理は必要ないということでしょうか。

Answer 2

distを含めるべきか捨てるべきか、
実際GitHubでも派閥があり、どちらも正解だったりします。

これはプロジェクトやその方針によりマチマチです。
やりたい用にしましょう。

デプロイに CI/CD を挟むならdistは抜いても良いと思います。

---

解説

WebブラウザはHTML、CSS、JSファイルのみしか認識出来ません。
それは辛いので、簡潔に表現出来るイケてる言語作っちゃおう！
それをトランスパイラというツールに噛ませてHTML、CSS、JSファイルを作れば楽だよねという思想があります。

有名所を上げるとこんな感じ

• Pug: HTML用の言語
• Sass: CSS用の言語
• TypeScript: JS用の言語

これだと場合によっては出力されるファイルに差異が出来る

有名どころのツールはその心配は基本的に無いので安心してください。

src -> destへの変換結果がバラつくトランスパイラは出来損ないのバグ持ちです。
有名所のツールの多くは1系にバージョンアップされてβが取れた時点で、
殆どバグはないよ！仕様の変更もコロコロせずにこれで安定動作させよう！！となります。
このためにツールの開発者達はテストを実行したり、日々改良しています。

いやいや、ツールのバージョンアップで仕様が変わって動作が不安定になるかも知れないじゃないか！

セマンティックバージョニングという思想があるので安心です。
Node.jsのパッケージ管理ツールであるnpmはデフォルトでこの思想で動作するように考えており、
多くのライブラリはこの思想通りの動作をします。

maisumakunさんはこの部分のユーザー側視点で回答してくださっています。
「ツール、バージョン、設定、そして対象のsrcファイル」
これら全てを一致させる事で100回実行しても同じ結果を取り出せるわけですね。

---

CI/CDとはなんぞや？

参考記事: CI/CDとは - RedHat

GitHubにはmasterブランチが更新されたり、
プルリクエストが送られてきたら、HTTPアクセスで登録しておいた任意のURLへ通知を発射する機能が備わっています。
webhookと言われています。

自作のWebサーバと組み合わせて、自由にGitHubに機能を追加するわけですね。

例えば今回の質問の例で言うなら、
src部分だけ変更してコミットすると、
srcをdistに変換して、コンパイル作業を忘れていたらslack越しに「お前忘れとるやないか」と叱る。
更に発展させてdist部分をコンパイルしてコミットにくっつけて再度GitHubへプッシュする機能を作るなんてのも良いですね。

もしくはdist部分は完全に捨ててしまって
masterブランチが更新されたタイミングでsrcや各種設定ファイルとツールを使ってdistを生成して本番環境へ適用するなんてのも良いですね。

こういった100回発生する作業を機械とプラグラミングの力で無理やりねじ伏せる事も可能です。
もちろんこういう仕組みを作り上げるには技術力もそうですが、
コツコツ作業を行う努力や時間も必要で中々大変です。

チームメンバーでどういう方向ですすめるのか、話し合ってみてはどうでしょうか？

Comments

[toromou]

非常にお詳しい解説をいただきありがとうございます。
ツールを曖昧な認識で使っていることが多かったので、非常に勉強になりました。
コミットした際にコードフォーマッタを実行するといったことも今後やりたいと考えていたので、参考にさせていただきます。

私のいる職場は自分以外ITに無縁な方しかおらず、またここに的外れな質問を投げてしまうかもしれませんが、温かい目で見て頂ければ幸いです。
今後ともよろしくお願いします。