異なる環境でGitブランチを管理する最良の方法
さまざまな環境でのgitリポジトリの使用に関する基本的な質問がありました。私はWeb開発者というよりはシステム管理者なので、これまで取り組んできたチームはちょうどマスターで正しく機能しましたが、これは明らかに正しい方法ではありません。
私は小さな会社のためにdev/prod/stage環境をセットアップしており、Gitリポジトリにはmaster/stage/devブランチがあります。ローカルでは、gitリポジトリのクローンを作成し、次にgit checkout developmentを正常に機能させるだけですが、dev/stage/prodサーバーでこれを行うための最良の方法は何でしょうか。
私には、環境内のリポジトリ全体をチェックアウトしているように見えますが、get checkout <environment>だけでは適切な方法ではない可能性があります。prodは本番ブランチのみを必要とし、devは開発のみを必要とするなどです。
ブランチで作業している個々の開発者とそれを行い、必要に応じてマスターにマージし、マスターから各環境にデプロイするだけです。
または、あなたが提案するように、トップレベルのブランチ（開発、受け入れ、生産など）を介してそれを行うことができます。ある時点で、各環境に入るロジックを処理する必要があります。そして、あなたが提案する方法は、ほぼ同じくらい良いです。
Ansible（ https://www.ansible.com/ ）のようなものを調べることは価値があります。私は最近、私が働いている会社でこれを採用しました。これは、構成とテンプレートに基づいてさまざまなビルドを異なるサーバーにプッシュする優れた方法です。これは、Unixベースのコントロールマシンから変更を希望のマシンにプッシュするのに最適です。UnixVMをコントロールマシンとして構築する必要があり、 Ansibleをインストールします。Vagrantでこれを管理することもお勧めします（ https://www.vagrantup.com/ ）。
また、各ブランチの各ビルドを管理するJenkinsサーバーを用意し、Ansibleやバッチプログラムなどの他のプロセスを介してバイナリを各サーバーに単にデプロイすることもできます。
それがあなたの質問への答えに役立つことを願っています。
これを行う一般的な方法は、各機能のブランチを作成して、完了時にマスターにマージすることです。製品リリースの場合は、マスターからリリースブランチを作成します。たとえば夜間ビルドは、最新のマスターを実行するだけです。マスターおよび公開されたリリースブランチ以外の長期実行ブランチは必要ありません。