流程
一般顺序为在本地建立代码仓库，然后git init初始化生成一个.git文件作为本地仓库版本控制。
通过git clone XXXX(地址)克隆远端仓库代码到本地，进行开发。（此处省略clone前的ssh配置步骤）
当本地写好代码需要提交到远端仓库时，首先通过git add .将代码加入暂存区，再通过git commit -m “xx”对代码版本进行说明备注，最后通过git push -u origin master将暂存区提交代码提交到远端仓库。
问题
-
冲突
-
解决办法
提交出现冲突时，需要先fetch获取，手动修改冲突，之后强制pull，再add，commit，就可。
-
原因分析
如描述，A和B合作完成某项目，A先向master提交，之后B提交。但是B这边需要先fetch下来看看A在哪里改动了，是否和自己写的冲突，手动对代码进行修改，然后再pull，这里需要说明的是pull是拉取下来直接合并，所以矛盾点在这里。
-
本质
对pull这个行为的理解不到位。
-
-
版本控制
-
问题（错例）
如果要实现本地和远端协同，把远端的直接clone到本地，在本地进行更改再提交远端？
-
正解（远程库关联）
现在本地建一个文件夹，并git init,作为本地仓库，而此文件夹中通过git init生成的.git文件，就是本地仓库的版本控制器。
-
用法
用git log --graph命令可以看到分支合并图。
创建并切换到新的dev分支，可以使用：$ git switch -c dev
合并完成后，删除dev分支：$ git branch -d dev
新建标签： git tag <name>
分支和master合并： git merge XX（分支名）
补充
-
远程库的名字就是
origin，这是Git默认的叫法 -
Git用
<<<<<<<，=======，>>>>>>>标记出不同分支的内容 -
关于冲突的一些碎碎念：一篇作文，你改开头，他改结尾，一合并，满分。你改开头，他也改开头，那叫冲突，因为不知道怎么合。在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
-
关于rebase:
rebase: 使Git的提交历史成为一条干净的直线
-
rebase操作可以把本地未push的分叉提交历史整理成直线；
-
rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。
-
-
图形界面管理工具 sourcetree,界面的每个操作对应了git的不同命令。