Gitコードロールバックについて
git rebase-iおよびgit cherry-pickを用いてコードロールバックを実現する方法について述べた.コードロールバックは高危険操作に属し、慎重に使用することをお勧めします.
サンプルソースファイルのダウンロード
どうしてこんな文章を書いたのですか.実際には,1回の反復でn個の需要を並列に開発し,抽出時に各需要のコードが次々とテスト分岐に統合された歴史がある.生活はもともと穏やかだったが、2日後にテストのリーダーは「私たちのグループは少し状況が発生し、今回の反復の需要は規定時間内に測定できないが、ボスはまたオンライン時間を強制的に要求し、優先度の低い需要のコードをテスト分岐から抽出しよう」と話した.当时は本当に心の中で1万匹のXXXが漂っていました...
上記のシナリオをシミュレートすると,反復中に3つの需要feature 1,feature 2,feature 3を並列に開発し,それぞれの開発ブランチに無事である(テストブランチをmasterと仮定する).
ここでfeature 2とfeature 3は同じファイルを修正する必要があります.私たちはわざと衝突を作りました.
測定時間になり、feature 1のコードがテストブランチにマージされました.
feature 1が1つのバグを修復した後、feature 2も測定した.
その後、feature 3も測定し、feature 3のコードを統合すると、製造されたばかりの衝突が爆発した.
競合を解決してコードをマージする必要があります.
feature 3の測定後、いくつかのバグを修正しました.
もちろん、feature 2は測定されたがテストには入らず、bugの修復はfeature 1とfeature 3に対するものである.
この場合、feature 2のテストは正常に行われず、コードをテストブランチから抽出する必要があります...
念のため、feature 2ブランチをバックアップします.
feature 2-copyブランチのコミット記録を見てみましょう.
最新の3つのコミットをロールバックする必要があります(3つのfeatureの開発ブランチはいずれも最初のコミットの時点から切り取られているため)、もちろん現実的にはあるニーズに対するコミットは3つだけではありません.もし1つ1つのrevertを提出するならばそんなに仕事量が感動的で、私達はどうしてn個のcommitを1つのcommitに合併してそれから一緒にrevertしませんか?
git rebase-iを使用してcommitをマージするには、ロールバックするcommitのhashcodeを接続する必要があります.
次に、次のダイアログ・ボックスが表示されます.
最新2回コミットされたcommandをsに変更する必要があります.
変更後に保存して終了するには、次のダイアログボックスに進みます.
最初に提出したcommit messageを変更する必要があります.
変更後に保存して終了し、feature 2-copyブランチのコミットレコードを再度表示します.
3回の提出で合併に成功し、おめでとうございます!次にrevertがマージされたコミットが必要です.
保存して終了し、feature 2-copyブランチのコミットレコードを再度表示します.
このとき、feature 2-copyをテストブランチに統合すればfeature 2のコードを抽出できると思いますが、そうではありません.正しい方法はgit cherry-pickを使用してfeature 2-copyブランチ上のrevertコミットをテストブランチにマージすることです.
このときfeature 2のコードはテストブランチから抽出に成功した.
最後にGitグラフィックスクライアント:GitUpをお勧めします
作者:小にゃん
私の裏庭:https://sunmengyuan.github.io...
私のgithub:https://github.com/sunmengyuan
テキストリンク:https://sunmengyuan.github.io...
サンプルソースファイルのダウンロード
どうしてこんな文章を書いたのですか.実際には,1回の反復でn個の需要を並列に開発し,抽出時に各需要のコードが次々とテスト分岐に統合された歴史がある.生活はもともと穏やかだったが、2日後にテストのリーダーは「私たちのグループは少し状況が発生し、今回の反復の需要は規定時間内に測定できないが、ボスはまたオンライン時間を強制的に要求し、優先度の低い需要のコードをテスト分岐から抽出しよう」と話した.当时は本当に心の中で1万匹のXXXが漂っていました...
上記のシナリオをシミュレートすると,反復中に3つの需要feature 1,feature 2,feature 3を並列に開発し,それぞれの開発ブランチに無事である(テストブランチをmasterと仮定する).
ここでfeature 2とfeature 3は同じファイルを修正する必要があります.私たちはわざと衝突を作りました.
測定時間になり、feature 1のコードがテストブランチにマージされました.
feature 1が1つのバグを修復した後、feature 2も測定した.
その後、feature 3も測定し、feature 3のコードを統合すると、製造されたばかりの衝突が爆発した.
競合を解決してコードをマージする必要があります.
feature 3の測定後、いくつかのバグを修正しました.
もちろん、feature 2は測定されたがテストには入らず、bugの修復はfeature 1とfeature 3に対するものである.
この場合、feature 2のテストは正常に行われず、コードをテストブランチから抽出する必要があります...
念のため、feature 2ブランチをバックアップします.
git checkout feature2
git checkout -b feature2-copyfeature 2-copyブランチのコミット記録を見てみましょう.
git log最新の3つのコミットをロールバックする必要があります(3つのfeatureの開発ブランチはいずれも最初のコミットの時点から切り取られているため)、もちろん現実的にはあるニーズに対するコミットは3つだけではありません.もし1つ1つのrevertを提出するならばそんなに仕事量が感動的で、私達はどうしてn個のcommitを1つのcommitに合併してそれから一緒にrevertしませんか?
git rebase-iを使用してcommitをマージするには、ロールバックするcommitのhashcodeを接続する必要があります.
git rebase -i e08ddaf558b9ad84422db5e4b620dcab97623fde次に、次のダイアログ・ボックスが表示されます.
最新2回コミットされたcommandをsに変更する必要があります.
変更後に保存して終了するには、次のダイアログボックスに進みます.
最初に提出したcommit messageを変更する必要があります.
変更後に保存して終了し、feature 2-copyブランチのコミットレコードを再度表示します.
3回の提出で合併に成功し、おめでとうございます!次にrevertがマージされたコミットが必要です.
git revert e544464c3de69adef5ca7556001abebaf40b218b保存して終了し、feature 2-copyブランチのコミットレコードを再度表示します.
このとき、feature 2-copyをテストブランチに統合すればfeature 2のコードを抽出できると思いますが、そうではありません.正しい方法はgit cherry-pickを使用してfeature 2-copyブランチ上のrevertコミットをテストブランチにマージすることです.
git checkout master
git cherry-pick b309f7944d2422d8fe647dca61bda518b192628fこのときfeature 2のコードはテストブランチから抽出に成功した.
最後にGitグラフィックスクライアント:GitUpをお勧めします
作者:小にゃん
私の裏庭:https://sunmengyuan.github.io...
私のgithub:https://github.com/sunmengyuan
テキストリンク:https://sunmengyuan.github.io...