ロールバックマスターからの古い枝は関係なく、他のブランチのその後

Question

まずシナリオをプッシュ：

私は私が働いていた3つの支店を持っています。ブランチA、ブランチB、ブランチC

ブランチAをマスターにテストし、マージした/プッシュしました。ブランチAはマスターにマージされているので、ブランチAを削除します。

1週間後、ブランチBおよびCがテストされ、マスタにプッシュされます。 BとCはマスターにマージされているので、私はBとCを削除します。

もう1週間後、上司がオフィスに来て、「Aは悪い考えで、これを削除したい」と言います。 明らかに、彼はAを削除したいが、BとCをプロダクションに保存したい。

どうすればいいですか？このシナリオでは、Aは、BとCから完全に独立している

第2のシナリオ：

このシナリオでは、B以外は、最初のシナリオと同じであり、Cは、Aがマスターにマージされたときにマスターするリベース。 こうして、彼らはAのおかげで利用可能な新しいメソッドを受け取り、それらを使用しました。

今私はBとCを壊さずにAを "削除"できますか？

私には「テストは何が間違っているかを教えてくれる」と答えていますが、テストはありません。

ありがとうございました。 最初のシナリオについては

Answer 1

Aブランチからmasterに導入された変更を完全に削除したいので、Aマージコミットを単にmasterに戻すだけで済むはずです。 git revertを使用すると、元のコミットが導入したすべてのものを効果的に元に戻す新しいコミットが導入されます。他の回答として

git checkout master 
git log 
# find the SHA-1 hash of merge commit A (e.g. d82n93kd...) 
git revert d82n93kd -m 1 

Answer 2

：マージのハッシュは、支店Aのコミット見つけ、

git revert <hash> 

を行う2つ目のシナリオあなたがの復帰として、マスターにAを合併した場合は同じように機能する必要がありますマージコミットは変更を取り消し、BとCをマスターにマージしても変更は再び反映されません。

ただし、各ハッシュでgit revertを実行すると、ブランチAのすべてのコミットを元に戻すこともできます。編集：1つのコミットの逆順、つまり最新のものからの復帰を行うことを覚えておいてください。

Answer 3

既に最初のシナリオはgit revert -m 1 <hash-of-merge>で解決することができる、と述べました。 "-m 1"は、マージコミットの親のどれがメインラインなのかをgitに伝えるので、元に戻すべきではありません。あなたはgit show <hash-of-merge>を使って両親を見ることができ、 "Merge："のような出力が得られます。変更を保存したい場合は、すべての親から "-m 1"を使用します。

これにより、ブランチAによって行われたすべての変更が元に戻される新しいコミットが行われます。

--preserve-mergesオプションを使用してgit rebaseを使用すると、履歴を書き換えてそのマージを削除できます。しかし、これはあなたの履歴を変更します。これは、そのブランチが既に他の人によって使用されている場合は良い考えではありません。

第2のシナリオに関して私はかなり手作業なしではできないと確信しています。すべてのケースでAの削除は、そのブランチによって導入された関数を削除し、それらがそれらの関数に依存する場合、BとCからの変更を破棄します。したがって、まだ必要なすべての機能を残して、手動で機能を削除することもできます。または、上記のようにAの復帰を行い、後でこれらの機能を手動で追加します。どのオプションが良いかは、ブランチAのどれくらいを実際に削除すべきか、どのくらい保持するかによって決まります。