Gitコマンド学習のためのgit-resetの詳しい解説

git-reset の機能は、現在のブランチの HEAD ポインタをリセットし、HEAD ポインタが特定の状態を指すようにすることです。

使用法の概要

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

最初の 3 行のリセット コマンドの機能は、指定された コンテンツを参照ベースとして使用することです。次に、コンテンツをキャッシュ領域内のターゲットにコピーします。

ツリーのようなもので、gitにはコミットツリーやタグツリーなどたくさんのツリーが存在します。

最後の行のリセット コマンドの機能は、現在のブランチの HEAD ポインタを にポイントすることです。同時に、さまざまなオプションを使用して、キャッシュ領域またはワーク領域を変更します。

上記のすべてのコマンド形式では、 または がデフォルトで HEAD ポインタとして使用されます。

#git replace [] [--] ##このメソッドには次のルールがあります:

は、キャッシュ領域内の に一致するパス リソースを の状態にリセットします。
• が何なのかわからないですか?

#キャッシュ領域に送信された変更は、作業領域に復元されます。
たとえば?

プロジェクトに Coffee.txt ファイルがあるとします。ファイルの内容は次のとおりです。 git tag コマンドを使用して現在のバージョンをコピーします。バージョンは v1.0.0 としてマークされています (ここでは tag タグを使用します)。

次に、coffee.txt ファイルを変更します。変更内容は次のとおりです:

卡布奇诺纳瑞冰-19.9￥
标准美式-14.9￥
香草拿铁-19.9￥
生椰爱摩卡-19.9￥
...

coffee.txt ファイルを変更した後、git タグを使用して v1.0.1 とマークします。

この時点で、coffee.txt ファイルを v1.0.0 バージョンに復元したい場合は、git restart コマンドを使用して、v1.0.0 として指定できます。操作は次のとおりです。

卡布奇诺纳瑞冰-19.9￥ --> 卡布奇诺纳瑞冰-14.9￥
标准美式-14.9￥ --> 标准美式-9.9￥
香草拿铁-19.9￥ --> 香草拿铁-14.9￥
生椰爱摩卡-19.9￥ --> 生椰爱摩卡-14.9￥
...

Use VSCode キャッシュ領域内のファイルの変更を確認します:

画像の右側にコードの変更の比較が表示されます。キャッシュ領域のcoffee.txtファイルは正常にリセットされ、v1.0.0バージョンのファイルの状態になります(ルール1)。この時点で、v1.0.1 がキャッシュに送信した変更も作業ツリーに復元されています (ルール 2)。

git replace コマンドと git add コマンドには、指定されたリソースをキャッシュ領域に追加するという逆の効果があることがわかります。キャッシュ領域から削除します。このコマンドは、 git list [--source=] --staged と同じ効果があります。復元に興味がある場合は、

この記事

を参照してください。

上で述べたように、reset コマンドを使用した後、キャッシュ領域のファイルの内容は v1.0.0 になります。gitrestore コマンドを使用してキャッシュ領域の内容をワークスペースに復元し、変更することができます。 :

git reset v1.0.0 coffee.txt

必要に応じて、ワークスペースの内容を復元することも選択できます:

git restore coffee.txt --staged

git restart [--pathspec-from-file= [--pathspec -file-nul]] []

上記の例では、同じ パス (coffee .txt)。ファイルパスが比較的シンプルなので、あらゆる操作を入力するのが簡単です。ただし、場合によっては、より複雑な パスをリセットする必要がある場合があります。たとえば、プロジェクト ディレクトリが深い場合、 パスの長いリストを入力する必要があり、非常に面倒になります。そのため、git には --pathspec-from-file オプションが用意されており、再利用が必要になる可能性がある パスを含むファイルを直接指定できます。 ここに詳しい使用法があります。

このファイルの各行は です。複数の がある場合は、改行文字を区切りとして使用します。もちろん、 --pathspec-file-nul を使用して、各 の区切り文字として NUL を使用することもできます。

##git replace (--patch | -p) [] [--] []

交互式的选择与缓存区之间的差异而产生的hunks。这些被选择的hunks将会撤销缓存区中的产生的修改。这里有更详细的--patch选项用法。

git reset [] []

该命令会把当前分支的HEAD指针指向某个，然后由决定是否同时更新缓存区或工作区的内容。默认值是--mixed，且必须是以下几种：

--soft

工作区和缓存区中的文件变动都将被保留，然后将HEAD指针指向。

还是以咖啡菜单为?，假如第一次commit到仓库中的文件内容如下：

卡布奇诺纳瑞冰-19.9￥
标准美式-14.9￥
香草拿铁-19.9￥
生椰爱摩卡-19.9￥
...

然后做第二次commit操作，删除标准美式，增加生椰拿铁：

卡布奇诺纳瑞冰-19.9￥
-标准美式-14.9￥
+生椰拿铁-19.9￥
香草拿铁-19.9￥
生椰爱摩卡-19.9￥
...

