私はしばらくの間gitを使用していますが、それでも自分はn00bだと思っているので、あまり厳しくしないでください。
私は「企業」のメインフレームシステムを2つの同一でないコピーとして維持しています。それらをテストと本番と呼びましょう。メインフレームには、私（またはおそらくあなたの誰か）がバージョン管理システムと見なすものは何もないので、デスクトップでgitを使用してバージョン管理を提供しています。現在のワークフローの主な機能は次のとおりです。
デスクトップとメインフレームはFTPと「同期」されています。最終的に、すべての開発作業は、メインフレームで記述されているかPCで記述されているかに関係なく、最終的にはgitブランチのPCで行われます。
ハドソンのような「最新の」展開テクノロジーにはアクセスできません。
TestとProdという2つの主要なブランチがあります。製品の（継承された）構造のため、TestインスタンスとProdインスタンスの間のコードには多くの違いがあります。たとえば、すべての表示パネルは、これがテストか製品かを明確に識別する必要がありますが、これを単一のポイントで構成する方法はありません。
私は通常、特定の開発サブプロジェクト用にアドホックに他のブランチを作成します。
一般的な開発は、複数のコミットを使用してテストブランチで行われます。準備ができたら、これらはProdにチェリーピックされ、変更番号のタグが付けられ、承認されたときにアップロードされます。
幸いなことにまれな緊急作業は、Prodブランチで行われ、Testにチェリーピックされます。
さくらんぼ狩りは、ごくまれに、手動でマージする必要があります。
このワークフローを改善したいと思います。現在、私のリポジトリは、2つのブランチでの並列の同一の変更でいっぱいです。
私はそれをこのようにしたいと思います（テスト->製品の場合）：
開発の準備ができたら、HEADofProdに新しいブランチを作成します
この一連の開発変更を、新しいブランチで1つの変更にまとめます
この新しいブランチをProdにマージします。彼らの共通の祖先は、TestをProdとは異なるものにする変更の前にあることを覚えておいてください
うまくいくように見えますが、それが私のポンアシノラムgit rebase -iであることを告白しなければなりません。どういうわけか、私は何度もツリーを台無しにしてしまいました。git rebase
だから私の質問はこれらです：
製品の制約の範囲内で、より良い方法を提案してください。
私の好みのアプローチが実行可能である場合、誰かが正しいパラメータを提案できます
git rebase -iか？
