git-reset - クラウドでオンライン

プログラム：

NAME

git-reset - 現在の HEAD を指定された状態にリセットする

SYNOPSIS

git リセット [-q] [ ] [--] ...
git リセット (--パッチ | -p) [ ] [--] [ ...]
git リセット [--ソフト | --混合 [-N] | --ハード | --マージ | --キープ] [-q] [ ]

DESCRIPTION

XNUMX 番目と XNUMX 番目のフォームでは、次のエントリをコピーします。 インデックスに。 XNUMX番目に
フォームで、現在のブランチ ヘッド (HEAD) を、オプションでインデックスを変更し、
一致する作業ツリー。 の/ デフォルトはすべてのフォームで HEAD です。

git リセット [-q] [ ] [--] ...
このフォームは、すべてのインデックス エントリをリセットします。 での状態に. （これ
作業ツリーや現在のブランチには影響しません。)

つまり、git リセットgit add の反対です.

git reset を実行した後インデックスエントリを更新するには、次を使用できます git チェックアウト(1)
作業ツリーへのインデックスからコンテンツをチェックアウトします。 または、 ギット-
チェックアウト(1) コミットを指定すると、パスの内容を
インデックスと作業ツリーに一度にコミットします。

git リセット (--パッチ | -p) [ ] [--] [ ...]
インデックスとインデックスの違いでハンクを対話的に選択します
(デフォルトはHEAD)。 選択されたハンクは、逆にインデックスに適用されます。

これは、git reset -p が git add -p の反対であることを意味します。
ハンクを選択的にリセットします。 の「インタラクティブ モード」セクションを参照してください。 git-追加(1) 方法を学ぶ
--patch モードを操作します。

git リセット [ ] [ ]
このフォームは、現在のブランチ ヘッドを次の場所にリセットします。 そしておそらくインデックスを更新します
（のツリーにリセットします) と、それに応じた作業ツリー. もしも
は省略され、デフォルトは "--mixed" です。 の次のいずれかである必要があります。

- 柔らかい
インデックス ファイルまたは作業ツリーにはまったく触れません (ただし、ヘッドを次のようにリセットします)。
、すべてのモードと同様)。 これにより、変更されたすべてのファイルが残ります
コミットする」、として git status それを置くでしょう。

--混合
インデックスをリセットしますが、作業ツリーはリセットしません (つまり、変更されたファイルは保持されます)
コミット用にマークされていない) と、更新されていないものを報告します。 これは
デフォルトのアクション。

