◆ Github にあるのは含めてくれてるほうがダウンロードとか楽
◆ 自分でコミットする場合でもサーバでビルドする必要なくなってブランチ切り替えるだけで最新版にできるので含めたい
◆ 含めてしまうデメリットもあるけどブランチ分ければだいたい解決できた

Git でコミットするデータに build で作られたファイルを含めるかについてです
コンパイルする言語の exe なども相当しますが 基本は Web の JavaScript や CSS ファイルを対象にします

含めたい派

他のファイルから自動生成できるファイルは一般的には含めないことが多いと思います
ただ Github を見ていると dist フォルダなどに build 後のファイルを含めているリポジトリもそこそこ見かけます
リポジトリに入っている方がダウンロードする側としては便利なので含めてくれてるほうがありがたいです

自分がコミットする側としても 実行する環境でビルドしたくないので含めておくほうが楽です
手動でアップデートするなら多少複雑な操作が入ってもいいですが push だけしたら済むようにしてる場合もあります
ビルド済みファイルが含まれていれば サーバ側では自動実行される定期的な処理で 更新があればソースコードを置き換えて再起動するだけで最新版になります
Git で fetch してブランチを切り替えるだけです
それがビルドファイルを含めなくなるとサーバ上でビルドして作ることになります
fetch で変更があったら yarn install して依存パッケージ取得してから webpack などで build を実行……なんてしたくないです
サーバにビルドのための余計なファイルをいっぱい置いておくことになりますし エラーが起きる可能性も増えますからね
そういう部分は極力減らして Git でファイル置き換えるだけで済むのがベストです

企業がやるようなサービスで技術レベルが高い人がやってそうな CI デプロイとかになると良い方法があるのかもしれませんが 個人レベルで使うツールを増やして複雑にはしたくないので使ってません

含めるデメリット

push した後の視点だと含めるメリットが多いのですが 普段の Git 操作では含めるデメリットもあります
watch したままだと Rebase などの処理途中で変更されて変な競合が出ることがあります
watch していなくても変更ありとみなされるので stash が必要になったり 競合が出たりします
ビルドされたファイルはいつでも作り直せるのでそれらの処理では全て無視してくれていいのですけどね
それならコミットに追加しなければいいということになります

リポジトリに入ってると .gitignore で無視されないし 無視するファイルとしてマークする機能もあるのですがビルドファイルをコミットしないといけないときにも表示されなくてコミット漏れになってたことも何度かあるのであまり良い方法じゃないと思います

世間のリポジトリはどうしてるのかと考えたら 前に見た大きめの OSS アプリではリリース用にブランチが分かれて そこは master にマージされません
ブラウザとか見てるとブランチが分かれるのがいつでリリースがいつみたいなのがあって開発中のツリーが一直線でもリリース用に別れてからはそこだけに別の変更が加えられてるんですよね

一人で作っているようなものだと開発中の最新とリリース用が離れていることはほとんどないですし わざわざブランチを分けていません
リリース用にビルドファイルをコミットして push したコミットの続きとして新機能などの変更をコミットしています
必要ないのにブランチが別れてるとログが見づらいし あえて分ける必要もあまりなかったのが理由です

ですが 分けてみるといい感じになりました
ブランチが分かれてから そこにだけビルドファイルをコミットすると開発中のブランチではビルドファイルは含まれません
Git の管理外になるので Rebase 中に変更されても何も起きませんし ブランチを変えたり Reset してもビルドファイルに影響しません
強制的に変更無しとして扱うわけでもないので コミット画面のリストに並んでいてコミット漏れの心配も減りました

あえて言うならバージョン情報をコード中に含めている場合 前回のバージョンがわからなくなるのが不便です
ビルド時の変更も含めてツリーが一直線だと バージョンを上げたいタイミングでは今書かれているコードのバージョン値を 1 つ上げるだけです
分けてしまうと今のバージョン情報が入ってないので次何にするのかを調べないといけないです
正規表現でバージョン部分を取り出して +1 するということもできなくなるので自動で処理にするのは難しくなります
OSS で誰かに使ってもらうでもないと 3 桁でメジャーバージョンとかマイナーバージョンとか管理してもあまり意味ないと思うのでバージョンをそのビルドの時刻にしてしまうのが良いのかもしれません

自動でリリースブランチを作る

ブランチを分けると言っても そのブランチのみパッチを当てるとかはないのでブランチ分けてビルドしてコミットまで自動でやるようにしようと思います

フォルダ構造は

- src
- lib

の 2 フォルダで src をビルドした lib フォルダを作ってコミットします
自動でコミットするのでコミット対象を選択するファイルリストに lib の中身が出る必要はないです
邪魔なだけなので .gitignore に書いてしまいます

[.gitignore]
/lib

Git 操作部分は bash のスクリプトにしました
ここではビルド処理は何もせずコピーするだけにしています
cp のところを適宜ビルド処理に置き換えます

git checkout -B release

# build
mkdir lib
cp src/* lib/

git add -f lib/*
git commit -m "release"
git checkout -

やってることは今の場所に release という名前のブランチを作って切り替えてから ビルドして lib 以下をコミットして 最後にもとのブランチに戻るというものです
実行前の release ブランチは消えるのでタグをつけるとかで参照を保持しておかないとアクセスできなくなります