最新VS默认提供了对Git的支持。
Git 是使用极广泛的新式版本控制系统。 使用 Git，可以跟踪一段时间内对代码所做的更改，并且可以还原到特定版本。
GitHub作为远程库，可用于团队内协作和团队外协作。

1.基础操作

1.1 VS配置Git

选择 VS2019 顶部的菜单项（工具 —> 选项），在弹出的对话框中，从左侧选择 ”源代码管理“，从右侧的下拉框中选择 Git.

然后发现左侧多出来了一些跟 Git 配置有关的选项，从左侧选择 “Git 全局配置” 这个选项，在右侧填写用户名和邮箱，这里可以随便填写，这个主要是用来在版本历史记录中识别用户身份（识别是哪个用户提交的版本）。

然后点击确定，保存配置成功后，就会发现在 VS顶部菜单上，多出来了一个 Git 菜单，这说明 VS集成 Git 配置成功。

1.2 操作界面

菜单栏中设有Git栏，可以进行基础设置和操作。
视图：
git更改：当工作区文件发生变化时，显示变换内容以及提交。也可以用于处理 拉取、暂存、提交、推送、合并等操作。
git存储库：当前版本和分支的变换历史记录，以视图的形式呈现。

主界面右下角显示未推送的提交、挂起的更改、当前操作的文件以及当前操作的分支。

2.本地库版本管理

2.1 创建管理本地库

1. 创建配置新项目并利用Git管理
   先使用 VS 创建一个控制台项目，设定项目存储路径。由于只创建一个简单的演示项目，为了查看方便，所以我将解决方案和项目放在同一个目录中了。在实际工作中的绝大部分场景中，我们都会在一个解决方案下创建多个项目，所以在实际工作中，不要勾选 “将解决方案和项目放在同一个目录中”。
   
   选择解决方案，通过鼠标右键菜单，选择 “创建 Git 存储库”。
   
   在弹出的对话框中，左侧选择 “仅限本地”，右侧的本地路径，默认就是项目所在的文件夹，然后点击 “创建” 即可。
   
   项目所在目录中的文件，有了被托管的绿色图标，在 VS的解决方案下，文件前面也有了 “小锁” 的标志，这说明项目的代码已经被 Git 进行版本管理，工作目录已经创建成功。
   
   当文件发生变化时，文件前面小锁变为对号。
   
   当添加新文件后，文件前将显示加号。
   

2.2 暂存、存储

在VS中，暂存是指“git add”，存储是指“git stash”。
改动文件点击“+”后，会归到【暂存更改】的节点下。然后才能提交和推送。
在有文件改动后，点击提交按钮右边的箭头，在下拉菜单中能看到【全部存储(T)(–include-untracked)】和【全部存储并保持暂存(S)(–保留索引)】

简单的说，就是将当前更改保存起来，或者理解为打包藏起来。并没有提交

【全部存储(T)(–include-untracked)】：就是字面意思，全部存储，傻瓜式，管你是暂存还是更改。后面括号中的(–include-untracked)，就是包含非追踪文件，就是即使“.gitignore”中已经忽略的文件发生更改，也存。存储结果就是你的【更改数】【暂存更改】节点下所有东西都被保存且不在显示。

【全部存储并保持暂存(S)(–保留索引)】：类似与全部存储，但“并保持暂存”是说，之前点过“+”，在【暂存更改】下的虽然会被存储，但不会被清理。方便你的下一步提交操作。所谓“–保留索引”是什么意思呢，索引就是当“git add”（点“+”）之后，这些更改就会生成版本号，或者叫索引，由一串字符表示。

存储后如何应用呢？
在【Git更改】窗口中的【存储】节点下，右击某一条存储，弹出的菜单中，【应用】就对应前面提到的“git stash apply”；【弹出】 就对应前面提到的“git stash pop”；【放下】就是丢弃删除某个存储的意思。

