选择 VS2019 顶部的菜单项(工具 —> 选项),在弹出的对话框中,从左侧选择 ”源代码管理“,从右侧的下拉框中选择 Git.
然后发现左侧多出来了一些跟 Git 配置有关的选项,从左侧选择 “Git 全局配置” 这个选项,在右侧填写用户名和邮箱,这里可以随便填写,这个主要是用来在版本历史记录中识别用户身份(识别是哪个用户提交的版本)。
然后点击确定,保存配置成功后,就会发现在 VS顶部菜单上,多出来了一个 Git 菜单,这说明 VS集成 Git 配置成功。
菜单栏中设有Git栏,可以进行基础设置和操作。
视图:
git更改:当工作区文件发生变化时,显示变换内容以及提交。也可以用于处理 拉取、暂存、提交、推送、合并等操作。
git存储库:当前版本和分支的变换历史记录,以视图的形式呈现。
主界面右下角显示未推送的提交、挂起的更改、当前操作的文件以及当前操作的分支。
在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创建分支。
将文件的改动提交都本地库中进行管理。
git commit -m "" 文件名
mixed(混合)reset默认的,不指定reset类型就是它,移动版本库HEAD指针,重置暂存区,但不重置工作区。就比如说你从当前版本回退到历史版本,你工作区更改的文件和代码都是不会变成历史版本的。
hard(硬),移动版本库HEAD指针,重置暂存区和工作区。彻底回退到某个版本,本地的代码也会变为某个版本的内容,此命令慎用! 如果真要使用,建议先commit提交一份到本地库里,后悔再git reset回去
在实际项目开发过程中,我们会经常遇到这样的情景:master 主分支的代码已经测试通过,编译发布到公网正式环境了,接下来我们需要开发新的需求功能,此时我们是在 master 主分支上继续开发新需求功能,还是新创建一个分支开发新需求功能?
这主要根据你所要开发的新需求功能的 任务量大小 和 复杂程度 而定。
大部分情况下,我们实际工作中开发的新需求功能,工作量都会比较大,复杂程度也较高,需要花费时间也较长,此时最好创建一个新分支来开发新需求功能,最好让 master 分支的代码版本始终保持跟发布到公网正式环境的版本一致,这样做的好处很多。万一新功能在开发过程中,运营人员反馈了公网环境中的一些 bug,万一产品经理或者领导要求临时调整一下公网上的一些界面或功能等等,此时通过修改 master 主分支的代码,我们就可以快速响应并及时发布。等新的功能需求开发完毕测试无误,发布到公网正式环境后,我们就可以考虑合并分支,或者直接把新的分支作为主分支。
在 VS 的顶部菜单中,选择 "Git —> 新建分支 ".
弹出如下对话框,录入新分支的名称 dev ,勾选上 “签出分支” 对话框,点击 “创建” 即可。
分别在master和hot_fix分支中修改部分内容,然后合并分支。合并的过程中会产生冲突,通过自主修改或者自带的git解决冲突。
合并完成后,由于我们在 master 分支和hot_fix分支上,同时更改了文件,所以 文件就有合并冲突,文件前面的图标也发生了变化,打开 Program.cs 文件可以看到冲突的细节.
此时我们有两种途径来解决冲突:
我们将 文件修改完成后,编译运行测试没有问题后,点击 “接受合并” 即可,然后将合并后的 文件提交到 master 版本库. 打开合并编辑器
可以在文件中修改后,调试查看结果。如果满足要求则“接受合并”。
此时 分支就没有什么用处了,我们可以把 分支进行删除,在 VS顶部菜单中,选择 “Git --> 管理分支”,打开如下界面,选择 分支,通过鼠标右键菜单选择 “删除” 即可。
从新建远程代码仓库,到克隆、拉取、推送、管理分支,基本都能通过VS完成。
克隆完成后,同时完成了:1、拉取代码;2、初始化本地库;3、创建别名。
通过行命令clone也可以,然后采用VS打开本地库进行操作,也能进行正常的远程库管理。
提取不会自动合并或覆盖本地代码,而是将其储存在分支选项卡中,供开发者自行选择合并,可以避免云端与本地一些代码起冲突时的数据丢失。而拉取则是暴力合并,如果该项目仅由你一人进行开发,那么用拉取更方便,因为没有其他人的改动,但如果是和团队一起协作开发则建议用提取,避免引起不必要的冲突。
同样地,如果是一人开发项目,或者仅仅是想同步本地代码到云端,那推送就足够了。但如果是团队协作开发,那么强烈建议使用同步,即先拉取再推送,不然可能会出现如下情况的提示,即项目中其他部分未和最新的云端仓库保持一致。
当你从远程仓库拉取最新代码并在其基础上进行开发时,其他开发者可能也在同时进行他们的开发工作。当你准备提交(push)你的代码时,的确可能会发生版本冲突。这是因为在你的开发过程中,源代码已经被其他开发者更新了。
这就是为什么定期拉取(pull)和推送(push)代码是很重要的。定期拉取最新的代码可以帮助你尽早发现和解决冲突,减少最后阶段的复杂性。如果你只在开发完成时才拉取最新代码,那么可能会遇到很多冲突,需要花费大量时间来解决。
当你准备提交你的代码时,你应该首先从远程仓库拉取最新的代码,然后合并(merge)到你的开发分支。这时,你可能会发现一些冲突。这些冲突需要你手动解决,Git提供了工具来帮助你标识和解决这些冲突。一旦冲突解决,你就可以将你的代码推送到远程仓库。
详细操作步骤如下:
这样,你的分支就包含了所有在你开发过程中主分支上的新提交,同时也包含了你自己的更改。
note:如果发生了拉取的冲突。则将软件版本回溯到之前有联系的版本,与远程库建立联系之后,然后将新的更改再合并到分支中去。