あなたが持っていると仮定します：
A-B-C
これで、ビルド/テストが失敗します。修正は A にマージする必要があります。現在のワークフローは次のようになります。
$ git commit -m "fixA"
A-B-C-fixA
$ git rebase -i A~1
A で fixA をスカッシュすると、次のようになります。
A'-B-C
次のようなコマンドはありますか:
A-B-C + (index with fix for A)
$ git commit -supperdupper A
結果：
A'-B-C
以前のコミットを修正するための簡単な解決策を探しているだけなら、質問を読んでください! それはそれをすべて説明します。しかし、エルマルコは巧妙な方法を求めていたので、ここに行きます：
Git 1.7.0 の時点で、必要な機能を実行する の--autosquashオプションがありrebaseます。物事を簡単にするための--fixupと--squashオプションもあります。commitいくつかのエイリアシングを使用すると、おそらくすべてを単一のコマンドに入れることさえできます。
最高のパフォーマンスを得るには、最新の Git にアップグレードすることをお勧めします。
git/Documentation/RelNotes $ grep -i -A1 autosquash\\\|fixup *
1.7.0.txt: * "git rebase -i" learned new action "fixup" that squashes the change
1.7.0.txt- but does not affect existing log message.
--
1.7.0.txt: * "git rebase -i" also learned --autosquash option that is useful
1.7.0.txt: together with the new "fixup" action.
1.7.0.txt-
--
1.7.3.txt: * "git rebase -i" peeks into rebase.autosquash configuration and acts as
1.7.3.txt: if you gave --autosquash from the command line.
1.7.3.txt-
--
1.7.4.txt: * "git commit" learned --fixup and --squash options to help later invocation
1.7.4.txt- of the interactive rebase.
--
1.7.4.txt: * "git rebase --autosquash" can use SHA-1 object names to name which
1.7.4.txt: commit to fix up (e.g. "fixup! e83c5163").
1.7.4.txt-
git 1.7 で追加されたおよびコマンドを使いやすくするために、いくつかのエイリアスを作成しました。これらをあなたに追加してください：git commit --fixupgit commit --squash~/.gitconfig
[alias]
fixup = !sh -c 'REV=$(git rev-parse $1) && git commit --fixup $@ && git rebase -i --autosquash $REV^' -
squash = !sh -c 'REV=$(git rev-parse $1) && git commit --squash $@ && git rebase -i --autosquash $REV^' -
使用法：
$ git commit -am 'bad commit'
$ git commit -am 'good commit'
$ git add . # Stage changes to correct the bad commit
$ git fixup HEAD^ # HEAD^ can be replaced by the SHA of the bad commit
悪いコミットは、数回前のコミットである可能性があります。
私の現在の git ワークフローは非常に--fixup/--squash集中的であるためgit-fixup、煩わしいビットのほとんどを自動的に処理する新しいコマンドを作成しました。
git fixup同じファイルに触れる最新のコミットの下にグループ化された変更されたファイルを示しますgit fixup -aこれらすべての--fixup変更を、対応する「親」コミットの変更としてコミットしますgit fixup -rgit rebase --autosquashすべての修正コミットに対して自動を行います多くの変更は、上記の 3 つのコマンドだけで作業を完了するのに十分であり、コミット ID をコピーして貼り付けたり、適切なターゲットgit logを見つけるために を読んだりする必要がありません。--fixup
最後の 2 つのコミットを押しつぶしたい場合は、呼び出す必要があります
git rebase --interactive <3rd last commit>
次に、最後のコミットを選択し、最後から 2 番目のコミットをスカッシュする必要があります。履歴の最上位のコミットをつぶすことはできません。
変更を行っているブランチを他の人と共有している場合、あなたがしていることは危険です。あなたの場合、コミット A を書き直し、B と C を新しい A の上にリベースします。これは完全に新しいオブジェクトです。リポジトリの履歴が「魔法のように」変更されるため、古い A をリポジトリに既にプルした人は、リポジトリを破損する可能性があります。彼らの git は、履歴が書き換えられたことを知る方法がありません。
この事実のため、Git 開発者は、このような操作を行うことの結果を認識しておく必要があるため、意図的にこれを簡単に実行できないようにしています。
問題の根底にあるのは、git (および一般的にはバージョン管理) によって一連の変更を考えるように強制されることですが、変更セットや機能ブランチ、または関連する変更のまとまりのあるグループと呼ばれるものは、一般的に論理的に連続的ではありません。 . コードが書かれた順序は付随的なものであり、必ずしもコードを読むべき順序とは関係ありません。
私はそれに対する解決策を持っていませんが、履歴を書き換えるプロセスを自動化するのに役立つPerl スクリプトを作成しました。@MikaEloranta さんの Python スクリプトに似ていて、私が書いたときには見たこともありませんでした。
commit --fixup素晴らしいですが、十分ではありrebase --autosquashません。一連のコミットがA-B-Cあり、それらの既存のコミットの 1 つまたは複数に属する作業ツリーにさらにいくつかの変更を書き込む場合、手動で履歴を見て、どの変更がどのコミットに属するかを判断し、それらをステージングして作成する必要があります。fixup!コミットします。しかし、git はすでに、そのすべてを実行できる十分な情報にアクセスできます。
git diffスクリプト内のハンクごとgit blameに、関連する行に最後に触れたコミットを見つけるために使用しgit commit --fixup、適切なコミットを書き込むように呼び出しますfixup!。基本的に、以前に手動で行っていたのと同じことを行います。
スクリプトがハンクを単一の明確なコミットに解決できない場合、失敗したハンクとして報告され、そのハンクについては手動のアプローチに戻る必要があります。2 つの別々のコミットで行を 2 回変更した場合、スクリプトはその行の変更をそれらのコミットの最新のものに解決しますが、これは必ずしも正しい解決策ではない可能性があります。「通常の形式」機能ブランチの私見では、2 つの異なるコミットで行を 2 回変更するべきではありません。各コミットは、レビュアーを支援するために、それが触れる行の最終バージョンを提示する必要があります。ただし、バグ修正ブランチで発生する可能性があります。たとえば、foo(bar());コミット A (名前fooを に変更fox) およびコミット B (名前barを に変更) によって行が変更される可能性がありますbaz。
スクリプトが有用であると思われる場合は、お気軽に改善と反復を行ってください。いつの日か、そのような機能がgit適切に実装される可能性があります。インタラクティブなリベースによってマージの競合が発生した場合に、その競合を解決する方法を理解できるツールがあればいいのにと思います。