Git可以完成两件事情：
1. 版本控制
2.多人协作开发
如今的项目，规模越来越大，功能越来越多，需要有一个团队进行开发。
如果有多个开发人员共同开发一个项目，如何进行协作的呢。
Git提供了一个非常好的解决方案 ---- 多人协作开发。
典型的做法是，首先创建一个git服务器，被多个人所操作。
分为如下几个步骤：
1.创建一个git裸服务器 （git init --bare）
2.从裸服务器将版本库克隆至本地（git clone ）
3.本地常规操作
4.推送版本至服务器 （git remote + git push origin master）
5.从远程服务器拉取版本（git pull）
一般而言，我们需要在Linux服务器上来搭建我们的git版本服务器，每个公司都会有。
由项目负责人开始。
我们现在是windows系统上模拟这个操作过程。
由负责人来完成的。服务器新建一个项目目录，如git-server
创建完毕，我们发现git-server内容和上次的不太一样。
上次使用git init 创建之后，会有一个隐藏的.git目录。目录中的才是现在看到的内容。
也就是说，现在根本就没有.git目录了。
这就意味着在这个目录中，不能做常规的开发。
在git版本服务器，一般是不做任何开发工作的。如果要开发项目，就需要将版本库从服务器克隆到本地。
假设有一个程序员甲，开始自己的工作了。
使用命令 git clone git版本服务器地址
在windows下面，就是使用绝对路径，如下：
然后，甲就可以在这个目录下，进行常规开发。
我们可以在这个目录下，创建自己的工作区目录，完成常规开发。
甲可以，在本地进行常规开发。
这个过程，可以反复进行。
我的第一个模块（功能）开发完毕。需要将其推送到服务器。
当在本地完成一个模块（功能），需要推送到服务器，供其他同事使用。
第一件事情，需要知道服务器在哪儿？
git remote
第二件事情，直接推送即可
git push origin master
其中origin就是使用git remote得到的远程服务器的名称。
master表示是主分支。
对于甲来说，它的工作已经告一段落了，该轮到乙程序员出场了。
乙程序员，首先将版本库从git服务器上克隆到本地。
打开这个目录，然后进可以看到最新新的内容，如下：
对于乙而言，可以在本地进行常规开发。与此同时，甲继续他的常规开发。
模拟乙程序员在本地的开发。
将完成的工作，推送到git服务器。
回头，再看看甲的开发。
甲收工，准备下班了。在下班之前，需要将最新版本推送到git服务器。
开始使用命令，执行如下：
结果出错了，why？
之所以会出错，原因在于：其他程序员已经将最新的一个版本提交到git服务器上，但是你在提交之前，已经不是最新的。
在这种情况下，甲，需要先从服务器拉取最新的版本。
在多人协助开发时，每个开发人员在推送自己的最新版本时，都需要确保当前版本是最新的，所以就需要先获取最新版本，也就是说需要从服务器拉取最新版本到本地。
需要使用 git pull命令
如此一来，甲当前就是最新的版本。
然后再次使用 git push 命令推送至服务器。
接下来需要分两种情况：
如果有新的开发人员加入进来，重复2~5过程。
如果不是新的开发人员，重复3~5过程。
比如，对于乙而言，其实它现在已经不是最新的版本了，所以需要使用 git pull 拉取最新版本。
所以，对很多开发人员而言，一打开电脑，马上先git pull，拉取最新的。然后进行常规开发，
开发完毕之后，在git push之前，还需要使用git pull再拉取一遍。
如果还有一个新的程序员丙，加入了，怎么办呢？
需要先git clone
然后就进行常规开发，推送版本、拉取版本。
在整个协作开发时，有时候会出现冲突。通常都是由于开发人员分工不明确导致的，所以如果出现这种情况，需要两个程序员协商解决。
在前面所有的操作当中，我们一直使用的是master主分支。以刚才的项目版本控制为例
有四个版本，在我们的版本库中，都是存在于master主分支上的。
图示如下：
如果我们的项目本身比较简单，只需要有主分支master就够了。
但是，实际上并不是这样的。
在这个世界上，有一种软件叫做开源软件 -- 源代码开发，所有的人都可以免费使用。
开源软件是由世界上无数的程序员共同来开发。
每个程序员都可以创建一个自己的分支，这个自己分支和主master完全独立的两个分支。
相应的，每个程序员都可以拥有自己的分支，可以进行任何的开发，此时和master没有什么关系的。
一旦开发完毕，就可以将你的分支合并到主分支上去。
什么时候会用到分支呢？
假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险，怎么办？
你可以创建一个属于自己的分支，别人看不见，还继续在原来的分支上工作，而你在自己的分支上进行开发，等开发完毕，合并即可。
在开源世界中，需用大量的程序员共同维护一个项目。也是需要使用分支，如Jquery。
基本操作有如下几个：
1. 查看当前分支 （git branch）
2. 创建分支 （git branch 分支名）
3.切换分支（git checkout 分支名）
4.分支上的常规操作
5.分支的合并 （git checkout master + git merge 分支名）
6.分支的删除（git branch -d 分支名）
查看当前分支 （git branch）
其中的 * 表示 当前分支。
默认情况下，只有一个master主分支。
创建分支 （git branch 分支名）
切换分支（git checkout 分支名）
创建完成之后，就有了一个新的分支，但是并没有立即切换到新的分支，需要使用命令切换一下。
分支上的常规操作
已经切换到b1分支上，就可以在b1分支进行常规开发和操作。
使用git add 和git commit提交。
使用git log查看即可：
与之对应的，我们再次切换到master分支上看看是什么情况：
说明在master分支上，并没有新提交的内容。
分支的合并 （git checkout master + git merge 分支名）
分支的合并，一定是在 主分支上进行的。
只能在主分支合并其它分支。
需要两步：
1） 切换到主分支
2） 使用git merge 分支名 进行合并
再次查看master的一个log情况，如下：
分支的删除（git branch -d 分支名）
使用命令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分支的使命已经完成，没有什么作用了，将其删除掉。只剩下一个主分支。
相关文章
