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>]

reset 명령의 처음 세 줄의 기능은 지정된 콘텐츠를 참조로 사용한 다음 해당 콘텐츠를 대상 캐시 영역에 복사하는 것입니다.

커밋 트리나 태그 트리 등 git에서 트리를 형성할 수 있는 것들이 많이 있습니다.

reset 명령의 마지막 줄은 현재 분기의 HEAD 포인터를 으로 가리키는 것입니다. 동시에 다양한 옵션을 사용하여 캐시 영역을 수정할지 작업 영역을 수정할지 제어할 수 있습니다.

위의 모든 명령 형식에서는 기본적으로 또는

git Reset [] [--]

이 메소드에는 다음 규칙이 있습니다.

• 영역은 의 상태로 재설정됩니다. 이 무엇인지 모르시나요?

• 캐시에 제출된 변경사항은 작업공간에 복원됩니다.

예를 들어?

프로젝트에 Coffee.txt 파일이 있다고 가정해 보겠습니다. 파일 내용은 다음과 같습니다.

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

git tag 명령을 사용하여 현재 버전을 v1.0.0으로 표시합니다(여기서는). 태그 태그가 사용됩니다).

그런 다음 Coffee.txt 파일을 수정하면 수정 내용은 다음과 같습니다.

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

coffee.txt 파일을 변경한 후 git 태그를 사용하여 v1.0.1로 표시합니다.

이번에 Coffee.txt 파일을 v1.0.0의 파일로 복원하려면 git Reset 명령을 사용하여 v1.0.0으로 지정하면 됩니다.

git reset v1.0.0 coffee.txt

VSCode를 사용하면 됩니다. 캐시 영역에서 파일 변경 사항 보기:

그림 오른쪽에서 코드 변경 사항의 비교를 볼 수 있습니다. 이때 캐시 영역의 Coffee.txt 파일이 성공적으로 상태로 재설정되었습니다. v1.0.0 버전의 파일 (규칙 1). 그리고 이때 v1.0.1이 캐시에 제출한 변경 사항도 작업 트리에 복원되었습니다(규칙 2).

git Reset 명령과 git add 명령은 지정된 리소스를 캐시 영역에 추가하는 효과와 캐시 영역에서 제거하는 효과를 갖는 것을 알 수 있습니다. 그리고 이 명령은 git Restore [--source=] --staged 와 동일한 효과를 갖습니다. 복원에 관심이 있는 분은 이 기사를 읽어보세요.

위에서 언급한 바와 같이, 재설정 명령을 사용한 후 캐시 영역의 파일 내용은 v1.0.0입니다. git Restore 명령을 사용하여 캐시 영역의 내용을 작업 공간에 복원한 후 수정할 수 있습니다:

git restore coffee.txt --staged

또한 필요에 따라 작업공간의 내용을 복원하도록 선택할 수 있습니다:

git restore coffee.txt --worktree

git Reset [--pathspec-from-file= [--pathspec-file-nul]] [ ;]

위의 예에서는 재설정 및 복원 시마다 동일한 경로(coffee.txt)가 사용됩니다. 파일 경로가 비교적 간단하기 때문에 모든 작업을 입력하기가 더 쉽습니다. 그러나 어떤 경우에는 더 복잡한 경로를 재설정해야 할 수도 있습니다. 예를 들어 프로젝트 디렉토리가 깊은 경우에는 경로의 긴 목록을 입력해야 할 수도 있습니다. 따라서 git은 재사용이 필요할 수 있는 경로가 포함된 파일을 직접 지정할 수 있는 --pathspec-from-file 옵션을 제공합니다. 여기에 더 자세한 사용법이 있습니다.

이 파일의 각 줄은 입니다. 이 여러 개인 경우 줄바꿈 문자를 구분하여 사용하세요. 물론 --pathspec-file-nul을 사용하여 NUL을 각 의 구분 기호로 사용할 수도 있습니다.

git 재설정 (--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 중국어 웹사이트의 기타 관련 기사를 참조하세요!