git基础原理

1、版本控制

       分布式管理与集中式管理：

     比较一：

 

比较二：

git的工作区域与文件不同的状态

2、git分支：

    每提交一次，都会包含一个指向前一个提交对象的指针，默认为master，并且自动向前移动。master指向新的版本：

       

   新建一个分支(git branch name)时，例如testing分支(git branchtesting)，就会有一个新的指针指向当前commit对象：

          

  那么，Git是如何知道你当前在哪个分支上工作的呢？其实它保存着一个名为HEAD的特别指针。它是一个指向你正在工作中的本地分支的指针(正指向master，所以master为当前所在分支)：

  

  切换到testing分支(git checkout testing),head指向testing分支，于是就可以在testing分支上开发了:

 

  在testing分支上开发并commit之后:

  

 切回master分支(git checkout master):

 

 在master分支上commit之后，会形成分叉，此时若需要合并，就需要进行冲突处理了。

3、远程分支：

        我们用(远程仓库名)/(分支名)这样的形式表示远程分支。比如origin/master分支。例如：

  假设你们团队有个地址为git.ourcompany.com的Git服务器。如果你从这里克隆，Git会自动为你将此远程仓库命名为origin，并下载其中所有的数据，建立一个指向它的master分支的指针，在本地命名为origin/master，但你无法在本地更改其数据。接着，Git建立一个属于你自己的本地master分支，始于origin上master分支相同的位置，你可以就此开始工作了。

 如果团队中另外一个人修改了master分支并且推送到该远程仓库：

  此时向远程提交代码就会有冲突导致提交失败，就需要拉取(git pull或者git fetch)代码合并后进行处理，解决冲突，再进行提交到远程仓库(git push)。

4、多人协作

    当一个团队同时开发一个项目时，有一个主分支(master)，一个开发分支(dev)，其余每个开发人员有自己的分支，master分支上时最稳定的版本，即在线使用的版本；dev分支超前于master分支，可以提供一些新的功能或者bug修复，经受住测试后再往master上合并。其余每个人都有自己的开发分支，从dev上拉取团队代码或者提交代码，这样就可以保证高效，并且master的稳定性了。

  

参考自《Pro Git》