vscode中的git插件将git操作从git指令简化到简单的图形界面操作，不消再去记忆git指令，操作简单直观了许多。第一次利用时，为了加深明白，我将一些基本操作和该操作底层利用的命令结合起来，并包含实例，方便学习。
【git】(二)在vscode上利用git举行版本控制（结合指令、含示例）-CSDN博客
0.配置
在完成git的下载和安装后，肯定要设置用户名称和email地址。这是非常紧张的，因为每次Git提交都会利用该用户信息。如果没有配置信息，在利用vscode调动git举行commit时会出现如许的弹窗：
基本配置: 恣意文件夹下打开Git Bash，大概打开恣意终端，利用以下指令设置用户信息：
- git config --global user.name "name"
- git config --global user.email "xxx@xxx.cn"
- git config --global user.name
- git config --global user.email
1.1 获取本地仓库
【vscode中的操作】
打开需要举行版本管理的项目文件夹（即将创建本地git仓库的地方），找到git插件（源代码管理），点击open repository，如果该文件夹下还没有本地仓库，则会初始化一个仓库；如果之前已经创建过仓库了，那么vscode会引导用户打开已有的仓库。
【对应的git指令】
以上的操作相当于：在该文件夹下，进入终端（可以是git bash、也可以是终端），输入以下git初始化指令。该命令用于在当前目录初始化一个新的 Git 仓库。如果当前目录已经是一个 Git 仓库，实行此命令不会有任何结果。
【结果】该文件夹下有.git隐藏目录，且git插件部门显示了该目录下各文件的状态，阐明本地仓库已经存在。
【示例】
作为示例，在该文件夹里创建test1、test2两个文件：
1.2 查看状态
文件状态表明了各文件是否被 Git 识别和纳入版本控制。在vscode中的Git插件，文件可以处于以下几种状态：
- 未跟踪(U)：文件不存在于最近的提交中，Git 尚未开始跟踪这个文件。当在仓库中创建新文件时，它们最初都是未跟踪的。
- 已修改(M)：文件自上次提交以来已经被修改，但还没有被暂存。
- 已删除(D)：文件在本地仓库中存在，但是在工作区中被删除，该删除操作还没被暂存。
- 已暂存（索引）：文件的当前版本已经被标记为将在下次提交时被包含，vscode中包含以下暂存的三种状态：
- 已添加索引(A)：文件已经被添加到暂存区
- 已修改索引(M)：文件自上次提交以来已经被修改，且已经被暂存。固然显示的也是M，但是需要和“已修改”分别开。
- 已删除索引(D)：文件在本地仓库中存在，且删除操作被暂存。固然显示的也是D，但是需要和“已删除”分别开。
【vscode中的操作（其实不消操作）】
Git插件的图形化界面本身可以轻松观察到当前全部文件状态，十分方便。此时Git 插件会显示以上test1、test2文件的状态为“未跟踪”（反面的大U），因为它们尚未被纳入版本控制。
【对应git指令】
如果利用该指令，可以查看全部文件的状态：
2.工作区与暂存区之间的转换
2.1 工作区->暂存区
【vscode中的操作】
在git插件中，“更改”部门列出了全部未暂存（包括“未跟踪”、“已修改”、“已删除”状态）的文件。
点击“更改”反面的按钮可以对全部文件举行操作；也可以鼠标悬停到某一个文件,对单一文件举行操作：曲线剪头是打消全部修改（这个在反面提及）," + " 号是暂存全部修改
【对应的git指令】
添加全部未暂存文件到暂存区：将当前目录下全部新的或修改过的文件添加到暂存区。
添加单一未暂存文件到暂存区：将 <file> 替换为要暂存的文件名（例如，test1.txt）。
【结果】文件从“更改”栏进入“暂存的更改” ，文件状态变成“已暂存”（反面的大A）
2.2 暂存区->工作区
从暂存区中移除特定的文件，回到工作区状态，且不修改该文件工作区的内容
【vscode中的操作】
在Git插件中，“暂存的更改”部门列出了全部已经暂存的文件。
同理，点击“暂存的更改”反面的按钮可以对全部文件举行操作；也可以鼠标悬停到某一个文件,对单一文件举行操作：上图所框选出的“-”号是移除暂存文件
【对应的git指令】
将暂存区中的全部文件取消暂存
取消暂存某个特定的文件：将 <file> 替换为要暂存的文件名（例如，test1.txt）。
【结果】文件从“暂存的更改”栏移除。出现在“更改”栏，文件状态变回未暂存状态。
2.3 暂存区与工作区同一文件版本差异的情况（冲突题目）
在 VSCode 的 Git 插件中，“暂存的更改”部门显示的不仅仅是 Git 暂存区中的文件，它还可能包括那些已经被暂存但之后又被修改的文件。即“暂存的更改” ≠ “暂存区”，在 Git 命令行中，只有真正被暂存且未被进一步修改的文件才被视为暂存区的一部门。
- 只在“暂存的更改”部门出现的文件：文件状态为“已暂存”（包含“已修改索引”、“已添加索引、“已修改索引”），这些文件的当前版本已经被添加到 Git 的暂存区，准备在下一次提交中被包含。
- 同时在“暂存的更改”和“更改”两个部门出现的文件：状态不是“已xx索引”，这些文件之前可能已经被暂存，但在工作区中又有了新的修改。这些修改尚未被添加到暂存区。
【示例】
①暂存test1.txt：此时该文件状态为“已添加索引”（A），表示文件的当前版本已经存在于 Git 的暂存区中。
②修改test1.txt：将全部的“广东”改成“东莞”。同时观察文件状态——此时test1文件状态为“已修改”，同时也在“更改”地域出现。
此时，由于对文件做了新的修改，它的状态变为“已修改”（M），而且也出现在 VSCode 的“更改”地域。只管这个修改后的状态为“M”的test1.txt仍然显示在“暂存的更改”部门，它实际上表示工作区中的文件版本与暂存区的版本差异。这些更改尚未被添加到 Git 的暂存区。
③此时可举行的操作：
（1）重新暂存修改：按照上述 工作区->暂存区 的方法，将工作区中的新修改添加到暂存区，即再次实行add。如许，test1.txt文件状态由M变为A，vscode中“暂存的更改”被覆盖，即全部“广东”变为“东莞”，保留了“更改”中的新内容：
（2）打消旧版本文件的暂存状态：即不提交这些新的修改，而是想要打消对旧版本test1.txt的暂存状态，即可按照上述 暂存区->工作区 的方法，将旧版本的该文件从暂存区中移除，同时工作区中的新修改仍然保留（即“东莞”版本）。
【有可能出现的题目】
在利用“-”操作时，如果跳出以下弹窗，这是因为“暂存的更改”和“更改”中的test1.txt内容存在冲突，它不知道你需要保留哪个版本的文件放入工作区
（好像在没有提交的时候会出现这个情况，如果已有提交，似乎就不会再有这个弹窗，而是直接移除暂存版本）
（3）手动融合两个版本，并暂存融合版本：点击更改区的该文件，vscode会显示出暂存版本（左侧）和当前工作区版本（右侧）的内容，并高亮差异部门。暂存版本不可更改，只能对照，可以直接在工作区版本手动更改融合，也可以利用中间的按钮来对各行的差异部门做弃取：箭头是保留暂存版本方案，+号是采用工作区版本方案
完成融合后，按照上述 工作区->暂存区 的方法，将工作区中的新修改添加到暂存区。
3.提交、修改与回退
3.1 提交、查看提交汗青
再次提示：已暂存状态为“已修改索引”、“已添加索引”、“已删除索引”（“索引”就是暂存），未暂存状态为“已修改”“未追踪”“已删除”
【vscode中的操作】
在输入框中输入本次提交的解释，描述代码的版本大概内容修改的情况，方便之后举行欣赏差异。输入之后点击提交，会将全部暂存区的文件举行提交。
提交后，在“源代码管理图”中，可以看到提交汗青，鼠标悬浮在上面可以获取更多信息，点进去也可以看该版本的详细代码与前一版本的差异。
【对应的git指令】
将暂存区的文件提交到本地仓库的当前分支，将“Your commit message”替换为提交解释。
- git commit -m "Your commit message"
3.2 修改已提交的文件
一旦文件被提交，而且之后没有发生更改，它不会在 Git 插件的“更改”或“暂存的更改”部门显示。这是因为该文件的状态与仓库中的最新提交相匹配，没有新的更改需要跟踪。
如果在提交后又对文件举行了修改，那么这个文件将出现在 Git 插件的“更改”部门，并标记为“已修改”，因为现在它的状态与仓库的最新提交不再同等。
对于举行了修改的文件，可以再次举行上文所述 暂存区<—>工作区 的转换，放在暂存区的全部文件用于等候下一次提交。
【示例】
test1.txt文件在提交“初版0.1”后没有被修改，此时的文件状态如下：它不会在 Git 插件的“更改”部门显示，因为它的状态与最后一次提交的版本同等。
此时，Git插件只显示了未追踪的test2.txt文件，test1.txt文件固然没有显示，但仍然存在于仓库中，只是没有新的更改需要版本控制。
①对test1.txt文件举行修改，删掉其中几行，并将版本改成0.2
②查看Git插件，修改后的test1.txt文件（工作区版本）出现在了“更新”部门，文件状态为“已修改”，点击后可以看到工作区版本的文件内容（右）与最新提交版本的文件内容（左）的差异
③ 利用add暂存test1.txt，该文件进入“暂存的更改”栏，文件状态为“已修改索引”【暂存状态】，点击后可以看到暂存版本的文件内容（右）与最新提交版本的文件内容（左）的差异
④再次修改test1.txt：将全部的“厦门”改成“福州”。此时test1文件状态为“已修改”，同时也在“更改”地域出现。点击后可以看到工作区版本的文件内容（右）与暂存版本的文件内容（左）的差异。
⑤再次利用add暂存test1.txt，该文件进入“暂存的更改”栏，文件状态为“已修改索引”【暂存状态】，点击后可以看到暂存版本的文件内容（右）与最新提交版本的文件内容（左）的差异。
3.3 打消全部修改
打消全部修改针对当前的未暂存文件，即“更改”中的文件，分为两种操作，都需要舍弃当前的工作区版本，一是回退到暂存版本；一是回退到最新提交版本。
【vscode中的操作】
在vscode中，这两种操作没有显式的区分，实现的方法就是点击“更改”栏的文件反面的“曲线箭头”。详细回退的版本为点击该文件时，编辑区左边显示的内容。即，如果暂存区有该文件的汗青版本，就会显示暂存版本；如果暂存区没有该文件的汗青版本，就会显示最新提交版本。
（一个题外话：“暂存的更改”栏下的文件，永远都会显示 最新提交版本 和 暂存版本）
结合以上示例，在第②步时，暂存区为空，因此显示工作区版本和最新提交版本；第④步时，暂存区已经有一个该文件的汗青版本，因此显示工作区版本和暂存版本。
如果在第④步后，点击了test1.txt反面的“曲线箭头”，该工作区版本就会回退到暂存版本（缺行 + “厦门”），同时，因为暂存版本和回退后的工作区版本内容同等，该文件将只挂载在“暂存的更新”栏，且状态将为“已修改索引”。
假如：暂存区有汗青版本，工作区在暂存版本的底子上做了修改，此时需要回退到最新提交版本，可以这么操作：根据上述2.2移除暂存区文件，使暂存区为空，点击打消箭头，回退到最新提交版本。
【对应的git指令】
将工作区中的文件替换为暂存区或最新提交的版本。将 <file> 替换为要暂存的文件名（例如，test1.txt），大概. (全部文件)
3.4 版本回退与打消
版本回退分为两类：一是直接回退到某版本并打消该版本之后全部汗青（reset）；一是打消某些版本的更改且保留汗青（revert）。暂时没有在我的vscode中找到回退的图形化操作，只能copy到版本号，因此得结合git指令操作。
【操作】
在源代码管理图中选中要回退的版本，右键，选择复制commit ID。
打开终端，根据需求输入适当的回退命令（reset/revert）,将<commitID>替换为复制的版本号
3.4.1 回退 git reset：
git reset将 HEAD（当前分支的指向）回退到项目汗青的某个特定点。有三种模式，分别是硬回退、软回退、混合回退。利用git reset命令会彻底打消指定版本之后的全部提交，如果在和他人协作，或是正在操作主分支，要慎重利用。
①硬回退：将 HEAD、暂存区和工作区都回退到指定的提交版本（<commitID>）。全部在该提交版本之后的更改都会被永世抛弃。
实用场景：需要彻底回退到某个版本，而且不需要保留之后的更改。
- git reset --hard <commitID>
实用场景：想要打消提交，但仍然需要对这些更改举行评估或重新构造后再提交。
- git reset --soft <commitID>
结果和软回退差不多，但是无法保留暂存版本。
- git reset --mixed <commitID>
【示例】
再次提交0.2版本，提交的文件为：缺行+“厦门”改“福州” 的test1-0.2 ，和提交0.1版本时没有提交的test2-0.1。
从源代码管理图中也可以查看差异提交版本之间的差异。
①修改test2.txt文件，将其中一行改成首字母缩写，改成0.2版本，暂存。
再删除缩写下面的全部数字，这时文件在“暂存的更改”和“更改”中同时出现，文件状态为“已修改”
②在源代码管理图中复制“初版0.1”的版本号，进入终端，查看差异回退方式的结果：
（1）混合回退：git reset <commitID>
观察仓库状态：暂存区无文件，test1和test2的工作区版本没变，全部更改都保留在了工作区，最新提交版本回到初版0.1状态。test1状态为“已修改”，test2状态为“未追踪”（因为初版0.1没有提交teset2文件）
（2）硬回退：git reset --hard <commitID>
观察仓库状态：Git 插件的“更改”或“暂存的更改”部门无文件，因为文件状态与仓库中的最新提交相匹配，没有新的更改需要跟踪。即，全部在提交该版本之后的更改，全部被抛弃。
接着查看文件目录：很糟糕，因为初始版本没有提交test2文件，test2被完全抛弃了，只剩下了初始提交版本内容的test1文件。【所以要审慎】
（3）软回退：git reset --soft <commitID>
观察仓库状态：test2文件的暂存区版本、工作区版本没变，同时暂存区多了一个test1文件的汗青提交版本，最新提交版本回到初版0.1状态。test1状态为“已修改索引”，test2状态仍为“已修改”。
3.4.3 打消 revert：
revert用来打消某个详细提交的更改。<commitID>理应为要打消的版本，而不是要回退到的版本。它通过创建一个新的提交来实现，这个新提交的更改会抵消<commitID>的更改。它不会改变提交的汗青，而是在汗青的底子上添加一个新的提交。因此更加具有安全性。
实用场景：需要打消汗青中某次提交的情况，该提交可以穿插在汗青中恣意地方
这项操作通常在已经提交了当前版本的更改之后实行，要确保工作区是干净的，即当文件状态与仓库中的最新提交相匹配时。
【示例】
在利用revent时，要包管工作区是干净的，因此将对test2的修改举行提交，解释为 初版0.2(test2-0.2版本)。如果要打消掉 初版0.2(test2-0.2版本) ，对应的要打消的操作就是 修改test2文件（0.1->0.2）。即test2变回0.1版本。
复制 初版0.2(test2-0.2版本) 的版本号，输入revert命令举行版本打消：
此时，如果没有冲突，会自动定义revert解释，并将当前版本（左）和git举行反操作之后的版本（右）显示出来，此时test2在上一次提交举行的更改已经被抵消，并被放入暂存区，等候下一次提交。
【可以明白为：git试图根据打消版本的操作举行反操作，来抵消打消版本的更改，更改后举行暂存，然后展现在我们面前，如果我们认为它操作的正确，那么可以直接提交，如果代码比较复杂，我们认为它没有处理好，那么可以将其转换到工作区，在工作区继承修改，而后暂存提交】
提交revert举行的打消操作，test2文件又回到了0.1状态
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
