スタックオーバーフローに同様の質問がたくさんあることは知っていますが、これを尋ねる前にいくつかの調査を行ったところ、私の質問に対する直接的な回答が見つかりませんでした。
私の状況は次のとおりです。私はプライベートリポジトリを持っており、別の開発者と協力しています。つまり、私たちは 2 人の開発者であり、プライベート リポジトリを使用しています。つまり、それpush -fは世界の終わりではありません。このリポジトリは間もなく公開され、この時点で間違いを評価し、履歴を変更するために少し手直しを行います (リポジトリが公開されると、人々は作業コミットの強固な基盤で作業できるようになります)。
昨日master、何らかの理由でコミットをプッシュしましたが、私のマシンと開発サーバーでのみ機能し、同僚のマシンや運用サーバーでは機能しません。
albumそのため、以前のコミットからブランチ ( ) をフォークしました。私の同僚は、このブランチで数回コミットしました。彼はブランチをリモート リポジトリにプッシュし (作業バージョンをプロダクション サーバーに公開するためにこれを行う必要がありました)、最終的には次のようになりました。
master: (previous commits) - C1 - C2 (my "troubled" commit)
\
album: C3 - C4 - C5 - C6
通常の状況では、チェックアウトmasterし (問題のあるコミットC2が先頭になります)、そこにマージalbumします。
しかし、これはC2歴史に残ります。加えて、私たちの人生を理解することはできないため、私のコミットが環境を壊した理由は、逆にコミットを「再適用」する方が良いと感じています。
私は何をしようと考えていますか：
- チェックアウト
album - その上にマスターをリベースする
albumローカルおよびリモートで削除push -f主人
望ましい結果:
master: (previous commits) - C1 - C3 - C4 - C5 - C6 - C2'
すべてのマシンでどこC2'を修正して動作させるべきか。
それで、私はまっすぐに考えていますか？そうでない場合、gitの達人はこれにどのように対処しますか?
よろしくお願いします。