早期：故事：
写个代码为了某些需求要一些操作，比如复制粘贴用于备份。属于手工管理代码版本时代，随着时间推移，手工版本成本太高。毕业论文最后一班，真最后一班，真真最后一班。有时候还需要用到昨天的版本。由此，需要制作一种工具、流程对版本进行控制和切换。早期属于集中式控制，SVN。中央库。搜有人对中央服务器进行提交。弊端：速度慢，我们可能需要大量时间浪费在代码提交，代码迁出。所以就有了分布式版本控制，git。作者：维纳斯。是unix keno 的开发人员，业界审计任务。当他需要续费的时候，他决定自己开发！开启了分布式版本控制时代！keno编程了git。keno开发人员特别多。svn区别：有本地库远程库，本地库是对远程库的拷贝。在svn中的提交和推送 打断
svn中情况，歇一天代码，下班之前推送本，时间关系。
git中可以随时提交，
svn是思想：万物皆字节。二进制流的差异比较，弊端：zip。相同的内容多次打包那么二进制流差异巨大。当我把类库更新的时候，差异很大。
git：以行作为保存单位。以文本的方式，（当然也可以通过配置来进行紫定华，文本按行，图片按相似点，）通过文件去比较。当文件发声冲突的时候，当我们利郎个人同事修改一个文件的时候哦，遇到冲突。差异并不仅仅体现在不同的部分。git以行的单元进行保存，则更加智能的对差异进行识别。优势：不仅仅在于分布式，并且对于差异化有着更好的处理。
git概念难点
代码，本地库，远程库。
本地库是对远程源的拷贝。远程源可以有多个，默认情况有一个。
主干开发，分支开发。
分支概念：学习曲线略高。一般使用主干开发，分支的创建，树形结构，分支创建的起点和终点应该在一个链上。
分支两点之间一条线，就怕环形结构。a——》b————》c
从哪来一定要回到哪里去。 我们的期望值是树形结构。
git开发分支开发：在此一定要说gitflow
gitflow工作流：是一个对git的扩展，不是自带的，他将复杂抽象的git概念更加清晰。
（手动展示了一个本地源新项目，完成初始化。）
简化为三件事情：
- 新功能
- 新版本
- 修复线上bug
约定大于配置，我们约定分成这三种事情。
主分支：master。第一次提交的默认目标分支。
当gitflow初始化之后，又了master和devlop分支。
master永远是最新最完整的线上版本。
devlop永远是最新最完整的本地版本，可执行！
开启
吕寰打扰我一会儿。。。。
feature是最简单的，
hotfix 热修复
release发布版本
两个分支
写下作者名。
写下当前日期。
不同分支下不同人写的东西互不影响。
审查分支，可以就结束分支。和到devlop
审查第二个分支，可以结束。河道devlop；
冲突，
<<<<<<<<<<<
魏涛
==========
2017-01-11
>>>>>>>>>>
不建议修改commit文本中的信息。
feature从devlop而来，回devlop而去。
发版本：1.0
提交之后，完成当前版本。（刚才是完成当前分支。）
release最终回到的位置是，先回到master，再回到devlop，然后在master上打一个tag，名字就是分支名字。
hotfix：1.0.1，一定是开始于master、
工作流：
github有自己的工作流
开源软件如何
fork ： 拷贝名下
pull request：以一个分支的形式退给作者。
在gitflow里面，没有明确代码审核的环节。
github自带的有审核环节。
抓取
拉取
推送
commit
pull
push
fetch
stash
。
