Git Part 2について


ResetとRevertについて


リセット:特定の過去の時点に戻る
Revert:変更のコミットの特定の履歴ポイントに戻る
デフォルトでは、この2つのコマンドは、過去の時点を返すために使用されます.
両者には明らかな違いがある.ちょっと聞きに行きましょう.

Resetについて


resetの場合、過去に戻る方法は3つあります.
方法によって、変化も違います.
オプションWorking Directory Staging Area Local Repositor--ソフト変更なしリセットポイントなし(commit id)--ハイブリッド変更なしリセットポイント(commit id)リセットポイント(commit id)--リセットポイント(commit id)リセットポイント(commit id)
明確な理解を得るために、例を通して詳しく説明しましょう.

現在HEADはMainBranchが指す274 aaccを指す.
この状態で、Working Directoryは追加のコード作成を行い、変更が発生しました.
このとき、
git reset --hard Da3de11
実行する場合

Working Directoryだけでなく、Staging AreaとLocal RepositoryもDa 3 de 11時に戻ります.
逆に、
git reset (--mixed) Da3de11
(reset의 default값은 --mixed이므로 생략 가능)
の場合、Working Directoryのみが変更され、残りはDa 3 de 11コミットポイントに戻ります.
最後に、
git reset --soft Da3de11
(reset의 default값은 --mixed이므로 생략 가능)
この場合、ローカルレポートのみがDa 3 de 11コミットポイントを返します.
最終的にresetを使用する場合は、次の要因を考慮してオプションを決定および使用します.
  • コード変更ステータスを適用するかどうか
  • Working Directoryのみ変更はありますか?
  • 変更は
  • 作業ディレクトリ+常駐領域に適用されましたか?
  • 作業ディレクトリ+駐在領域+ローカルレポート?
  • 開発者のリセット目的
  • 作業ディレクトリ、常駐領域、およびローカルレポートで、ある時点にリカバリできるターゲットはどれですか?
  • 🤔 リセットエラーの場合はどうすればいいですか?


    次のHEADは90 ac 000にコミットされていました.
    git reset --hard 48ea1f3
    4 8 ea 1 f 3のコミット時間によって返される状態が表示される.

    option Yes--ハードなので、ローカルレポートからWorking Directoryまで48 ea 1 f 3時点に変更されました.
    しかしリセットミスで元の状態に戻りたい場合はどうすればいいのでしょうか?
    パニックの気持ちでまず、
    git log
    入力してみましたが、リセットされて元の状態に戻りたいcommitは全く見えません...私たちは涙を浮かべてコードを書き直すべきですか?
    いいえ.復元できます.「git reflect」と「git reset」を使用して「再リセット」できます.

    🤔 git reflog

  • reference log
  • Gitログとは異なり、
  • には、1回のコミットでも、現在のリポジトリツリーでは一般的ではないすべてのコミットが表示されます.
    したがって、まずgit reflectによりリセットにより失われたコミットIDを検索する、次いでである.
    git reset --hard (유실된 commit id)
    それによって元の姿に戻ることができます.

    RESETの特徴を再整理すると…。

  • Git reset--soft:ローカルRepoのみ
  • をリフレッシュ
  • Git reset--ブレンド:ローカルRepo+Stating Areaのみ
  • をリフレッシュ
  • Git reset--hard:Working Directory
  • をすべてリセット
  • エラーリセットのリカバリもリセット可能
  • Git再記録により、まず紛失したコミットID
  • をチェックする.
  • Git reset--hard(失われたコミットID)により
  • を復元する.

    リセットの注意!

  • の提出時点が異なるため、連携には注意が必要です
  • リセット時にローカルレポートが変更され、リモートレポートと一致せず、競合する可能性のある複数の

  • したがって、
  • は、「リモート・買い戻し前にプッシュ」の場合に使用することが望ましい.「リモート・買い戻しを単独で使用するか、チーム・メンバーと協議する」場合は、
  • である.
    git push --force
    解決することによって

    Revertについて


    resetとは異なり、revertの核心はオプションがなく、変更のコミットを残して過去の時点に戻ることです.resetとの比較で知っておきます.

    この状態で、Da 3 de 11コミットポイントに戻ります.
    まず、resetの場合、戻るコミットポイントにHEADを指します.もちろん、失われたcommit idはgit reflectで検証できます.

    次に、revertの状況を見てみましょう.
    revertの場合、変更コミットを保持しながら、返す時点と同じ内容として作成します.
    過去の時点でのコミット内容と同様にするために、最近の時点でのコミットから、これらの内容を相殺する変更コミットが順次作成されるものと理解される.
    したがって、実行結果は過去の時点でコミットされた内容と一致するが、resetとは異なり、HEADは将来の時点のコミットを指す.
    次の図が表示されます.
    git revert 274aacc...Da3de11
    実行結果を図に示します.

    REVERTの特徴を再整理すると…。

  • が過去のコミットポイントに戻った場合、resetとは異なり、変更履歴を保持し、
  • に戻る
  • コードの時点は過去になり、コミットは未来になります.
  • リセットとは異なり、
  • は競合のないリモート・レポートのプッシュを提供します.
  • コラボレーションでは、
  • を一時的にリセットするのではなく、リストアすることを推奨します.
  • ただし、revertの使用が適切でない場合、競合が発生する可能性があります.
  • e.g.過去の時点の特定のコミットのみを復元する(推奨しない)
  • .

    🤔 git commit --amend


    最新のコミットの簡単な変更方法
  • は、新規コミットを個別に作成するのではなく、既存の最新コミット
  • を修正する.
  • 使用例
  • commitのメッセージを変更したい場合
  • git commit-[修正]コマンド後のメッセージ修正後のcommit
  • に提出されたファイルは、コードを変更したい場合は
  • Git addコマンドまず駐在領域
  • を変更する
  • 以降git comit--modifyコマンドを入力し、
  • を再発行します.
  • 修正前の最新のコミットがリモートrepoにプッシュされた場合、修正後にgit commit-修正後に競合
  • が発生することに注意してください.