SYNOPSIS

git reset [-q] [<tree-ish>] [--] <pathspec>...
git reset [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]
git reset (--patch | -p) [<tree-ish>] [--] [<pathspec>...]
git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]

DESCRIPTION

In the first three forms, copy entries from <tree-ish> to the index. In the last form, set the current branch head (HEAD) to <commit>, optionally modifying index and working tree to match. The <tree-ish>/<commit> defaults to HEAD in all forms.

git reset [-q] [<tree-ish>] [--] <pathspec>...
git reset [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]

These forms reset the index entries for all paths that match the <pathspec> to their state at <tree-ish>. (It does not affect the working tree or the current branch.)

これは、 git reset <pathspec> が git add <pathspec> の反対であることを意味します。 このコマンドは、 git restore [--source=<tree-ish>] --staged <pathspec>... と同等です。

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

git reset (--patch | -p) [<tree-ish>] [--] [<pathspec>...]

Interactively select hunks in the difference between the index and <tree-ish> (defaults to HEAD). The chosen hunks are applied in reverse to the index.

This means that git reset -p is the opposite of git add -p, i.e. you can use it to selectively reset hunks. See the "Interactive Mode" section of git-add(1) to learn how to operate the --patch mode.

git reset [<mode>] [<commit>]

This form resets the current branch head to <commit> and possibly updates the index (resetting it to the tree of <commit>) and the working tree depending on <mode>. Before the operation, ORIG_HEAD is set to the tip of the current branch. If <mode> is omitted, defaults to --mixed. The <mode> must be one of the following:

--soft

Does not touch the index file or the working tree at all (but resets the head to <commit>, just like all modes do). This leaves all your changed files "Changes to be committed", as git status would put it.

--mixed

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

-N が指定されている場合、削除されたパスは intent-to-add としてマークされます(git-add(1) 参照)。

--hard

Resets the index and working tree. Any changes to tracked files in the working tree since <commit> are discarded. Any untracked files or directories in the way of writing any tracked files are simply deleted.

--merge

Resets the index and updates the files in the working tree that are different between <commit> and HEAD, but keeps those which are different between the index and working tree (i.e. which have changes which have not been added). If a file that is different between <commit> and the index has unstaged changes, reset is aborted.

言い換えると、 --merge は git read-tree -u -m <commit> のような操作を行い、 未マージのインデックス・エントリを保持します。

--keep

Resets index entries and updates files in the working tree that are different between <commit> and HEAD. If a file that is different between <commit> and HEAD has local changes, reset is aborted.

--recurse-submodules
--no-recurse-submodules