-N が指定されている場合、削除されたパスは追加意図としてマークされます ( git-追加（1））。

- ハード
インデックスと作業ツリーをリセットします。 作業中の追跡ファイルへの変更
以来の木破棄されます。

- マージ
インデックスをリセットし、異なる作業ツリー内のファイルを更新します
の間におよび HEAD が含まれますが、インデックス間で異なるものは保持されます
および作業ツリー (つまり、追加されていない変更があるもの)。 ファイルの場合
それは違いますインデックスにステージングされていない変更がある場合、リセットは
中止されました。

つまり、 --merge は次のようなことを行います git 読み取りツリー -u -m 、 だけど
マージされていないインデックス エントリを繰り越します。

- 保つ
インデックス エントリをリセットし、異なる作業ツリー内のファイルを更新します。
の間にそして頭。 異なるファイルの場合と頭
ローカルの変更があるため、リセットは中止されます。

ブランチの最新以外のコミットを取り消したい場合は、 git-revert(1) はあなたの
友人。

OPTIONS

-q、-quiet
静かにして、エラーのみを報告してください。

例

追加を取り消す

$編集 (1)
$ git add frotz.c filfre.c
$メールx (2)
$ git リセット (3)
$ git pull git://info.example.com/nitfol (4)

1. あなたは何かに楽しく取り組んでいて、これらのファイルの変更が
順調です。 「git diff」を実行するときにそれらを見たくありません。
他のファイルで作業していて、これらのファイルの変更が気が散る。
2. 誰かがあなたに引っ張るように頼んだら、変更はマージする価値があるように聞こえます。
3. ただし、すでにインデックスをダーティにしています (つまり、インデックスが HEAD と一致しません)。
専念）。 しかし、あなたが作ろうとしているプルはfrotz.cや
filfre.c であるため、これら XNUMX つのファイルのインデックスの変更を元に戻します。 働き方の変化
木はそこに残ります。
4. 次に、frotz.c と filfre.c の変更をそのまま残して、プルしてマージできます。
ワーキングツリー。

コミットを取り消してやり直す

$ git コミット ...
$ git restart --soft HEAD^ (1)
$編集 (2)
$ git commit -a -c ORIG_HEAD (3)

1. これは、コミットしたばかりのものが不完全であることを思い出したときに最もよく行われます。
またはコミットメッセージのスペルを間違えた、またはその両方。 作業ツリーを以前のままにします
「リセット」。
2. 作業ツリー ファイルを修正します。
3. 「リセット」は古いヘッドを .git/ORIG_HEAD にコピーします。 から始めてコミットをやり直します
ログメッセージ。 メッセージをさらに編集する必要がない場合は、 -C オプションを指定できます
を代わりにお使いください。

--amend オプションも参照してください。 git-commitとします。

コミットを元に戻し、トピックブランチにします

$ git ブランチ トピック/ウィップ (1)
$ git restart --hard HEAD~3 (2)
$ git チェックアウト トピック/ウィップ (3)

1. いくつかのコミットを行いましたが、それらが「マスター」になるには時期尚早であることに気付きました
ブランチ。 トピックブランチで磨き続けたいので、「topic/wip」を作成します。
現在の HEAD から分岐します。
2. マスターブランチを巻き戻して、これらXNUMXつのコミットを取り除きます。
3. 「topic / wip」ブランチに切り替えて、作業を続けます。

コミットを永久に取り消す

$ git コミット ...
$ git restart --hard HEAD~3 (1)

1. 最後の 2 つのコミット (HEAD、HEAD^、および HEAD~XNUMX) は不適切であり、そうしたくない
彼らに再び会うことはありません。 行う これらのコミットをすでに与えている場合は、これを行います
他の誰か。 (「UPSTREAM REBASE からのリカバリ」セクションを参照してください。 git-リベース（1）
そうすることの意味。)

マージまたはプルを元に戻す

$ git プル (1)
自動マージ nitfol
CONFLICT (コンテンツ): nitfol での競合のマージ
自動マージに失敗しました。 競合を修正してから結果をコミットします。
$ git リセット --hard (2)
$ git プル . トピック/ブランチ (3)
41223... から 13134... に更新しています...
早送り
$ git restart --hard ORIG_HEAD (4)

1. アップストリームから更新しようとすると、多くの競合が発生しました。 あなたは準備ができていませんでした
今はマージに多くの時間を費やすため、後でマージすることにします。
2. 「pull」はマージコミットを行っていないため、「git reset --hard」は「git」の同義語です。
reset --hard HEAD" は、インデックス ファイルと作業ツリーから混乱を解消します。
3. トピック ブランチを現在のブランチにマージすると、早送りになります。
4. しかし、トピック ブランチはまだ公開する準備ができていないと判断しました。
「プル」または「マージ」は、常に現在のブランチの元の先端を ORIG_HEAD に残し、
そのため、ハードにリセットすると、インデックスファイルと作業ツリーが元に戻ります
状態にし、ブランチの先端をそのコミットにリセットします。

ダーティな作業ツリー内のマージまたはプルを元に戻す

$ git プル (1)
自動マージ nitfol
再帰によるマージ。
ニトフォル | 20 +++++----
...
$ git restart --merge ORIG_HEAD (2)

1. 作業ツリーにローカルの変更がある場合でも、安全に言うことができます
他のブランチでの変更が重ならないことがわかっている場合は「git pull」
それら。
2. マージの結果を調べた後、他の変更が見られる場合があります。
ブランチが不十分です。 「git reset --hard ORIG_HEAD」を実行すると、元に戻ることができます
どこにいても、ローカルの変更は破棄されますが、これは望ましくありません。 "ギット
reset --merge" は、ローカルの変更を保持します。

中断されたワークフロー
ある問題の最中に、緊急の修正要求によって中断されたとします。
大きな変化。 作業ツリー内のファイルは、まだコミットできる形になっていません。
しかし、迅速なバグ修正のために他のブランチにアクセスする必要があります。

$ git checkout feature ;# "feature" ブランチで作業していて、
$ work work work ;# 中断されました
$ git commit -a -m "スナップショット WIP" (1)
$ git チェックアウト マスター
$ 修正修正修正
$ git commit ;# 実際のログでコミット
$ git チェックアウト機能
$ git reset --soft HEAD^ ;# WIP 状態に戻る (2)
$ git リセット (3)

1. このコミットは吹き飛ばされるため、ログ メッセージを破棄しても問題ありません。
2. これにより、 WIP コミット履歴からコミットし、作業ツリーを
そのスナップショットを作成する直前の状態。
3. この時点で、インデックス ファイルには、コミットしたすべての WIP 変更が残っています。
スナップショット WIP. これにより、インデックスが更新され、WIP ファイルが未コミットとして表示されます。

参照 git スタッシュとします。

インデックス内の単一のファイルをリセットする
ファイルをインデックスに追加したが、後で追加しないことにしたとします。
それをあなたのコミットに。 変更を保持したまま、インデックスからファイルを削除できます
gitリセットで。

$ git リセット -- frtz.c (1)
$ git commit -m "インデックス内のファイルをコミット" (2)
$ git add frtz.c (3)

1. これにより、ファイルが作業ディレクトリに保持されたまま、インデックスからファイルが削除されます。
2. これにより、インデックス内の他のすべての変更がコミットされます。
3. ファイルをインデックスに再度追加します。

以前のいくつかのコミットを破棄しながら、作業ツリーの変更を保持します
何かに取り組んでいて、それをコミットしてから、作業を続けたとします。
もう少しですが、作業ツリーにあるものは
以前にコミットしたものとは関係のない別のブランチ。 あなたはできる
新しいブランチを開始し、作業ツリーの変更を維持しながらリセットします。

$ git タグの開始
$ git チェックアウト -b branch1
$編集
$ git コミット ... (1)
$編集
$ git チェックアウト -b branch2 (2)
$ git reset --keep 開始 (3)

1. これにより、branch1 での最初の編集がコミットされます。
2. 理想的な世界では、以前のコミットが属していないことに気付くことができたはずです
branch2 を作成して切り替えたときに新しいトピックに移動します (つまり、「git checkout -b
branch2 start") ですが、完璧な人はいません。
3. ただし、「reset --keep」を使用して、切り替えた後に不要なコミットを削除できます
「ブランチ2」。

考察

以下の表は、実行時に何が起こるかを示しています。

git reset --option ターゲット

HEAD を別のコミット (ターゲット) にリセットするには、さまざまなリセット オプションを使用します。
ファイルの状態。

これらの表では、A、B、C、および D は、ファイルのいくつかの異なる状態です。 たとえば、最初の
最初のテーブルの行は、ファイルが作業ツリーで状態 A にある場合、状態 B であることを意味します。
インデックスで、HEAD で状態 C、ターゲットで状態 D の場合、「git reset --soft
target」は、ファイルを状態 A で作業ツリーに残し、状態 B でインデックスに残します。
HEAD (つまり、現在のブランチにいる場合はその先端) をリセット (つまり、移動) します。
「ターゲット」（状態Dのファイルを持っています）。

作業インデックス HEAD ターゲット作業インデックス HEAD
-------------------------------------------------- -
ABCD --ソフト ABD
--混合追加
--ハード DDD
--merge (許可されない)
--keep (許可されない)

作業インデックス HEAD ターゲット作業インデックス HEAD
-------------------------------------------------- -
ABCC -- ソフト ABC
--混合ACC
--ハード CCC
--merge (許可されない)
--ACCを保持

作業インデックス HEAD ターゲット作業インデックス HEAD
-------------------------------------------------- -
BBCD -- ソフト BBD
--混合 BDD
--ハード DDD
--DDD をマージ
--keep (許可されない)

作業インデックス HEAD ターゲット作業インデックス HEAD
-------------------------------------------------- -
BBCC -- ソフト BBC
--混合BCC
--ハード CCC
-- CCC をマージ
--BCCを保持

作業インデックス HEAD ターゲット作業インデックス HEAD
-------------------------------------------------- -
BCCD -- ソフト BCD
--混合 BDD
--ハード DDD
--merge (許可されない)
--keep (許可されない)

作業インデックス HEAD ターゲット作業インデックス HEAD
-------------------------------------------------- -
BCCC -- ソフト BCC
--混合BCC
--ハード CCC
--BCCをマージ
--BCCを保持

「reset --merge」は、競合するマージからリセットするときに使用することを意図しています。 任意のマージ
操作は、マージに関与する作業ツリー ファイルが変更されないことを保証します。
開始前にインデックスをローカルに変更し、結果を
ワーキングツリー。 したがって、インデックスとターゲットの間に何らかの違いが見られた場合、さらに
インデックスと作業ツリーの間で、それは私たちがからリセットしていないことを意味します
競合で失敗した後、マージ操作が終了したことを示します。 それが私たちが許可しない理由です
この場合は --merge オプション。

「reset --keep」は、現在の最後のコミットの一部を削除するときに使用することを意図しています
作業ツリーの変更を保持しながら分岐します。 間で競合が発生する可能性がある場合は、
削除したいコミットの変更と作業ツリーの変更
キープ、リセットは許可されていません。 そのため、両方の変更がある場合は許可されません
作業ツリーと HEAD の間、および HEAD とターゲットの間。 安全のためにも、
マージされていないエントリがある場合は許可されません。

次の表は、マージされていないエントリがある場合に何が起こるかを示しています。

作業インデックス HEAD ターゲット作業インデックス HEAD
-------------------------------------------------- -
XUAB --soft (許可されない)
--混合 XBB
--ハード BBB
--BBB をマージ
--keep (許可されない)

作業インデックス HEAD ターゲット作業インデックス HEAD
-------------------------------------------------- -
XUAA --soft (許可されない)
--混合XAA
--ハード AAA
-- AAA をマージ
--keep (許可されない)

X は任意の状態を意味し、U はマージされていないインデックスを意味します。

GIT

の一部 git（1）スイート

onworks.net サービスを使用してオンラインで git-reset を使用する