在commit后，修改卡布奇诺纳瑞冰的价格，添加到缓存区。再修改香草拿铁的价格，保留在工作区：

-卡布奇诺纳瑞冰-19.9￥
+卡布奇诺纳瑞冰-14.9￥ // 添加到缓存区中
生椰拿铁-19.9￥
-香草拿铁-19.9￥
+香草拿铁-14.9￥ // 保留在工作区
生椰爱摩卡-19.9￥
...

此时我想保留工作区和缓存区做的改动，并且将HEAD指针指向第一次commit。这时可以使用--soft选项实现：

git reset HEAD^ --soft // 这里使用HEAD^表示上一个commit，同样也可以使用hash id

使用git log查看当前HEAD指针确实已经指向第一个commit，第二个commit被抛弃了：

同时所有的工作区和缓存区的改动都被保留了：

当前只有两次的commit，是为了方便演示--soft选项的作用。但是在实际开发中，我们可能会commit多次，尤其是在测试环境改几个BUG就要提交到发布平台，这样会导致很多无意义的commit。这时候就可以使用--soft选项，重置HEAD到指定的只保留一到两个重要的commit。

--mixed

重置缓存区，但是会保留工作区的内容，这是的默认值。

相信在理解了--soft作用后，理解--mixed不难，上面例子中如果是使用--mixed那么最终结果如下：

该选项会重置缓存区，但是保留工作区的改动，并将当前指针指向。

--hard

重置缓存区和工作区中的所有的变动，并且将指针指向。

--hard更加的简单粗暴，我们将--soft例子改为--hard来查看结果：

如图所示，工作区和缓存区的内容都被重置了。不止是如此，就连Untracked文件同样也会被删除。

--merge

该选项的作用，看字面意思就知道大概就是把当前分支和指定的进行合并，规则如下：

• 重置缓存区，任何已经添加到缓存区的改动都将被抛弃

• 如果和HEAD之间有文件存在不同（这个不同指的是文件被删除或者新增），那么将会把该文件重置成中的状态（新增或删除）。

• 如果和HEAD之间有文件存在不同（这个不同是指文件内容的不同），且此时工作区也存在未提交的改动，那么本次的reset将会被终止。

• 如果一个文件在和HEAD中完全相同，但是它的工作区存与缓存区存在着不同（也就是改动未提交到缓存区），那么该文件在工作区的改动在重置之后就会被保留。

我们举个例子来验证一下以上列出的规则，假设此时的咖啡店项目有如下的几个commit。

第一个commit和文件内容如下：

第一个commit中只有一个coffee.txt菜单文件，此时如果咖啡店引进了新品种开始卖果汁，那么就需要新增果汁菜单文件fruits.txt，于是就有了第二个commit：

此时我们做一些改动来验证1，2，4这几点的规则，改动后的文件如下：

首先修改coffee.txt文件，新增一款生椰拿铁咖啡，保留在工作区中。然后增加咖啡豆菜单文件beans.txt，将其添加到缓存区中。

假设因需求变动，咖啡豆菜单文件在缓存区中需要清除，果汁菜单文件需要删除，只有咖啡菜单中新增的生椰拿铁的改动需要保留。那么就可以使用git reset --merge将HEAD和commit-1进行合并，操作如下：

git reset --merge HEAD^

结果如下：

执行命令reset命令产生了如下效果：

• 将当前HEAD指针指向了commit-1
• 将缓存区中的beans.txt文件抛弃(规则1)
• HEAD(commit-2)和commit-1中的fruits.txt文件存在不同(commit-2中新增fruits.txt)，所以会将fruits.txt删除(规则2)
• coffee.txt文件新增生椰拿铁的改动被保留在工作区中(规则4)

再来验证一下第3点规则，假设咖啡店项目此时第一个commit如下：

接下去同样新增水果茶菜单，然后再修改coffee.txt文件，第二个commit如下：

然后在HEAD中再修改coffee.txt文件，删除掉标准美式品种：

此时，如果我们再使用git reset --merge HEAD^就无法再进行重置，该操作会被git终止(规则3)。并且控制台会进行报错提示：

--keep

该选参的作用和--merge相似，唯一的区别就是缓存区中被重置的会被保留在工作区中。

构造如下第一个commit：

改造第二个commit：

在HEAD中进行修改

使用git reset --keep命令：

从结果上来看，只有fruits.txt文件被删除了，beans.txt文件被重置回了工作区中。coffee.txt文件的改动也被保留了。

--[no-]recurse-submodules

使用该选项可以控制是否递归的重置submdoule。如果想要更详细了解，查看这篇文章。

总结

git-reset命令的作用就是重置缓存区和工作区，同时它也提供多个选项来做更具体的控制，使得该命令更加灵活多变。git-reset命令在我们的工作中经常使用，因此熟练掌握该命令是非常重要的。

更多编程相关知识，请访问：编程入门！！

以上がGitコマンド学習のためのgit-resetの詳しい解説の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。