マスターと開発者の2つのブランチを持つプロジェクトがあるとします。一度テストするとマスターにマージされる特別なイベントの開発にたくさんのコミットがあります。次に、イベントが終了した後、イベント固有のコードを削除したいと思います。ただし、イベントコードが追加されてから他のコミットが行われたため、gitリセットは実行されません。
現在、git checkoutを使用して、イベントがマージされる前のファイルをチェックアウトしてから、git diffを使用して、イベントがコミットされてから行われた変更を再度追加しています。これは私には非常に厄介な方法のように思えます。
プロジェクトに一時的なコードを含めるためのより良い解決策はありますか？
編集：明確にするには、変更をコミット、プッシュ、非コミット、プッシュする必要があります。
マスターを取得してブランチを作成します：git checkout -b special-event、変更を加え/適用します。イベントが終了したら、マスターに戻ってブランチを放棄/削除するだけです。
変更を継続するには、マスターで変更を行い、必要に応じて特別なブランチにマージします。git checkout master...変更を加えるgit checkout special-event; git merge master...。
または、1回のコミットですべての特別イベント関連の変更を行い、git revertそれらをロールアウトするときに使用して、そのコミットのみを指定します。
私の特許を取得していない方法に従ってコミットをロールアップします。
# work on a new branch
git checkout -b event-36
git commit -a -m "all broken dammit"
git commit -a -m "fixed that damn code"
git commit -a -m "almost ready, going to eat lunch"
git commit -a -m "It's done!"
# other people might be working on master in the meantime, so
git checkout master
git checkout -b erasemeImmediately
git merge event-36
git reset --soft master # THE KEY TO THE WHOLE THING: SOFT RESET!
git commit -a -m "Event 36, all code in one commit"
git checkout master
git merge erasemeImmediately
これはで行うことができますreflogが、その場合は最近のCSの学位が必要になります（つまり、理解するのが難しい）。
これで、コミットは1つになります。これで、revertを使用するか、それなしでブランチへの道をチェリーピックすることができます。
「一時的なコード」？gitではそのためにブランチを使用します。コミットはgitで非常に軽量であり、ブランチは、ほんの少しのロジックがアタッチされたコミットの単なる名前（または参照）であり、他のシステムと比較して非常に軽量です。
ロジックのほんの少しは、参照が最後のコミットに自動的に更新されるということです。これがブランチのほとんどすべてです。つまり、実際には何も作成または削除されないため、gitでのブランチの作成と破棄は高速で、シンプルで、安全ですらあります。削除後も、commit-idでブランチヘッドを参照できます（そうです、ガベージコレクションされるまでそこにあります。それでも、他に参照がない場合にのみ発生します）。
gitのほとんどすべてのコマンドは、パラメーターとしてコミットへの参照を取ります。これはgitマージにも当てはまります。ブランチをマージするのではなく、コミットをマージします。はい、「git merge」と入力しますが、ここでも、ブランチはコミットの名前にすぎません。それ以上のものはありません。また、必要なのはイベントのコミットをグループ化することだけなので、名前を付けるだけです。
したがって、正しいことは、イベントのブランチを作成することです。または、おそらく、「event-master」と「event-dev」の2つです。ここで、「event-dev」でイベントのコードを開発します。メインコードで修正する必要のあるバグに遭遇した場合は、通常の「dev」ブランチに隠して切り替え、修正をコーディングしてコミットします。'event-dev'に戻り、'dev'からマージして、スタッシュをポップします。開発を続け、完了したら、コミットしてテストします。問題がない場合は、「event-dev」を「event-master」にマージします。これには修正も含まれます。修正はまだ「マスター」にないことに注意してください。
修正を「master」にマージする必要がある場合は、修正が「dev」にあるため、通常の方法で実行します。
基本的に、このセットアップでは次のことができます。
通常どおりメインコードを開発します。「dev」にコミットし、テストして、「master」にマージします。
同様の方法でイベント固有のコードを開発します。「event-dev」にコミットし、テストして、「event-master」にマージします。それはまったく同じワークフローです。
2つのワークフローを混合します。ブランチをコミットして切り替えるか、gitstashを使用します。
ブランチを（ほぼ）自由にマージします。マスターが何らかの方法で更新され、イベントの変更が必要な場合は、「master」を「event-dev」にマージできます。イベントの変更がどうしても必要で、それらを「マスター」にプッシュする通常のテストサイクルを待つことができない場合は、「dev」を「event-dev」にマージできます。gitは、マージがクリーンである限り、つまり、2つの-devブランチで同じコードを2つの異なる方法で変更しない限り、これを実行します（もちろん、これは処理する必要がある特殊なケースです）。
さらに柔軟性が必要な場合は、さらにブランチを作成します。柔軟性を高めるために、個々のコミットをブランチに選択することもできますが、一般的にはそれをお勧めしません（自分が何をしているかを本当に理解している場合にのみ実行してください）。
最後に、このワークフローはgitでは非常に自然であることを指摘しておく必要があります。実際、「dev」で開発し、「master」で変更をプルすることは、一般的に言って最高ではありません。開発している機能またはモジュールごとにdevブランチを作成し、それらのブランチを「dev」にマージするのが通例です。
gitを使用するときの正しい考え方は、「今日はどのようにコーディングしたいですか？機能Xです。ブランチ「feature-x」を作成してハッキングを始めましょう。」だと思います。あなたのその出来事も例外ではありません。
今、私があなたに言っているのは、あなたが最初から物事をどのようにすべきだったかということであり、それは今のところあまり役に立たないことを知っています。イベントの変更が「dev」ブランチへの通常の変更と混合されているため、ツリーを修正する必要があります。したがって、問題は、イベントの変更のみを使用して「event-dev」を適切に作成し、同時に「dev」からそれらを削除する方法です。
歴史を書き換える時が来ました。それがどれほど難しいかは、変更の性質によって異なります。たとえば、すべての変更が1つのディレクトリに属している場合は、作業が簡単になります。
これが私がすることです（これ以上のことはわかりません）：
gitlogで履歴を調べます。
最初のイベント固有の変更の直前にあるコミットを見つけ、そのcommit-idに注意してください。これは「day-0」コミットです。
そのコミットを指す「newdev」という名前のブランチを作成します。クリーンなツリーでこれを実行します。つまり、これを実行する前にコミットします。git checkout <commit-id> -b newdev;
'event-dev'を作成します：git checkout -b event-dev;
これで、両方とも「day-0」コミットを指す2つのブランチができました。
ここでもう一度履歴を確認します（git log dev）。commitごとにそれに従う必要があります。
'day-0'に続く各コミットは、メインコードに属するコミットか、イベントのみに属するコミットのいずれかであると想定しています。あなたがしなければならないのは、正しいブランチでそれらをチェリーピックすることです。メインコードの場合は「newdev」、イベントコードの場合は「event-dev」です。正しい順序で一度に1つずつ実行します（「0日目」から「今日」まで）。
運が良ければ、「newdev」で終わるコミットは「event-dev」とその逆のコミットに依存しません。あなたはちょっと終わった。現在のmasterとdevの名前をmaster-oldとdev-oldに変更し、次にnewdevの名前をdevに変更し、devからmasterを作成し、event-devからevent-masterを作成すると、設定が完了します。
運が少し悪い場合は、「newdev」を「event-dev」にマージする必要がある場合があります。これは、一部のコミットがメインコードで行われた変更に依存しているためです。ここで大胆に感じている場合は、gitrebaseについて読むときが来ました。ただし、必要がない限り、リベースは行わないでください。
または（さらに悪いことに）「newdev」の一部のコミットは「event-dev」の変更に依存します...おっと、メインブランチが必要とする場合、そのイベント固有のコードはそれほどイベント固有ではないことがわかります。いくつかのマージが必要です。
または（悪い）1つのコミットに両方の種類の変更が含まれています：分割統治（変更を分離して適切なブランチに適用する必要があります）。つまり、コミットを2つに分割します。
または、あなたの木について十分な詳細がないため、今は想像できない何かがあります。
そよ風や悪夢かもしれません。事前に各コミットを調べ（git show、パッチとして見ることができます）、何をすべきかを決定します（最終的には、ファイルを編集する方が簡単な場合があります）、わからない場合は、ブランチを作成します、そこで作業し、何が起こるかを確認し、問題がなければマージし、それ以外の場合はドロップして再試行します。
これまでは触れていませんが、もちろん、ツリー全体のコピーを作成し、gitファイルを含めて、100％安全になるようにコピーを処理することができます。
最初からそれを行うのはかなり簡単です。今それを修正します、まあ、頑張ってください。:)
私は隠し場所があなたが望むことをすることを信じています。
git checkout -b event
...特定のイベントを変更します...
git commit -am "specific event change"
...別の特定のイベントを変更します...
git commit -am "another specific event change"
この時点では、マスターブランチはそのままで、イベント固有の変更はイベントブランチにあります。イベントブランチでも必要なマスターブランチに変更が加えられた場合は、リベースを使用してください...
git rebase master
別の回答は、マスターをイベントにマージすることを提案しましたが、通常はリベースがより良いアプローチです。リベースは、トピックブランチで行われたコミットを切り離し、更新されたマスターを前方にプルしてから、トピックブランチの変更がマスターの最新バージョンに加えられたかのように、トピックブランチの変更を一番上に再適用します。
シナリオでは、イベントが終了したら、イベントブランチを削除するだけです。
git revert
コミット、または元に戻す必要のあるコミットの範囲が削除されます。公開リポジトリにプッシュすることも安全です。
私の経験では、いくつかの特別なイベントには繰り返しの方法があります。したがって、ここで検討する別の解決策は、特別なイベントの処理を有効にする構成オプションを作成して、必要に応じてオンとオフを切り替えることができるようにすることです。