老实说，听完他说的，并结合B站视频了解，发现他说的，并不完全正确。。。因为他分享的部署文章，做了个汉化设置，导致有些功能容易误导人，所以建议英文比较好的同学，还是别搞什么汉化了，害人害己~~~~ 例如 “Git 同步”，没想过就是 git clone 吧
一开始其实我想偏了，以为用“贮藏更改”去解决冲突：同一个文件，本地与线上不同的场景。可以想象成每个编辑人员都有自己的贮藏更改，贮藏一个自己修改过的状态，然后跟线上的冲突进行比对。如果从这里入手，我会发现我的工作量无比巨大，要解决他们本机电脑贮藏更改里跟线上的冲突，然后最终提交到线上分支（这里如果说的有问题，欢迎大家指出，小女学艺不精~），当时还真被自己搞死，以至于上周三不禁感叹，做条狗子也不错~~~
既然看网上文字说明找不到头绪，干脆去B站搜视频，最终柳暗花明 。。。跟老板的需求不谋而合，最终有个管理员合并分支（master：受保护分支），其他人从dev分支去拉代码，建立自己的分支进行文章编辑，完了合并到dev分支下，最后由统一的管理员将dev分支合并到master分支。这个实际上就是多人协同合作开发的流程~~
今天比较坑，因为仓库用的是码云：gitee.com，以dev为基准，创建自己本地分支：Branch_ljycom，编辑文件提交到远程时一直报错：
大家不用怀疑，就是ssh密钥问题！！
据说码云不认之前加上去的公钥，重新生成一个密钥放上去的时候，死活说已经被他人使用。只能删掉我本地 .ssh/id_rsa.pub 文件，然后生成
C:\Windows\system32> ssh-keygen -t rsa -C 'xxx@xxx.com'
最后讲下B站视频里面还有断断续续测试（公司总有杂七杂八的事分散我注意力）给我的启发（可能对很多人来说比较浅显，我接触git比较少咯）呼应下标题：
（1）搞清楚自己本地建的分支，及推到远程的分支
像下图实际上是本地建的分支，没推到远程前是没有该分支信息的
（2）自己改文件，直到推送到远程的流程
a）本地切换到dev分支，拷贝远程最新的代码下来，然后建自己分支，例如：Branch_ljy，在自己分支上去添加或修改内容
b）本地改好后先切换到dev分支，然后选则merge（合并）自己的本地分支内容
c）把本地dev分支提交到线上（origin/dev）
（3）多人改同一个文件，提交到远程的流程
比如，有人编辑好自己的分支某个文件 ljy.txt，推送到远程dev分支，我自己本地有个Branch_ljy的分支，也改ljy.txt文件（但内容跟远程线上dev的是不同的），推送到远程的Branch_ljy很正常。但当在本地合并到本地dev时，再提交到远程dev就会报错。
这个时候要自己手动解决冲突。
这个时候你要选其一作为最终修改的版本（应该也可以两边都摘取部分，这个我还没测，不武断去评判）
再手动“标记为已解决”，最后提交（commit） ——》 推送远程（push）
先说到这里(今天整天迷迷糊糊的，可能有误人子弟的成分)，下篇再放我的测试过程