受託ウェブサイト制作現場における確認出しにまつわる問題について

私が携わっているウェブサイト制作現場で、Gitを使っているにもかかわらず、Gitの強みを十分に活かせない運用がなされている。
もうちょっと何とかならないものかと思い、諸賢のご意見をうかがいたい。

問題

Aという制作案件と、Bという制作案件が進行している。あるページ example.htmlが、両方の案件で編集される。
Aのリリース後の近い未来にBのリリースが行われる予定である。
Aの制作を施したexample.htmlを確認してもらうことになった。同時に、Bの制作も済んだので確認にまわしたいが、Aリリース時点のexample.htmlはそのままにしておきたいので、example_b.htmlと別名で保存して確認してもらうことにした。

あるべき運用

Aの件について、feature/aブランチで制作、commit&pushして確認を依頼。
Bの件については、feature/bブランチで制作、commit&pushして確認を依頼。
AについてはOKが出たので、feature/aブランチの履歴から差分ファイルをまとめて納品。そして、masterブランチにマージ。（masterブランチからそのままデプロイできるとより理想的）
Bについては修正指示が出たので、feature/bブランチで修正内容をcommit&pushして再度確認を依頼。OKが出たら、Aと同じように差分ファイルをまとめて納品。masterブランチにマージする。

実際に起こっていること

Aの件について、（一応）feature/aブランチで制作。一通りできたら、developブランチにmergeし、pushしてから確認を依頼。
Bの件について、（一応）feature/bブランチで制作。一通りできたので、developブランチにmergeしたいが、Aの件で対応しているページ（example.html）を編集している。Aの対応状態とBの対応状態をそれぞれ確認してもらう必要があるので、example_b.htmlなどと別名にリネームした上で、developブランチにmergeする。そして、pushして確認を依頼。
Bの件についてOKが出たので納品しようと思うが、htmlファイルをリネームしているので差分ファイルがgitコマンドで素直に出てこない。
developブランチの履歴が汚い。example.htmlの履歴を正しく追えない。

納品ファイルをまとめるのが辛いというのは副次的なことで、
とにかく、Gitを使っているのに、同一ファイルをバージョンごとに別名保存しないといけないというのが究極的にダサい。これを何とかしたい。

このような運用を強いられる背景

• 常時、複数の制作案件が同時進行している
• スキルの問題で、リモートサーバにアップロードされたサイトでないと閲覧確認できない人（クライアント、ディレクター）がいる
• リモート確認環境が１個しかない
• リモート確認環境がGitリポジトリの特定のブランチに紐づいてデプロイされる

以下、細かく見ていく。

常時、複数の制作案件が同時進行している

これは普通。制作現場とはそういうもの。

スキルの問題で、リモートサーバにアップロードされたサイトでないと閲覧確認できない人がいる

確認する人がgitに上がっているブランチを自分でpullして、各自の環境（ローカルサーバとか）でチェックしてOK/NGを判断できれば何の問題もない。
しかし、実際にはそんなことはない。
受託のウェブサイト制作においては、最終確認者であるクライアント（依頼人）は、基本的にはブラウザでサーバにアップロードされたウェブサイトを閲覧することしかできない。
制作サイドの人でも、ディレクターなど非エンジニアに確認してもらう際にも同様だったりする。
確認してもらうためにリモートサーバにアップロードする工程は必須。

リモート確認環境が１個しかない

確認環境が複数あれば、環境１にはAの対応状況をデプロイして、確認してもらう。環境２にはBの対応状況をデプロイして、確認してもらう。ということが可能だ。
example.htmlの２つの状態を確認可能にするために、別名保存する必要はない。
ただ、環境が2つあっても、３つの状態を確認してもらう必要が生じたときには同じ問題が発生する。確認環境を複数用意するのは根本的な解決策ではないのかもしれない。

リモート確認環境がGitリポジトリの特定のブランチに紐づいてデプロイされる

リモートの確認環境は、特定のブランチdevelopの状態が反映される。
developブランチをpushすれば、（トリガー自体はブラウザから手動だが）デプロイは自動で行われる。
確認してもらうためには、developブランチに入れるしかない。

解決策

私はこの現場において、リモート確認環境について変更する権限がない。
よって根本的に解決できないのだが、もし権限があるとしたら、どうするのが良いのだろうか。

デプロイするブランチを切り替えられるようにする

もし、デプロイするブランチを切り替えられるのであれば、feature/aをデプロイして「いまAの内容を反映しているので確認してください」、feature/aをデプロイして「いまBの内容を反映しているので確認してください」とかができる。
同一ファイルを別名保存しなくてもよい。
でも、鈴木さんにAの確認を、佐藤さんにBの確認を同時に出したい（明日のリリース状態と明後日のリリース状態を確認できるようにしたい）とかなると問題になる。

開発用のリポジトリと確認用のリポジトリを分ける

リモート確認環境に紐づいているリポジトリとは別のリポジトリを用意して制作する。
確認してもらいたい段階になったら、開発用リポジトリの当該ブランチのファイルを（何らかのコマンドとかで）確認用リポジトリにコピーして、commit&pushしてデプロイする。
確認用リポジトリの履歴はぐちゃぐちゃかもしれないが、開発用リポジトリは整然と運用できる。
デプロイするブランチを切り替えるというのと本質的には同じ。なので、同時に別バージョンを確認してもらいたい状況が発生するとやはり問題になる。

実際どうしているの

このような現場で、同じファイルをバージョンごとに別名保存するというこの上なくバカバカしい運用をなくすためにはどうすればいいのだろう。
閲覧確認環境を複数用意して、ブランチを切り替えることができる（デプロイされた状態を変更できる）ことになれば、大方の問題は解消しそうではある。しかし、制作進行が複雑で、確認環境の個数以上に様々なバージョンを同時に確認出ししなければいけなくなったときに行き詰まるので、本質的な解決ではない。
ブラウザでウェブサイトを閲覧するくらいのスキルの確認者に、任意のブランチの状態を確認してもらえる仕組みはないのだろうか。