セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット作成
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ適用
デバッグ
外部システム
サーバー管理
- 2.39.4 → 2.49.0 変更なし
-
2.39.3
2023-04-17
- 2.36.1 → 2.39.2 変更なし
-
2.36.0
2022-04-18
- 2.34.1 → 2.35.8 変更なし
-
2.34.0
2021-11-15
- 2.27.1 → 2.33.8 変更なし
-
2.27.0
2020-06-01
- 2.25.1 → 2.26.3 変更なし
-
2.25.0
2020-01-13
- 2.23.1 → 2.24.4 変更なし
-
2.23.0
2019-08-16
- 2.22.1 → 2.22.5 変更なし
-
2.22.0
2019-06-07
- 2.21.1 → 2.21.4 変更なし
-
2.21.0
2019-02-24
- 2.20.1 → 2.20.5 変更なし
-
2.20.0
2018-12-09
- 2.15.4 → 2.19.6 変更なし
-
2.14.6
2019-12-06
-
2.13.7
2018-05-22
-
2.12.5
2017-09-22
- 2.1.4 → 2.11.4 変更なし
-
2.0.5
2014-12-17
概要
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>]
説明
最初の3つの形式では、<tree-ish> からインデックスにエントリをコピーします。最後の形式では、現在のブランチヘッド (HEAD) を <commit> に設定し、オプションでインデックスと作業ツリーを一致させるように変更します。<tree-ish>/<commit> は、すべての形式でデフォルトで HEAD になります。
- git reset [-q] [<tree-ish>] [--] <pathspec>…
- git reset [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]
-
これらの形式は、
<pathspec>に一致するすべてのパスのインデックスエントリを、<tree-ish>における状態にリセットします。(作業ツリーや現在のブランチには影響しません。)これは、
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>…]
-
インデックスと
<tree-ish>(デフォルトはHEAD) の間の差分でハンクを対話的に選択します。選択されたハンクは、インデックスに逆向きに適用されます。これは、
git reset -pがgit add -pの逆、つまり、ハンクを選択的にリセットするために使用できることを意味します。--patchモードの操作方法については、git-add[1] の「対話モード」セクションを参照してください。 - git reset [<mode>] [<commit>]
-
この形式は、現在のブランチヘッドを
<commit>にリセットし、<mode>に応じてインデックス (<commit>のツリーにリセットする) および作業ツリーを更新する可能性があります。操作前に、ORIG_HEADは現在のブランチの先端に設定されます。<mode>が省略された場合、デフォルトは--mixedです。<mode>は以下のいずれかでなければなりません- --soft
-
インデックスファイルや作業ツリーにはまったく触れません (ただし、すべてのモードと同様に、ヘッドを
<commit>にリセットします)。これにより、変更されたすべてのファイルはgit statusが示すように「コミットされる変更」として残されます。 - --mixed
-
インデックスをリセットしますが、作業ツリーはリセットしません (つまり、変更されたファイルは保持されますが、コミットの対象とはマークされません)。また、更新されなかったものを報告します。これがデフォルトのアクションです。
-Nが指定された場合、削除されたパスは「追加する意図」としてマークされます (git-add[1] を参照)。 - --hard
-
インデックスと作業ツリーをリセットします。
<commit>以降の作業ツリー内の追跡対象ファイルの変更はすべて破棄されます。追跡対象ファイルを書き込む際に邪魔になる untracked ファイルやディレクトリは単純に削除されます。 - --merge
-
インデックスをリセットし、
<commit>とHEADの間で異なる作業ツリー内のファイルを更新しますが、インデックスと作業ツリーの間で異なるファイル (つまり、まだ追加されていない変更があるファイル) は保持します。<commit>とインデックスの間で異なるファイルにステージングされていない変更がある場合、リセットは中止されます。言い換えれば、
--mergeはgit read-tree -u -m <commit>のようなことを行いますが、未マージのインデックスエントリは引き継ぎます。 - --keep
-
インデックスエントリをリセットし、
<commit>とHEADの間で異なる作業ツリー内のファイルを更新します。<commit>とHEADの間で異なるファイルにローカルな変更がある場合、リセットは中止されます。 - --[no-]recurse-submodules
-
作業ツリーが更新される際、--recurse-submodules を使用すると、すべての有効なサブモジュールの作業ツリーもスーパープロジェクトに記録されたコミットに従って再帰的にリセットされ、そのコミットでサブモジュールの HEAD もデタッチされた状態になります。
これら3つのコマンドの違いについては、git[1] の「リセット、リストア、リバート」を参照してください。
オプション
- -q
- --quiet
-
静かに実行し、エラーのみを報告します。
- --refresh
- --no-refresh
-
混合リセット後にインデックスを更新します。デフォルトで有効です。
- --pathspec-from-file=<file>
-
パススペックはコマンドライン引数の代わりに
<file>で渡されます。<file>が正確に-の場合、標準入力が使用されます。パススペック要素は LF または CR/LF で区切られます。パススペック要素は、設定変数core.quotePath(git-config[1] を参照) で説明されているようにクォートできます。--pathspec-file-nulおよびグローバルな--literal-pathspecsも参照してください。 - --pathspec-file-nul
-
--pathspec-from-fileと共にのみ意味を持ちます。パススペック要素は NUL 文字で区切られ、他のすべての文字はリテラルに解釈されます (改行やクォートを含む)。 - --
-
これ以上の引数をオプションとして解釈しません。
- <pathspec>…
-
操作の影響を受けるパスを制限します。
詳細については、gitglossary[7] の pathspec エントリを参照してください。
例
- add の取り消し
-
$ edit (1) $ git add frotz.c filfre.c $ mailx (2) $ git reset (3) $ git pull git://info.example.com/ nitfol (4)
-
作業中に、これらのファイルの変更が良い状態にあることに気づきました。他のファイルや変更に取り組む予定であり、これらのファイルの変更が邪魔になるため、
git diffを実行したときにそれらを見たくありません。 -
誰かがプルを要求し、その変更がマージに値すると判断しました。
-
しかし、すでにインデックスを汚してしまっています (つまり、インデックスが
HEADコミットと一致していません)。ただし、これから行うプルがfrotz.cまたはfilfre.cに影響しないことが分かっているので、これらの2つのファイルのインデックス変更を元に戻します。作業ツリー内の変更はそのまま残ります。 -
その後、プルしてマージし、
frotz.cとfilfre.cの変更は引き続き作業ツリーに残すことができます。
-
- コミットを取り消し、やり直す
-
$ git commit ... $ git reset --soft HEAD^ (1) $ edit (2) $ git commit -a -c ORIG_HEAD (3)
-
これは、コミットしたばかりのものが不完全だった、コミットメッセージのスペルを間違えた、またはその両方であることに気づいた場合によく行われます。作業ツリーは「リセット」前の状態のままになります。
-
作業ツリーファイルを修正します。
-
「reset」は古いヘッドを
.git/ORIG_HEADにコピーします。そのログメッセージから開始してコミットをやり直します。メッセージをさらに編集する必要がない場合は、代わりに-Cオプションを指定できます。git-commit[1] の
--amendオプションも参照してください。
-
- コミットを取り消し、トピックブランチにする
-
$ git branch topic/wip (1) $ git reset --hard HEAD~3 (2) $ git switch topic/wip (3)
-
いくつかのコミットをしましたが、それらが
masterブランチに入れるには時期尚早であることに気づきました。それらをトピックブランチで磨き続けたいので、現在のHEADからtopic/wipブランチを作成します。 -
それらの3つのコミットを取り除くために、masterブランチを巻き戻します。
-
topic/wipブランチに切り替えて作業を続けます。
-
- コミットを完全に元に戻す
-
$ git commit ... $ git reset --hard HEAD~3 (1)
-
最後の3つのコミット (
HEAD、HEAD^、およびHEAD~2) は悪く、二度と見たくありません。これらのコミットをすでに他の人に渡している場合は、これを行わないでください。(これを行うことの意味については、git-rebase[1] の「アップストリームのリベースからの回復」セクションを参照してください。)
-
- マージまたはプルの取り消し
-
$ 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)
-
アップストリームからの更新を試みた結果、多くの競合が発生しました。今すぐマージに多くの時間を費やす準備ができていなかったので、後でそれを行うことにしました。
-
「pull」はマージコミットを作成していないので、
git reset --hard(git reset --hard HEADの同義語) はインデックスファイルと作業ツリーの混乱を解消します。 -
トピックブランチを現在のブランチにマージし、早送りマージになりました。
-
しかし、そのトピックブランチはまだ一般公開する準備ができていないと判断しました。「pull」または「merge」は常に現在のブランチの元の先端を
ORIG_HEADに残すため、そこへハードリセットすることで、インデックスファイルと作業ツリーはその状態に戻り、ブランチの先端もそのコミットにリセットされます。
-
- ダーティな作業ツリー内でのマージまたはプルの取り消し
-
$ git pull (1) Auto-merging nitfol Merge made by recursive. nitfol | 20 +++++---- ... $ git reset --merge ORIG_HEAD (2)
-
作業ツリーにローカルな修正がある場合でも、他のブランチの変更がそれらと重複しないことが分かっている場合は、安全に
git pullと言うことができます。 -
マージの結果を検査した後、他のブランチの変更が満足のいくものではないと判断するかもしれません。
git reset --hard ORIG_HEADを実行すると、元の状態に戻ることができますが、ローカルの変更が破棄されてしまいます。それは望ましくありません。git reset --mergeはローカルの変更を保持します。
-
- 中断されたワークフロー
-
大規模な変更の途中で、緊急の修正依頼によって中断されたとします。作業ツリーのファイルはまだコミットできる状態ではありませんが、緊急のバグ修正のために別のブランチに移動する必要があります。
$ 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)
-
このコミットは破棄されるので、使い捨てのログメッセージで構いません。
-
これにより、WIP コミットがコミット履歴から削除され、作業ツリーはスナップショットを作成する直前の状態に設定されます。
-
この時点では、インデックスファイルには、snapshot WIP としてコミットしたすべての WIP 変更がまだ残っています。これにより、インデックスが更新され、WIP ファイルが未コミットとして表示されます。
git-stash[1] も参照してください。
-
- インデックス内の単一ファイルのリセット
-
ファイルがインデックスに追加されているが、後でコミットに追加したくないと判断したとします。
git resetを使用して、変更を保持したままインデックスからファイルを削除できます。$ git reset -- frotz.c (1) $ git commit -m "Commit files in index" (2) $ git add frotz.c (3)
-
これにより、ファイルはインデックスから削除されますが、作業ディレクトリには保持されます。
-
これにより、インデックス内の他のすべての変更がコミットされます。
-
ファイルを再びインデックスに追加します。
-
- 作業ツリーの変更を保持しつつ、一部の以前のコミットを破棄する
-
何か作業をしてコミットし、さらに少し作業を続けたが、作業ツリーにあるものは以前にコミットしたものとは関係のない別のブランチに入れるべきだと考えた場合を想定します。新しいブランチを開始し、作業ツリーの変更を保持したままリセットすることができます。
$ git tag start $ git switch -c branch1 $ edit $ git commit ... (1) $ edit $ git switch -c branch2 (2) $ git reset --keep start (3)
-
これにより、
branch1で最初の編集がコミットされます。 -
理想的な世界では、
branch2を作成して切り替えたときに、以前のコミットが新しいトピックに属さないことに気づけたはずです (つまり、git switch -c branch2 start)。しかし、誰もが完璧ではありません。 -
しかし、
branch2に切り替えた後に、reset --keepを使用して不要なコミットを削除できます。
-
- コミットを複数のコミットに分割する
-
多数の論理的に分離された変更を作成し、それらをまとめてコミットしたとします。その後、各論理チャンクを独自のコミットに関連付ける方が良いと判断しました。
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つ前のコミットにリセットしますが、作業ツリーはすべての変更を保持したままにします。
-Nは、HEADで追加された新しいファイルが引き続きマークされ、git add -pがそれらを見つけることを保証します。 -
次に、
git add -p機能を使用して、差分ハンクを対話的に選択して追加します。これにより、各差分ハンクについて順に尋ねられ、「はい、これを含める」、「いいえ、これを含めない」、あるいは非常に強力な「編集」機能などの簡単なコマンドを使用できます。 -
含めるハンクに満足したら、
git diff --cachedを使用して最初のコミットのために準備された内容を確認する必要があります。これにより、インデックスに移動され、コミットされようとしているすべての変更が表示されます。 -
次に、インデックスに保存されている変更をコミットします。
-cオプションは、最初のコミットで開始した元のメッセージからコミットメッセージを事前に入力することを指定します。これは再入力を避けるのに役立ちます。HEAD@{1}は、元のリセットコミットの前のHEADがあったコミット (1つ前の変更) の特殊な表記です。詳細については、git-reflog[1] を参照してください。他の有効なコミット参照も使用できます。 -
元のコードを任意の数のコミットに分割するために、手順2-4を複数回繰り返すことができます。
-
これで多くの変更が個別のコミットに分割されたため、残りの未コミットの変更をすべて選択するために、
git addのパッチモードを使用しなくなるかもしれません。 -
もう一度、含めたいものがすべて含まれていることを確認してください。また、
git diffが後でコミットすべき変更を何も表示しないことを確認したい場合もあります。 -
そして最後に、最終コミットを作成します。
-
考察
以下の表は、
git reset --option target
ファイルの状態に応じて異なるリセットオプションで HEAD を別のコミット (target) にリセットした場合に何が起こるかを示します。
これらの表では、A、B、C、D はファイルの異なる状態です。たとえば、最初の表の最初の行は、作業ツリーでファイルが状態 A、インデックスで状態 B、HEAD で状態 C、ターゲットで状態 D である場合、git reset --soft target はファイルを作業ツリーで状態 A、インデックスで状態 B のままにし、HEAD (現在のブランチにいる場合はその先端) をターゲット (ファイルが状態 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
reset --merge は、競合したマージからリセットする場合に使用されることを意図しています。任意のマージ操作は、マージに関与する作業ツリーファイルが開始前にインデックスに対してローカルな変更を持たず、結果を作業ツリーに書き出すことを保証します。したがって、インデックスとターゲットの間、およびインデックスと作業ツリーの間にいくつかの違いが見られる場合、それは競合で失敗した後、マージ操作が残した状態からリセットしていないことを意味します。そのため、この場合は --merge オプションを許可しません。
reset --keep は、現在のブランチの最後のコミットの一部を削除しながら、作業ツリーの変更を保持する場合に使用されることを意図しています。削除したいコミットの変更と保持したい作業ツリーの変更の間に競合が発生する可能性がある場合、リセットは許可されません。そのため、作業ツリーと HEAD の間、および HEAD とターゲットの間に変更がある場合は許可されません。安全のため、未マージのエントリがある場合も許可されません。
以下の表は、未マージのエントリがある場合に何が起こるかを示します
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 は未マージのインデックスを意味します。
GIT
git[1] スイートの一部
