Git に修正できない問題があります。同様のケースを検索しましたが、自分の状況に適した解決策を見つけることができませんでした。

基本的に、master と bugfix の 2 つのブランチがあります。バグ修正は、リリースを行った時点で master から派生します。バグ修正で何かを修正し、バグ修正リリースを行うたびに、それをマスターにマージする必要があります。Master には新しい機能が含まれています (もちろん、バグ修正にマージすることはできません)。誰かが誤って master をバグフィックスとマージしてしまったことがありました。

これに対する解決策は、ここで説明されているように、「git revert -m 1 M」(M はマージからの SHA) で行ったマージを元に戻すことでした。バグ修正ブランチには、失いたくない他の変更が既にあり、これはバグ修正ブランチでうまく機能したため、元に戻しました。

この問題は、バグ修正ブランチを master にマージする必要があるときに発生します。私が投稿したリンクで説明されているように、元に戻すとコードの変更は修正されますが、履歴は修正されません。これは、マスターにバグ修正をマージすると、元に戻すが有効になり、マスター (x1 と x2) から変更が削除されることを意味します。私にできることは、マスターにマージする前に、バグ修正で元に戻すことです。

これは機能しますが、マージを行うたびにこの「元に戻す」を行う必要があるため、最終的な解決策ではありません。数日間、これに対する恒久的な解決策を探していましたが、バグ修正ブランチの履歴からマスター コミット (x1 と x2) を消去するしかないようです。ただし、ここでは例として x1 と x2 を使用しています。実際にはもっと多くのコミットがあり、バグ修正ブランチの履歴を分析することは非常に難しく、エラーが発生しやすくなっています。Git がこれを行うのに役立つことは確かですが、方法がわかりません。

どんなアイデアでも非常に役に立ちます。

私たちのリポジトリでは、機能ブランチに基づいて機能を開発しています。最近、機能feature/myfeatureをに統合しましたmaster:

このマージの後、この機能に問題があり、統合がブロックされていることが判明するまで、さらに開発が行われたため、このマージを元に戻すことにしました。https://stackoverflow.com/a/6217372/1237653に従って、履歴を壊さずにマージを元に戻す唯一のオプションを選択しました。

その間、さらに多くの開発masterが行われ、作者は修正コミットを追加しました。ここで、機能を統合/マージするために 2 回目の実行を行いたいと考えています。残念ながら、最初の apply & revert が 2 回目の試行とまったく同じコード行に触れるため、今では多数の競合が発生しています。

これらの無意味な競合なしに、以前に元に戻した機能ブランチを再適用するにはどうすればよいですか?

運悪くやってみ-s recursive -Xrenormalizeた。リベースも同じ競合を引き起こします。

だから私はgithubにマスターとリファクタリングの2つのブランチを持っていました。ローカルでリファクタリングをチェックして、町に行きました。ある時点で、git push origin master元のリファクタリングにプッシュする代わりに失敗して実行し、さらに、さらに有効な変更を master にコミットしてから 2 週間後まで問題に気づきませんでした。

/me フェイスパームス

ボークを解除しようとするために、マスターをローカルでチェックアウトし、git revert <some tag>追加したさまざまなファイルを削除してマスターを修正するなどの作業を行いました。ハッピーエンド！元のマスターにプッシュされ、すべてが順調でした。ローカルのリファクタリング ブランチで作業を続け、ときどきオリジン リファクタリングにプッシュしました。

今日、リファクタリングの最初のパスが完了し、変更をマスターにプッシュしたいと考えています。私git add、、。git commit_ git push origin refactorすべては順調です。次に、オリジンマスターにプッシュしようとします。失敗！驚くべきことではありませんが、悪ふざけのために手動でマージする必要がありますよね? それでgit pull origin master、私はローカルのリファクタリングブランチにいます...そして、すべてが壊れてしまいます。私の新しいファイルはすべて削除され、どこでも競合します。

何が起こっているのかというと、元に戻すプッシュが適用されようとしていて、マスターの上にきれいに適用されるはずの完全に幸せな変更と競合していると思います。

それで、私はまだgit newbなので、私の跛行を救う方法について何か提案はありますか? 私の将来のワークフローでこのクラスのエラーを回避する方法について、一般的なガイダンス/教育を提供できればボーナスポイント. ありがとう！

Rails プロジェクトがあり、次の手順を実行しました。

1. git commit -m "Format gemfile"git pushすべてがきれいであることを確認します。このコミットの ID は b24d101 です

2. git checkout -b newbranch

3. 新しいブランチで、ファイルを削除し、他の 2 つのファイルに変更を加え、他のいくつかのファイルを生成しました。

4. git status2 つのファイルが変更され、1 つのファイルが削除され、いくつかのファイルが追跡されていません。ここまでは順調ですね。

5. 問題に気付いたので、 を介して master ブランチに戻り、 を介しgit checkout masterて newbranch を削除しましたgit branch -d newbranch。

6. git statusまだ追跡されていないファイルがいくつかあることを示しています。

7. 前回のコミットに戻ることにしました。

8. git reset --hard b24d101

9. git status現在、ファイルが削除または変更されていないことが示されています（実際、手動チェックの後にこれを確認できます。ステップ3から削除されたファイルがあり、ステップ3からの2つのファイルの編集はなくなりました）。ただし、これらの追跡されていないファイルがまだいくつかあります。私はそれらをしたくありません。これらのファイルが作成されたので、git はこれらのファイルを削除することになっていませんか?

