の親を変更、遅すぎる枝を始め、私は次のような状況があります。は私の枝
A---B---F---G---H (master)
\
\
C---D---E (experimental)
を私の問題は、Bがmasterに起こってはいけない非常に、非常に悪いことであるということです。それはexperimentalに属します。しかし、F --- G --- Hは大丈夫です。
A---F'---G'---H' (master)
\
\
B---C---D---E (experiment)
私はおよそリベースし、そのようなものが、最大の問題はmasterがoriginにプッシュされたことがある読んだ：すべてはこのように見えるようにする方法はあります。
git rebase --onto A B masterとなります。
マスターがすでにorginにプッシュされているようですが、元のマスターブランチを上書きすることが確実であれば、マスターブランチでgit push -fを実行してください。他の開発者が原点から引っ張られると競合する可能性があることに注意してください。
一般的に、パブリックリポジトリのブランチはそのままにしておく必要があります。つまり、コミットBをマスターから削除することはできません。コミットBによって導入された間違いを新しいコミットに修正し、再度マスターにプッシュするだけです。
あなたのチームメンバーにリベースについて知らせることができ、あなたがそうするように主張したら、書き直しても大丈夫です。あまりにも頻繁にハッパーにならないようにしてください。マスターオン
このような矛盾は、' '公開リポジトリにプッシュしたコミットをrebaseしないでください' 'からhttp：// git- scm.com/book/en/Git-Branching-Rebasing –
はい、しかし、あなたが求めているのは、 'git rebase'がこの条件のツールに過ぎない歴史の書き直しです。一般に、パブリックリポジトリのブランチはそのまま残るべきです。つまり、マスタでコミットBを削除することはできません。新しいコミットでBによって導入された間違いを修正し、再度押します。しかし、あなたのチームメンバーにリベースを知らせるのが得意なら、それは書き直しても大丈夫ですが、これがあまりにも頻繁に行われないようにしてください。 – weynhamz
このオプションを使用します。ありがとう！ –
、実行します。
git revert B
コミットその下流の変更は直接の影響を受けていない場合は、それはBをすることなく除去することができるコミットの内容、すなわち（、安全にプッシュすることができますそれの後に来た他の変更を動揺これが事実であるようにそれは確かに聞こえる）。これは、作成します
：。。
A---B---F---G---H---I (master)
\
\
C---D---E (experimental)
ここで、Iは復帰コミットです。マスターはBの内容を削除しながら履歴を保持し、実験ではBの変更を保持します。
実験を後でマスターにマージする場合は、コミットIを元に戻す必要があります。
あなたの答えをありがとうが、それは歴史が複雑に見えるので、私は2人の仲間の開発者を怒らせ、リベースする危険があると思う。あなたのために+1。 –
マスタをリベースすると、手動で通知するチームの人が多すぎますか？もしそうなら、あなたは単に 'git revert B'を行うことができるかもしれません。 – bcmcfc
実験ブランチ上でBを保つ必要があります –