3

ケース #xyz「Implement Hello World」の作業を行うブランチ case-xyz があるとします。

開発中に、最終的なコミットの一部であってはならないデバッグ出力などを追加します。

次のようなことができますか？

  • case-xyz-debug に分岐し、そこでのみデバッグ コードをコミットします。
  • 場合によっては、case-xyz-debug を case-xyz にマージします。
  • case-xyz で最終パッチに入れるはずのものをコミットします。
  • 最後に、case-xyz-debug を「逆マージ」します。つまり、いつ case-xyz にマージされたかに関係なく、そのブランチから発生したすべての変更を削除します。つまり、これは case-xyz-debug からのすべてのマージを元に戻すことと同じです。

マージ コミットを元に戻す場合、Git はマージを忘れないことを知っています。つまり、Git はまだマージ済みであると認識しているため、元に戻すことによってのみ再マージできます。したがって、case-xyz-debug で最初にコミットされたすべての変更が削除されることだけが必要であり、それがどのように記録されるかは関係ありません。ただし、次のようなこともできればいいと思います。

  • git チェックアウト ケース-xyz
  • git checkout case-xyz-done
  • git "reverse-merge" case-xyz-debug

私は開発/デバッグを続けたいかもしれないので:

  • git チェックアウト ケース-xyz
  • ファイルを変更する
  • git commit -am "おっと、忘れ物"
  • git checkout case-xyz-really-done
  • git "reverse-merge" case-xyz-debug

私の意図が明確であることを願っています。全く違う形でこれが実現できれば私も嬉しいです。

4

1 に答える 1

0

私は通常のワークフローの一部として、インタラクティブなリベースを通じて、この種のことを定期的に行っています。デバッグ ロギング、一時的なテストの変更 (タイミングの問題をテストするための fe スレッド スリープ コール、エラー処理コードをテストするために意図的にスローされた例外)、ハードコーディングされた値を含むコミットがあり、アプリでエンド ツー エンドのテストを簡単に行うことができます。 UI などに値を入力します。私はこれらの種類のものを分離したコミットに保持します。私自身の慣習により、コミット ログ メッセージがすべて大文字の場合、それはリモートにプッシュされるべきではないコミットを意味します。

これらの変更を「逆マージ」する (削除する) 準備ができたら、インタラクティブなリベースを介して行います。

git rebase -i <id of branch point>

そして、すべて大文字のメッセージを持つコミットを削除するだけです。

(実際には、これを他の目的に使用できます。たとえば、それらをすべてブランチの最初にgit commit --amend並べ替えるなど、実際の作業を実行したり、最後に並べ替えるのに役立ちます。branch-point..<id of last real commit>「デバッグ」コミットをそのままにして、現在の履歴行の最後に残して、リモートにプッシュしたい場合。)

何が何であるかを知ること<id of branch point>は、多少の苦痛になる可能性があります。master私のワークフローでは、デバッグ コミットを削除すると同時に、ブランチを fe の最後にリベースしたくありません。そのため、私は参照ポイントとして使用するローカル フローティング タグを保持していますrebase(混乱するかもしれませんが、好きな名前を付けることができます)。これが面倒だと思われる場合は、 を使用git rebase -i `git merge-base HEAD master`することをお勧めします。

(これが危険な慣行であるという議論は理解していますが、特に説得力があるとは思いません。SCM で自分自身を撃つ方法は無数にあります。 と の組み合わせを検討する必要がgit rebase --abortありgit reflogます。デバッグ コード以外を含むコミットを誤って削除してしまった場合に備えて、ハッチをエスケープします。)

HTH

于 2012-10-11T20:23:30.380 に答える