When the working tree is updated, using ‘--recurse-submodules` will also recursively reset the working tree of all active submodules according to the commit recorded in the superproject, also setting the submodules’ HEAD to be detached at that commit.

3つのコマンドの違いについては、 git(1) の「Reset, restore and revert」を参照してください。

OPTIONS

-q
--quiet

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

--refresh
--no-refresh

混合リセット(mixed reset)後にインデックスを更新します。 デフォルトで有効になっています。

--pathspec-from-file=<file>

Pathspec is passed in <file> instead of commandline args. If <file> is exactly - then standard input is used. Pathspec elements are separated by LF or CR/LF. Pathspec elements can be quoted as explained for the configuration variable core.quotePath (see git-config(1)). See also --pathspec-file-nul and global --literal-pathspecs.

--pathspec-file-nul

Only meaningful with --pathspec-from-file. Pathspec elements are separated with NUL character and all other characters are taken literally (including newlines and quotes).

-U<n>
--unified=<n>

コンテキストの「<n>行」の diff を生成します。 デフォルトは diff.context 、 または構成オプションが設定されていない場合は 3 です。

--inter-hunk-context=<n>

指定の「<number>行」までの diff ハンク間のコンテキストを表示し、 それによって互いに近いハンクを融合します。 デフォルトは diff.interHunkContext 、 または構成オプションが設定されていない場合は 0 です。

--

これ以降の引数をオプションとして解釈しないでください。

<pathspec>...

操作の影響を受けるパスを制限します。

詳細については、 gitglossary(7) の「pathspec」エントリを参照してください。

EXAMPLES

addを取り消し(undo add) 
$ edit                                     <1>
$ git add frotz.c filfre.c
$ mailx                                    <2>
$ git reset                                <3>
$ git pull git://info.example.com/ nitfol  <4>

  1. あなたは喜んで何かに取り組んでおり、これらのファイルの変更が適切に行われていることがわかります。 あなたが git diff を実行するときにそれらを表示したくないのは、他のファイルで作業することを計画していて、これらのファイルでの変更が気を散らすためです。

  2. 誰かがあなたにプルを要求し、その変更がマージに値すると思われる場合。

  3. しかしながら、あなたはすでにインデックスをダーティにしています(つまり、インデックスが HEAD コミットと一致していません)。 ただし、これから行うプルは frotz.c または filfre.c には影響しないため、これら2つのファイルのインデックスの変更を元に戻します。 作業ツリーのあなたの変更はそのまま残ります。

  4. それから、あなたは frotz.c と filfre.c の変更を作業ツリーに残したまま、プルしてマージできます。

コミットを取り消し、再度行う(undo a commit and redo) 
$ git commit ...
$ git reset --soft HEAD^      <1>
$ edit                        <2>
$ git commit -a -c ORIG_HEAD  <3>

  1. これは、コミットした内容が不完全であることを思い出した場合、コミットメッセージのスペルを間違えた場合、またはその両方の場合に最もよく行われます。 「リセット」前の状態で作業ツリーを残します。

  2. 作業ツリーファイルを修正します。

  3. 「リセット」は古いヘッドを .git/ORIG_HEAD にコピーします。 ログメッセージから始めて、コミットをやり直します。 メッセージをさらに編集する必要がない場合は、代わりに -C オプションを指定できます。

    git-commit(1) の --amend オプションも参照してください。

コミットを取り消し(undo)、トピックブランチにします 
$ git branch topic/wip          <1>
$ git reset --hard HEAD~3       <2>
$ git switch topic/wip          <3>

  1. あなたはいくつかのコミットをしましたが、それらが master ブランチに入るのは時期尚早であることに気づきました。 あなたはトピックブランチでそれらを磨き続けたいので、現在の HEAD から topic/wip ブランチを作成します。

  2. masterブランチを巻き戻して、これら3つのコミットを取り除きます。

  3. topic/wip ブランチに切り替えて、作業を続けます。

コミットを永久に取り消す(undo commits permanently) 
$ git commit ...
$ git reset --hard HEAD~3   <1>

  1. 最後の3コミット(HEAD と HEAD^ と HEAD~2)は悪かったので、二度と見たくありません。 あなたがこれらのコミットを他の誰かにすでに与えている場合は、これを行ってはいけません。 (そうすることの意味については、 git-rebase(1) の「RECOVERING FROM UPSTREAM REBASE」セクションを参照してください。)

マージまたはプルを取り消す(undo a merge or pull) 
$ git pull                         <1>
Auto-merging nitfol
CONFLICT (content): Merge conflict in nitfol
Automatic merge failed; fix conflicts and then commit the result.
$ git reset --hard                 <2>
$ git pull . topic/branch          <3>
Updating from 41223... to 13134...
Fast-forward
$ git reset --hard ORIG_HEAD       <4>

  1. 上流から更新しようとすると、多くの競合が発生しました。 あなたは現在、マージに多くの時間を費やす準備ができていなかったため、後でマージすることにしました。

  2. 「プル」はマージコミットを行っていないため、 git reset--hard HEAD の同義語である git reset --hard は、インデックスファイルと作業ツリーから混乱を取り除きます。

  3. トピックブランチを現在のブランチにマージします。これにより、早送り(fast-forward)が行われました。

  4. しかし、あなたはそのトピックブランチがまだ一般公開の準備ができていないと判断しました。 「pull」または「merge」は常に現在のブランチの元の先端を ORIG_HEAD に残すため、ハードにリセットするとインデックスファイルと作業ツリーがその状態に戻り、ブランチの先端がそのコミットにリセットされます。

ダーティな作業ツリー内でマージまたはプルを取り消し(undo) 
$ git pull                         <1>
Auto-merging nitfol
Merge made by recursive.
 nitfol                |   20 +++++----
 ...
$ git reset --merge ORIG_HEAD      <2>

  1. 作業ツリーにローカルの変更がある場合でも、他のブランチの変更がそれらと重複していないことがわかっている場合は、「git pull」と安全に言うことができます。

  2. マージの結果を調べた後、他のブランチでの変更が不十分であることがわかる場合があります。 git reset --hard ORIG_HEAD を実行すると、元の場所に戻ることができますが、不要なローカルの変更は破棄されます。 git reset --merge は、ローカルの変更を保持します。

Interrupted workflow

あなたが大規模な変更をしている最中に、緊急の修正リクエストによって中断されたとします。 作業ツリー内のファイルはまだコミットできる形ではありませんが、バグをすばやく修正するには、他のブランチにアクセスする必要があります。

$ git switch feature  ;# you were working in "feature" branch and
$ work work work      ;# got interrupted
$ git commit -a -m "snapshot WIP"                 <1>
$ git switch master
$ fix fix fix
$ git commit ;# commit with real log
$ git switch feature
$ git reset --soft HEAD^ ;# go back to WIP state  <2>
$ git reset                                       <3>

  1. このコミットは吹き飛ばされちゃうので、投げやりなログメッセージでOKです。

  2. これにより、コミット履歴から「WIP」コミットが削除され、作業ツリーがスナップショットを作成する直前の状態に設定されます。

  3. この時点で、インデックスファイルには「スナップショットWIP」としてコミットしたすべてのWIP変更がまだ含まれています。 これにより、インデックスが更新され、WIPファイルがコミットされていないものとして表示されます。

    git-stash(1) も参照して下さい。

Reset a single file in the index

インデックスにファイルを追加したが、後でそれをコミットに追加したくないと判断したとします。 git resetを使用して変更を保持しながら、ファイルをインデックスから削除できます。

$ git reset -- frotz.c                      <1>
$ git commit -m "Commit files in index"     <2>
$ git add frotz.c                           <3>

  1. これにより、ファイルは作業ディレクトリに保持されたまま、インデックスから削除されます。

  2. これにより、インデックス内の他のすべての変更がコミットされます。

  3. そのファイルをインデックスに再度追加します。

以前のコミットを破棄しつつ作業ツリーの変更を保持する

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

$ git tag start
$ git switch -c branch1
$ edit
$ git commit ...                            <1>
$ edit
$ git switch -c branch2                     <2>
$ git reset --keep start                    <3>

  1. これにより、branch1 にあなたの最初の編集がコミットされます。

  2. 理想的な世界では、 あなたが branch2 (つまり、 git switch -c branch2 start)を作成して切り替えたときに、以前のコミットが新しいトピックに属していないことに気付くかもしれませんが、完璧な人は誰もいません。

  3. しかし、 あなたが branch2 に切り替えた後は、 reset --keep を使用して不要なコミットを削除できます。

コミット(a commit)を一連のコミット(a sequence of commits)に分割

論理的に別々の変更をたくさん作成し、それらを一緒にコミットしたとします。 次に、後で、各論理チャンクを独自のコミットに関連付ける方がよい場合があると判断したとします。 あなたが git reset を使用すると、ローカルファイルの内容を変更せずに履歴を巻き戻すことができます。その後、git add -p を使用して各コミットに含めるハンクを対話的に選択し、 git commit -c でコミットメッセージをあらかじめ入力しておくことができます。

$ git reset -N HEAD^                        <1>
$ git add -p                                <2>
$ git diff --cached                         <3>
$ git commit -c HEAD@{1}                    <4>
...                                         <5>
$ git add ...                               <6>
$ git diff --cached                         <7>
$ git commit ...                            <8>

  1. First, reset the history back one commit so that we remove the original commit, but leave the working tree with all the changes. The -N ensures that any new files added with HEAD are still marked so that git add -p will find them.

  2. 次に、 私達は git add -p 機能を使用して、追加するdiffハンクを対話的に選択します。 これにより、各diffハンクについて順番に尋ねられ、「はい、これを含める」、「いいえ、これを含めない」、または非常に強力な「編集」機能などの簡単なコマンドを使用できます。

  3. あなたが含めたいハンクに満足したら、 git diff --cached を使用して、最初のコミットのために何が準備されているかを確認する必要があります。 これは、インデックスに移動され、コミットされようとしているすべての変更を示しています。

  4. 次に、インデックスに保存されている変更をコミットします。 -c オプションは、最初のコミットで開始した元のメッセージからコミットメッセージを事前入力することを指定します。 これは、再入力を避けるのに役立ちます。 HEAD@{1} は、元のリセットコミット(1変更前)の前に HEAD が使用されていたコミットの特別な表記です。 詳細については、 git-reflog(1) を参照してください。 他の有効なコミット参照を使用することもできます。

  5. あなたは手順2〜4を複数回繰り返して、元のコードを任意の数のコミットに分割できます。

  6. さて、あなたは多くの変更をそれぞれのコミットに分割したので、残りの未コミットの変更をすべて選択するために、もはや git add のパッチモードは使用しないかもしれません。

  7. もう一度、必要なものが含まれていることを確認してください。 また、git diffにて後でコミットする残りの変更が表示されないことを確認することもできます。

  8. そして最後に最終コミットを作成します。

DISCUSSION

下記の表達は、 以下のコマンドの実行時に何が起こるかを示します:

git reset --option target

これは、 ファイルの状態に応じて異なるリセット・オプション(--option)を使用して、 HEAD を別のコミット(target)にリセットします。

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

working index HEAD target         working index HEAD
----------------------------------------------------
 A       B     C    D     --soft   A       B     D
                          --mixed  A       D     D
                          --hard   D       D     D
                          --merge (disallowed)
                          --keep  (disallowed)
working index HEAD target         working index HEAD
----------------------------------------------------
 A       B     C    C     --soft   A       B     C
                          --mixed  A       C     C
                          --hard   C       C     C
                          --merge (disallowed)
                          --keep   A       C     C
working index HEAD target         working index HEAD
----------------------------------------------------
 B       B     C    D     --soft   B       B     D
                          --mixed  B       D     D
                          --hard   D       D     D
                          --merge  D       D     D
                          --keep  (disallowed)
working index HEAD target         working index HEAD
----------------------------------------------------
 B       B     C    C     --soft   B       B     C
                          --mixed  B       C     C
                          --hard   C       C     C
                          --merge  C       C     C
                          --keep   B       C     C
working index HEAD target         working index HEAD
----------------------------------------------------
 B       C     C    D     --soft   B       C     D
                          --mixed  B       D     D
                          --hard   D       D     D
                          --merge (disallowed)
                          --keep  (disallowed)
working index HEAD target         working index HEAD
----------------------------------------------------
 B       C     C    C     --soft   B       C     C
                          --mixed  B       C     C
                          --hard   C       C     C
                          --merge  B       C     C
                          --keep   B       C     C

git reset --merge is meant to be used when resetting out of a conflicted merge. Any mergy operation guarantees that the working tree file that is involved in the merge does not have a local change with respect to the index before it starts, and that it writes the result out to the working tree. So if we see some difference between the index and the target and also between the index and the working tree, then it means that we are not resetting out from a state that a mergy operation left after failing with a conflict. That is why we disallow --merge option in this case.

git reset --keep is meant to be used when removing some of the last commits in the current branch while keeping changes in the working tree. If there could be conflicts between the changes in the commit we want to remove and the changes in the working tree we want to keep, the reset is disallowed. That’s why it is disallowed if there are both changes between the working tree and HEAD, and between HEAD and the target. To be safe, it is also disallowed when there are unmerged entries.

以下の表達は、 未マージ・エントリがある場合に何が起こるかを示しています:

working index HEAD target         working index HEAD
----------------------------------------------------
 X       U     A    B     --soft  (disallowed)
                          --mixed  X       B     B
                          --hard   B       B     B
                          --merge  B       B     B
                          --keep  (disallowed)
working index HEAD target         working index HEAD
----------------------------------------------------
 X       U     A    A     --soft  (disallowed)
                          --mixed  X       A     A
                          --hard   A       A     A
                          --merge  A       A     A
                          --keep  (disallowed)

X は任意の状態を意味し、 U は未マージ・インデックス(unmerged index)を意味します。

GIT

Part of the git(1) suite