■プロジェクト運用的な話
まず最初に言えるのは既にリリース済みの製品に対して
何か運用を変えるのであれば他の方の回答にある通り、
「相談」は絶対に必須です。
※回答者の言葉馴染みの関係で「外製」を「外注」と記述します。
例ですが、
自身 => プロジェクト管理者(若しくは更に上長) => 顧客(外注)折衝
のように
現在の契約(責任問題)をどのように整理し、
SE側のプロジェクト管理をどのようにするのか等
具体的な方針を決める必要があると思われます。
ですので、質問者の方が提示した
個人的に思いついた案2
そもそも顧客と外製が触ってもよい領域を決める
こちらが現実的かと思います。
仮にソースコードの話だとしますが、
①自社のmainブランチ(最新かつデプロイ済み)
②顧客のサーバ(git未導入+自由に変更することができる)
③外注のmainブランチ(必ず①と同一であること)
とした場合、②に問題があることは
一目で分かるので相談しましょう。
■技術的な話
顧客のサーバーにあるデータ
これがソースコードの話か
DBの実データを何かしらに固めたモノかや
スキーマの話かいまいち分かりませんが…
もし実データであれば、
「そもそもGitで管理するべきでない」という回答になります。
その場合は可能であればデータの出力及び突合できるような
機能を実装してデータをマージするべきです。
みなさまどのようにしているのでしょうか。
※以下は自身が経験したRails案件の一例です
もしソースコードに変更を加えるようであれば
「feature/refactor-yyyyMMdd」のように新規(一時変更用)にブランチを作成し、
ローカル環境(もしくはステージング環境)での動作確認完了後
Pull-Requestを発行しレビュー完了後に
develop(開発用)ブランチにmerge => main(本番稼働)ブランチにmergeを実施します。
上記についてどうするかは全体的に相談してもらうとして、
GitHubで特定の操作が検知された場合に
自動的に何か仕掛けるということは
GitHub Actionsである程度は可能です。