基本操作
-
设置本机所有仓库的大标识
git config --global user.name "maoni"
git config --global user.email "[email protected]" -
初始化仓库。（这个仓库被一个文件夹管理）
git init -
放到暂存区和推送版本
git add 文件or文件夹
git commit -m '注释' -
一般有这样的操作，我在某一个版本上进行修改，修改的还挺多的，但是发现修改的内容是错的，需要撤销这些修改，除了版本回退，还有命令：
git checkout -- 文件
但是如果已经将修改放到了暂存区，只会回到暂存区的状态。
这种撤销是对单个文件来的，期间你对其他文件进行操作都不影响其他文件，新增一个文件，就要将其add,不然就不回追踪这个新文件 -
查看所有版本和回退版本
git reflog
git reset --hard 版本号
合并与分支
- 创建并切换分支
git checkout -b dev
文件还是那些要受控制的文件，只是你单独创建一条分支，这条分支上，你对现有的版本进行更改，但是不会影响到主分支（他的线路还是原来的，互补干扰），当你个人的一条分支的修改有用时，将此分支的当前版本合并进主分支，实质上就是将主分支指向你的当前这个分支上的版本。
在新分支上进行的任何操作，即使提交了，也不会影响到主分支。 所以在切换回主分支之后git checkout master,在主分支上合并分支git merge dev
- 解决冲突
发生冲突指在主分支和其他分支上对相同行或者相同区域进行了不同的修改。解决冲突的方式一般而已还是以master为主，？？？？？？
分支策略：首先master主分支应该是非常稳定的，也就是用来发布新版本，一般情况下不允许在上面干活，干活一般情况下在新建的dev分支上干活，干完后，比如上要发布，或者说dev分支代码稳定后可以合并到主分支master上来。
合并分支时git merge –no-ff -m “注释” dev防止当删除分支时，分支的版本号消失。
- bug分支
当你在分支dev上修改时，临时收到了一个bug-404，而dev的bug尚未修复，bug-404比较紧急，此时需要保护现场(那我还不如直接commit这个版本呢)，命令为git stash，然后切换到主分支上，再建立bug-404分支。
注意当master分支已经改变过时，就不要再使用以前的dev分支了,而是在最新的master上建立dev分支，所以在这之前可以把以前的dev分支给删掉。删除分支为git branch -d 分支名
什么时候冲突，什么时候不会冲突，我还没搞清楚诶。
搞清楚了，当在master下创建分支dev，并在dev上进行了修改之后commit，此时回到master上合并是不会发生冲突的，会发生冲突的情况在于回到master之后此时的master版本也是被修改过的，也就是当前已经不是创建dev时的master版本，此时进行合并时就会发生冲突。所以上面在修复完bug合并bug-404之后，再回到之前的dev时，此时master已经改变了，所以就会冲突。
但是在多人协助的时候，或者遇到当前分支还没修复完成时，先修复另外的bug，导致冲突时，就只能比较了？？--这里还有更多的东西要看，明天上午吧
在vscode中倒是有插件来处理：
Accept Current Change 保留当前分支的代码
Accept Incoming Change 保留合并分支的代码
Accept Both Change 保留两者
Compare Change 对比改动
根据自己需要，点击这四个按钮中的一个就行
建立远程连接
这句话将本地仓库关联远程仓库。
git remote add origin [email protected]:maoni99999/testgit.git 很快就完成
git push origin -u master 开始推送。我们一般只会对主分支的最新版本进行推动，当然也可以推送分支版本，每次的推动都会有记录，github中显示的是你推动的最新版本。好方便啊。在本地每做好一个版本就使用git push origin -u master推送上去。
如何协作
一个很重要的点，在github下克隆到本地，本地的git就会自动把本地分支和远程github分支联系起来，此时在本地有任何改动，commit出新的版本，也可以通过git push origin -u master把改动同步到远程github分支。那这样就可以形成一张网络了。
如何协作？
首先你的同事的另外电脑，此电脑