版本控制的历史
集中式VS分布式
1）集中式版本控制系统
版本库是集中存放在中央服务器的，先从中央服务器取得最新的版本，更新后把版本推送给中央服务器。集中式版本控制系统最大的弊端就是必须联网才能工作，如果在局域网内还好，速度够快，可如果在互联网上，遇到网速慢的话，可能提交个10M的文件就需要5分钟。
2）分布式版本控制系统
根本没有“中央服务器”，每个的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。多个人协作时，比如说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。更安全：和集中式版本控制系统相比，分布式版本控制系统的安全性要好很多，因为每个电脑里都有完整的版本库，某个人的电脑坏掉了不要紧，而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了
git下载：https://www.git-scm.com/download/win
或者 https://pc.qq.com/detail/13/detail_22693.html（腾讯工具速度较快）
git多人协作问题
多人协助实现
分为如下几个步骤：
1.创建一个git裸服务器 （git init --bare）
2.从裸服务器将版本库克隆至本地（git clone ）
3.本地常规操作
4.推送版本至服务器 （git remote + git push origin master）
5.从远程服务器拉取版本（git pull）
操作都是在master主分支上的
分支
开源软件是由世界上无数的程序员共同来开发。
每个程序员都可以创建一个自己的分支，这个自己分支和主master完全独立的两个分支。
什么时候会用到分支呢？
假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险，怎么办？
你可以创建一个属于自己的分支，别人看不见，还继续在原来的分支上工作，而你在自己的分支上进行开发，等开发完毕，合并即可。
分支的基本操作
基本操作有如下几个：
1.查看当前分支 （git branch）
2.创建分支 （git branch 分支名）
3.切换分支（git checkout 分支名）
4.分支上的常规操作
5.分支的合并 （git checkout master + git merge 分支名）
6.分支的删除（git branch -d 分支名）
分支的原理
分支的过程及原理如下：
默认只有master的情况下，master总是指向最新的版本，而HEAD指针总是指向master的。
现在，我创建了一个新的分支dev，将当前分支指定为dev，此时，master和dev都指向当前最新版本，但是HEAD指针已经指向了dev分支。
接下来，我们提交了新的版本，dev指向最新版本，而master则原地不动。
HEAD指向当前分支dev的。
当在dev分支上完成开发之后，可以将它合并到主分支master上。
合并时，需要先切换到master，意味着HEAD指向了master，合并的时候其实就是将master和dev的最新版本同步。
dev分支的使命已经完成，没有什么作用了，将其删除掉。只剩下一个主分支。
查看原文：https://blog.csdn.net/wangliang888888/article/details/80536277
原文地址：https://www.cnblogs.com/liangtao999/p/11993931.html