应用场景：
1 当正在dev分支上开发某个项目，这时项目中出现一个bug，需要紧急修复，但是正在开发的内容只是完成一半，还不想提交，这时可以用git stash命令将修改的内容保存至堆栈区，然后顺利切换到hotfix分支进行bug修复，修复完成后，再次切回到dev分支，从堆栈中恢复刚刚保存的内容。
2 由于疏忽，本应该在dev分支开发的内容，却在master上进行了开发，需要重新切回到dev分支上进行开发，可以用git stash将内容保存至堆栈中，切回到dev分支后，再次恢复内容即可。
总的来说，git stash命令的作用就是将目前还不想提交的但是已经修改的内容进行保存至堆栈中，后续可以在某个分支上恢复出堆栈中的内容。这也就是说，stash中的内容不仅仅可以恢复到原先开发的分支，也可以恢复到其他任意指定的分支上。git stash作用的范围包括工作区和暂存区中的内容，也就是说没有提交的内容都会保存至堆栈中。

git stash //能够将所有未提交的修改（工作区和暂存区）保存至堆栈中，用于后续恢复当前工作目录。
git stash save //作用等同于git stash，区别是可以加一些注释  git stash save "test"
git stash list //查看当前stash中的内容
git stash pop //将当前stash中的内容弹出，并应用到当前分支对应的工作目录上。
git stash apply + stash名字 //将堆栈中的内容应用到当前目录，不同于git stash pop，该命令不会将内容从堆栈中删除，也就说该命令能够将堆栈的内容多次应用到工作目录中，适应于多个分支的情况。
git stash drop + 名称  //从堆栈中移除某个指定的stash
git stash clear //清除堆栈中的所有 内容
git stash show //查看堆栈中最新保存的stash和当前目录的差异。
git stash branch  //从最新的stash创建分支。

2.3 提交

将文件的改动提交都本地库中进行管理。

git commit -m "" 文件名

2.4 版本切换

在需要更改版本的上右击，点击“查看历史版本”

• git reset soft、mixed和hard的区别

soft （软），仅仅移动版本库HEAD指针，其他什么事都不做，即索引文件（暂存区）、工作区不会重置

mixed（混合）reset默认的，不指定reset类型就是它，移动版本库HEAD指针，重置暂存区，但不重置工作区。就比如说你从当前版本回退到历史版本，你工作区更改的文件和代码都是不会变成历史版本的。

hard（硬），移动版本库HEAD指针，重置暂存区和工作区。彻底回退到某个版本，本地的代码也会变为某个版本的内容，此命令慎用！ 如果真要使用，建议先commit提交一份到本地库里，后悔再git reset回去

• VS中对第二个历史版本commit进行重置>删除更改处理，会删除第一个commit版本。但是通过git bash命令窗可以恢复。
• 对于第二个版本利用保留更改，然后撤销更改即可恢复到当前选定的事先版本。该功能也能实现跨版本的功能修改。
  

3.分支操作

3.1 分支应用

在实际项目开发过程中，我们会经常遇到这样的情景：master 主分支的代码已经测试通过，编译发布到公网正式环境了，接下来我们需要开发新的需求功能，此时我们是在 master 主分支上继续开发新需求功能，还是新创建一个分支开发新需求功能？
这主要根据你所要开发的新需求功能的 任务量大小 和 复杂程度 而定。
大部分情况下，我们实际工作中开发的新需求功能，工作量都会比较大，复杂程度也较高，需要花费时间也较长，此时最好创建一个新分支来开发新需求功能，最好让 master 分支的代码版本始终保持跟发布到公网正式环境的版本一致，这样做的好处很多。万一新功能在开发过程中，运营人员反馈了公网环境中的一些 bug，万一产品经理或者领导要求临时调整一下公网上的一些界面或功能等等，此时通过修改 master 主分支的代码，我们就可以快速响应并及时发布。等新的功能需求开发完毕测试无误，发布到公网正式环境后，我们就可以考虑合并分支，或者直接把新的分支作为主分支。

3.2 新建分支

在 VS 的顶部菜单中，选择 "Git —> 新建分支 ".

弹出如下对话框，录入新分支的名称 dev ，勾选上 “签出分支” 对话框，点击 “创建” 即可。

3.3 合并分支、解决冲突

分别在master和hot_fix分支中修改部分内容，然后合并分支。合并的过程中会产生冲突，通过自主修改或者自带的git解决冲突。