PSこれらのファイルを手動で「クリーニング」する必要がありますか?

git フローでの作業。昨日、誤って開発をマスターにマージしてしまった Git に慣れていない同僚がいます。

開発には、次のリリースでリリースされるかなりの数の機能があり、マージ時に元に戻す必要があります。これにより、すべての変更を元に戻すコミットが作成されました。マスターを開発にマージすると、リバート コミットによって機能によって生成されたコードが削除されます。

新機能を維持しながら、開発をマスターのホットフィックスと同期できるようにするための最良の方法は何ですか?

- 編集 - 明確にするために、復帰は復帰でした。IE git revert -m 1 <sha>、コミットは既にリモート リポジトリにプッシュされているためです。

これを投稿して以来、マスターを分岐して復帰を元に戻すことで、可能な修正を考え出しましたが、衝突を最小限に抑える可能性がある他の可能性があるかどうか知りたいです。

環境

チームメイトの 1 人が、誤っていくつかのコミットをメインの開発ブランチにプッシュしました。私たちは、同じ場所に配置された小さなチームです。当社のリモート リポジトリは、内部サーバーでホストされています。

以下はコミット ログの先頭です (これらのコミットはすべて既にプッシュされています)。

da8b496は、ブランチに保持したかった最後のコミットであるため、develop最後の 5 つのコミットを元に戻す必要がありました。8c29252「機能ブランチ」での作業を継続するために、から新しいブランチを作成しました。

この回答とLinusからのこの投稿に導かれて、私は多くのことを試しました。しかし、私が最終的に行ったことが「正しい方法」であるかどうかはわかりません。私が見つけた情報は複雑でした。この特定の問題に対する「最善の解決策」を見つけることができませんでした。

質問

私が選択したアプローチ (以下の詳細を参照) は、履歴を損なうことなく、これら 5 つのコミットを元に戻す良い方法でしたか? 同じことを達成するためのより簡単な、または「より正しい」方法はありますか?

とりわけ、da8b496( git checkout -b new-develop da8b496) から新しいブランチを作成し、現在のブランチを放棄することを検討しましたdevelopが、それは適切ではないと感じました。

やったこと（詳細）

最初に、コミットa78b993および用の新しいブランチを作成しました8c29252。これらのコミットには保持したい作業が含まれており、最終的にはメインの開発ブランチにマージし直すためです。

次に、開発ブランチで問題のあるコミットを元に戻し始めました。

最初にこれを試しましたが、うまくいきませんでした (コミットの一部がマージされているためと思われます):

だから…代わりに、各コミットを手動で元に戻しました。一つずつ：

すべての元に戻した後にログをコミットします。

元に戻した後のグラフ:

私には正しいようです。最後に、保持したくないバックアップ ファイルをいくつか削除します。

現在のステータスはクリーンです:

そして、すべてをリモートにプッシュします。

現在、私のgitリポジトリには次のような状況があります。

ブランチ「branch-1」は、しばらく前にマスターからフォークされました (コミット 5 を参照)。

コミット 0 で、それをマスターにマージしたかったのですが、コミット 1 と 3 の間にマスターで発生したすべての変更が上書きされました。効果的な作成

私の同僚はこの状態で作業を続けることができなかったので、マージ コミットを元に戻しました。したがって、HEAD を 1 と同じに設定しました。使用するコマンドは「git revert -m 2 0」です。

しかし今、私は自分の変更を再びマージしたいと思っています。今度は成功することを願っています。次のようなものを作成する必要があります。

これは、失敗したマージ 0 を回避し、マージ前のクリーンな状態 (元に戻すことで達成したクリーンな状態) に戻る新しいコミット -1 になります。

ただし、2 を HEAD にマージしようとしても機能しません。これは、すでに 0 でマージされているためだと思います。

以下に説明する私のコミットツリー：

一部の変更はmasterで元に戻されました。ブランチからの変更をマスターにマージして、元に戻したコミットを元に戻す必要があります。

ワンステップウェイは存在しますか？それとも、ブランチをマージする前にマスターするチェリーピック(B)は 1 つだけですか?

PS 最終マスターは次のようになります: (ABCDE) - 順序は重要ではありません

問題: ブランチには、望ましくないコミットが混在する良好なコミットがあります。

試みられた解決策:

これが行うと思ったのは、指定されたすべてのコミットを適用し、競合を整理できるようにすることです。

私が今それが起こると思うこと：

• git はコミット ハッシュ 5 を適用し、その過程で大きな競合が発生します。
• マージを試み、コードを編集して、より多くの競合の準備を整えます (次のポイントを参照)。
• git は commit ハッシュ 8 を適用しますが、これはマージで行われた編集と競合します
• マージを試みます...などなど

質問: 競合の可能性を提示する前に、git にすべての復帰を連続して適用させるにはどうすればよいですか?

多くのコミットと多くのファイルを含む git ツリーがあります。ここで、ファイルのみに触れる特定のコミットを元に戻したいと思います。説明する：

ここで、変更を a . IOW は、ファイル内のコミットのみを元に戻します (異なるファイル内の他の中間コミット (数千になる場合があります) を元に戻すことはありません)。これはどのように可能ですか?