Git版本控制原理了解

版本控制的历史

集中式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