合并完成后，由于我们在 master 分支和hot_fix分支上，同时更改了文件，所以 文件就有合并冲突，文件前面的图标也发生了变化，打开 Program.cs 文件可以看到冲突的细节.

此时我们有两种途径来解决冲突：

1. 直接修改文件，编译没有问题后，提交即可。
2. 鼠标选择文件，点击鼠标右键菜单 “Git --> 解决”。

我们将 文件修改完成后，编译运行测试没有问题后，点击 “接受合并” 即可，然后将合并后的 文件提交到 master 版本库. 打开合并编辑器

可以在文件中修改后，调试查看结果。如果满足要求则“接受合并”。

3.4 删除分支

此时 分支就没有什么用处了，我们可以把 分支进行删除，在 VS顶部菜单中，选择 “Git --> 管理分支”，打开如下界面，选择 分支，通过鼠标右键菜单选择 “删除” 即可。

4.远程库版本管理

4.1 新建、克隆

从新建远程代码仓库，到克隆、拉取、推送、管理分支，基本都能通过VS完成。

克隆完成后，同时完成了：1、拉取代码；2、初始化本地库；3、创建别名。
通过行命令clone也可以，然后采用VS打开本地库进行操作，也能进行正常的远程库管理。

4.2 提取、拉取、推送与同步

在菜单栏和git更改视图中都可以操作。

• 提取（fetch）：从远程获取最新版本文件到本地，不自动合并，最新版本在“分支”选项中的“remotes/origin”文件夹下可以查看，可以选择将其合并到master分支上。
• 拉取（pull）从远程仓库拉取最新版本文件到本地，自动合并/merge。
• 推送（push）即将本地仓库上传至云端.
• 同步包括拉取和推送两个步骤.

提取不会自动合并或覆盖本地代码，而是将其储存在分支选项卡中，供开发者自行选择合并，可以避免云端与本地一些代码起冲突时的数据丢失。而拉取则是暴力合并，如果该项目仅由你一人进行开发，那么用拉取更方便，因为没有其他人的改动，但如果是和团队一起协作开发则建议用提取，避免引起不必要的冲突。
同样地，如果是一人开发项目，或者仅仅是想同步本地代码到云端，那推送就足够了。但如果是团队协作开发，那么强烈建议使用同步，即先拉取再推送，不然可能会出现如下情况的提示，即项目中其他部分未和最新的云端仓库保持一致。

4.3 团队开发

• 创建新的分支进行开发
  这是一个常见的开发实践，每个开发者都在自己的分支上进行工作，而不是直接在主分支上开发。这样可以防止不同开发者的改动直接冲突。
• 定期拉取和推送代码
  开发者需要定期从远程仓库拉取最新的代码，并将自己的代码推送到远程仓库。这样可以确保开发者始终基于最新的代码进行开发，减少冲突的可能性。

当你从远程仓库拉取最新代码并在其基础上进行开发时，其他开发者可能也在同时进行他们的开发工作。当你准备提交（push）你的代码时，的确可能会发生版本冲突。这是因为在你的开发过程中，源代码已经被其他开发者更新了。
这就是为什么定期拉取（pull）和推送（push）代码是很重要的。定期拉取最新的代码可以帮助你尽早发现和解决冲突，减少最后阶段的复杂性。如果你只在开发完成时才拉取最新代码，那么可能会遇到很多冲突，需要花费大量时间来解决。
当你准备提交你的代码时，你应该首先从远程仓库拉取最新的代码，然后合并（merge）到你的开发分支。这时，你可能会发现一些冲突。这些冲突需要你手动解决，Git提供了工具来帮助你标识和解决这些冲突。一旦冲突解决，你就可以将你的代码推送到远程仓库。
详细操作步骤如下：

1. 切换到主分支。
2. 从远程仓库拉取最新的代码。
3. 切换回开发分支。
4. 将主分支的新提交合并到你的分支。
5. 解决完所有冲突后，你需要添加所有解决了冲突的文件，提交这次冲突解决。
6. 将你的分支推送到远程仓库。

这样，你的分支就包含了所有在你开发过程中主分支上的新提交，同时也包含了你自己的更改。

note:如果发生了拉取的冲突。则将软件版本回溯到之前有联系的版本，与远程库建立联系之后，然后将新的更改再合并到分支中去。