職場では、developブランチを日常業務に使用しています（新機能、バグ修正など）。リリースする準備ができたら、devleopブランチをマスター、タグ、およびリリースにマージします。我々はすぐに解放する必要があり、修正プログラムを実行するために必要とされている場合はホットパッチやパッチなどのリリースブランチに対するGit rebase
は、我々は、masterオフブランチを作成して変更を適用し、それに応じて（developに戻すmasterをマージ含む）をマージします。私がこれまで説明してきたことには何の問題もありません。
私は最近、次のリリースに含まれる予定の小さなバグ修正に取り掛かっていました。そこで、私の普通のブランチをdevelopから作り、いくつかのコミットを行い、PRを提出しました。その後、管理者は今日の修正プログラムを修正プログラムとして望んでいました。 OK - シンプルで、私はmasterに対して自分の作品をリベースし、PRをマスターに対して開きます。しかし、git rebase masterを実行しても、マスター上の現在のHEADコミットに対して私の作業は再生されませんでした。代わりに、gitはすべてが "最新のもの"だったと私に言った。私はその後、マスターに対してPRを開きました。私のPRには、私のバグ修正だけでなく、developブランチのすべての新しい仕事が含まれていました。
私はインタラクティブなリベースを行い、そこにあってはならないすべてのコミットを削除することができましたが、これは退屈でエラーが起こりやすいようです。古い目的の最新のブランチに対してrebasingの目標を達成するために、より正気な方法がありますか？？ （あなたが使用したコマンドごとに「上流としてmasterと」すなわち）「masterに対する」代わりにリベースの
あなたの小さなブランチにはいくつのコミットがありますか？ほんの少しの場合、私は "git checkout hotfix; git cherry-pick develop..my-branch"を試してみるかもしれません。 –
幸いにも、私が今週中にリリースしたときに削除しなければならなかったコミットはほんのわずかでしたが、この問題のポイントはコミットや履歴などが何であるかを知ることではありません。 1コミットか100かにかかわらず、別の支店に基づいて仕事をしたいです。 –