個人の開発環境に必要でファイルに改修を加えたけどgit pushはできない時
目次
この記事の内容
自分の開発環境依存で、プロジェクトのインフラコードなどに少し改修を加える必要があるタイミングがあります。 個人的な開発環境の問題なので、これらの改修をコードベースにcommitするわけにはいかないことも多いです。
上記の問題に差し当たって、この記事では以下のことについて言及します。
- どういう時に困った
- 解決策の選択肢
- 自分の選んだ解決策
困ったタイミング
私が開発に携わっているプロジェクトでは基本的な開発環境を全てdocker imageで提供しています。
M1 Macを購入してmysqlのarmパッケージがない既知の問題にぶつかり、
その対応策として公式の指示通り、 mysql-server のimageを利用するようにしました。
M1 Macを利用した開発環境というのは個人の問題であり、そこで生じる課題に対してプロジェクトのコードベースを変更するのはどうなのかという意見もあり、
コードベースは mysql のイメージの利用を続けています。
この場合、コードベースのdocker-compose.ymlと手元のdocker-compose.ymlに差分が生じることになりますが、この差分はcommitしてはいけません。 コードベース側に変更が生じた際には追従したいので、gitのexlclude設定に入れるのも勘弁したいです。
VSCodeの設定や、環境依存で変更しなければならないビルドスクリプトなどで、似たような状況の方は結構いるんじゃないのかなと思っています。
解決策の選択肢
それほど多くの選択肢は思いつきませんでした。
- git hookに引っ掛けて、git操作のたびに該当ファイルをstashしてgit操作が完了すれば復元する
- git hookに引っ掛けるわけではないが、修正したファイルのコピーをとって退避した後にgit操作をする
- 気持ち悪いがそのまま放置する
選んだ解決策
2番(3番)になります。
まずはこの気持ち悪さの解消にそれほど大きな工数を割きたくなかったので、git hookは除外しました。 通常業務で頻繁に使用するコマンドに現地してhookするなら簡単な気もしたのですが、稀に利用するコマンドに対応していないと逆にヘイトが高まりそうと言うのもあり、 それらへの対応をするとなると割と時間が溶けそうだなと感じました。
コピーをとる方針は簡単そうだったので、これを採用しました。
しかし、結局毎回コピーをとって git restore . をするかと言うとそうでもないです。
私は git add . はせず、commitするファイルを自分で選ぶので、基本的にはずっとunstagedのファイルが残るだけで実害はありません。
そのため、手元の独自版ファイルを誤ってコードベースと同期してしまった時の保険としてコピーをとっているという状況で、 気持ち悪さを許容しています。
コピーを取る際
- コピーをgit管理させない
.gitと同様の階層で扱いたい- コピーのデプロイは一括で行いたい
あたりの要求があったので簡単なシェルスクリプトを書きました。コードはこちらになります
コードの上部に記載している使い方は以下の通りです。
# Local Development Files Storage
#
# usage:
# ldfs Restore all storaged files to use in development
# ldfs [file] Store file in storage
# git checkout [file] Restore original file managed in remote repository
#
# description:
# store files only to use in local development
# ldfs is enable only in git repository
修正したファイルのコピーを .ldfs ディレクトリに保存します。
ldfs docker-compose.yml
コピーしたファイルを展開したいときは
ldfs
とします。
git_ignore のグローバル設定などに .ldfs を追加してgit管理から外しています。
まとめ
あまり綺麗な解決策ではないと思うのですが、同様の問題に困っている方がいれば一助になれば幸いです。 また、逆におすすめの解決策をご存知の方がいましたら教えていただけると幸いです。
追記
Twitterで git stash で良いのではと言う意見をいただき、いや本当にその通りと思いました。