最初の統合リポジトリが I で、あなたのコミットが Y で、後で同僚のコミットが C であるとしましょう。したがって、開発ラインは次のようになります。また、ファイルシステムは現在 F です。
(F)
I--Y--C1--C2
↑
HEAD
そして、あなたが述べたように
ただし、私の変更は完全に異なるファイルに対するものであったことに言及する必要があります。私の同僚は誰もそれらに触れませんでした。
したがって、変更を加える前のコミットである I に到達するまで、RESET HEAD~1 を実行し続けることができます。コミットの後に 2 つのコミットがあるとします。これを使用してコミット I に到達できます。
git reset HEAD~3
ファイルが保存されると、これは次のようになります
(F)
I--Y--C1--C2
↑
HEAD
これで、システムからファイルを削除し、同僚のファイルを (FileSystem に既に存在するインデックスに) 追加してからコミットすることができます。そして今、開発行はあなたの変更なしのように見えるかもしれません.
(F1)
I--C3
↑
HEAD
これは推奨される方法ではありません。それを行うための推奨される方法は、
git revert HEAD^
私はそれを使用したことがないので、わかりません。
編集:それを行う別の方法。
コミット「Y」の「SHA KEY」を見つけ、その「I」の直前にコミットします。
を使用して行うことができます
git log
Y キーの場合: 7a2ab465aad23dc66a23ade897deb65a5bf9419d
、I キーの場合: 906488ac2d5a8468d725351df80e3b0f6338c9be
のように両方のコミットのタグを作成します。
git tag Intercommit -a 906488ac2d5a8468d725351df80e3b0f6338c9be
git tag YourCommit -a 7a2ab465aad23dc66a23ade897deb65a5bf9419d
を使用したチェックアウトのインターコミット
git checkout Intercommit
次に、を使用してリポジトリをリベースします
git rebase --onto HEAD YourCommit master
これで dev の行は次のようになります
I--C1--C2
↑
HEAD
1 つのコミットのリベースとリライトについて詳しく知ることができます。
http://www.kernel.org/pub/software/scm/git/docs/v1.7.3/user-manual.html#rewriting-one-commit
と
http://learn.github.com/p/rebaseing.html