什么是版本控制：
•最早的版本控制是手工的。
•如果从1改到2，我们还能知道改动了什么，回滚起来也很简单。
•但如果从二再继续改到3,4,那么再要回到之前版本就容易出错了。就像我们常用的ctrl+z
•版本控制系统能自动记录每一次版本变更的内容，能准确快速的回到指定的某个版本状态。
git仓库
初始化版本库 git init
添加文件到版本库 git add git commit
查看仓库状态 git status
git的基本操作
•打开git bash
•以下都是linux基本命令
•获取当前目录 pwd
•展示当前目录下文件信息的长格式 ll
•到指定目录下创建文件夹 cd d: mkdir gitdemo
•初始化版本库 git init
•显示当前目录下所有文件（含隐藏文件） ls -a
•使用输入重定向将字符串保存在test.txt文件中 echo “git repo1” >>test.txt
•查看test.txt里的内容 cat test.txt
•添加test.txt到版本库 git add test.txt
•提交确认，添加保存信息。 git commit -m “repo first commit”
•查看当前版本库的状态。 git status
git的工作流
•情景：第一天产品经理要求做个bash脚本，于是我在gitdemo中新建了文件夹demo2，并且新建了文件bashdemo.txt,里边写了，第一天产品经理要求的bash已完成。
•然后用git bash进到进入demo2文件夹 执行git status 提示我有未保存的文件，建议我add然后commit。我照做了。快下班了老板有个临时要求，我说只能做一部分。于是我就做了。要下班了，我用add保存了。没提交。
•第二天来了，产品经理说，那个修改不要了。我有点生气。通过git reset Head bshdemo.txt撤销了这次保存。 通过git checkout -- bashdemo.txt 退回了修改的内容。然后布置了新内容，我完成了也添加提交了。
•第三天来了。产品经理突然说，其实昨天的修改用不上，我们就用第一天的结果就行。我提起了10米长刀，又默默的放下了。我通过 git log 获取了第一天的保存记录号。然后通过 git reset --hard 记录号回滚到了第一次保存后的结果。抽了根烟后，又开始了愉快的工作。
•其实当时我有这样想：太气人了，删库跑路吧。我可以这样做的git rm bashdemo.txt 然后提交删除 git commit -m “我走了，勿念。”
添加远程仓库
•点击头像后边的加号添加远程仓库，然后选择ssh得到git@github。。。。。。。地址
•创建本地仓库，执行git init--创建文件 echo “testgitdemo”>>README.md--git add README.md--保存到暂存区--提交保存到本地目录树 git commit -m“xxx”--连接远程仓库
•git remote add origin 上边的地址连接远程仓库。
•将本地master和远程仓库同步。
•git push -u origin master
•如果已经同步过第二次直接用git push即可。
•断开连接 git remote rm origin
克隆仓库
•将远程仓库中的代码克隆一份到本地。
•本地创建目录
•gitbash 进入该目录 ls -a查看当前目录下有没有.git如果没有就可以克隆
•git clone git@github.com:xxxxxx/xxx.git
•ls -a
•进入文件夹后即可开始操作
•克隆下来后就可以修改文件，add commit
•因为克隆的时候已经自动将本地和远程仓库对应上了所以这次直接git push即可同步文件。.
git的研发流程
常见问题：
- 在gerrit平台上使用merge的方法合入代码
- 不了解保护分支，Code Review, CI等概念，研发流程不规范
- 代码历史混乱，代码合并方式不清晰
集中式工作流：只依托于master分支进行研发工作
分支管理工作流
- Git Flow :分支类型丰富，规范严格
- Github Flow 只有主干分支和开发分支，规则简单，基于Pull Request 往主干分支提交代码
- Gitlab Flow 在主干分支和开发分支上构建环境分支，版本分支，满足不同发布or环境的需要
