私が働いているgitを使っている巨大なプロジェクトには、3ヶ月間巨大な機能のために働いているチームがあります。その期間の2ヵ月目に、ある開発者は何らかの形で、機能ブランチにコミットを1つ作成して、すべてのファイルを変更せずにステージングしました。コミットせずにGitブランチを作り直す
この機能ブランチをメインのものにマージしようとすると、大きな問題が発生します。
コミットの3ヶ月間に1回悪いコミットを行わずに再作成する方法はありますか？
新しいコミットを使用して「取り消し」します。変更を保存する予定の別のブランチに統合すると、これは面倒なことがあります。 – evolutionxbox
最も安全な方法は、<commit>が問題のSHA1ハッシュがコミットされ
$ git revert <commit>
を行うことです。
コミットを履歴から完全に削除する場合は、git rebaseを使用できます。 featureは仕事に分岐がある場合は、次の手順を実行します。これは現在までコミットからの全体の歴史を書き換えていること
$ git checkout feature
$ git rebase --onto <commit>~ <commit>
注意を。これは、すべての開発者が今featureブランチを取得すると、むしろgit pullを行うよりも、それにリセットしなければならないことを意味します
$ git checkout feature
$ git fetch origin feature
$ git reset --hard origin/feature
なぜこれが最も安全な方法ですか？ – evolutionxbox
@evolutionxbox 'git revert'は、指定されたコミットからの変更を元に戻す新しいコミットを作成します。すべての開発者はブランチを 'git pull 'して直ちに最新の状態にすることができます。しかし、 'git rebase'はブランチの履歴を書き換え、各開発者は私の答えで最後の3つのステップを実行する必要があります。もしもいずれかの開発者が 'git pull'を実行すると、当初の問題のあるコミットは履歴に残っているだけでなく、元のコミットのシーケンスとrebase操作によって作成されたコミットの新しいシーケンスの両方として、 –
Gitは-i HEAD〜Nをリベース。ここで、nはコミットの背後にある1つのコミットです。コミットを削除します。メインブランチにマージする前に、後でgit rebaseを実行してください。 –
フィーチャーブランチの* one commitというフレーズは、すべてのファイルが変更されずにステージングされます*意味がありません：* Gitのstaged *は "インデックス内"を意味します。コミットにはインデックスがありません。コミットはスナップショットであり、各スナップショットには* all *のファイルがあります。一般的に、スナップショットと親コミットのスナップショットを比較して、「変更されたもの」を表示します。何も変更されていない場合、結果のコミットは「空」と呼ばれることもありますが、空のコミットは無害なので、心配することはなく、実際の問題は生じません。したがって、*問題がある場合、この記述は正しくはありません。 – torek