开放原子开发者工作坊

其实我在写这篇随笔的时候连Git是什么都不知道,只是听说过,也注册了一个GitHub的账号,但并不会玩.

我也是查看了半天的网页才明白一个大概,但我觉得以后肯定会经常用到它.

简单的来说， Git 是一个分布式的版本控制系统。顾名思义，在你编辑程序代码的时候（特别是在多人协作一个项目时），它将会自动帮你实现代码以及版本的更新。这意味着你不必 每次都手动地将自己修改的内容同步到云端。这些工作都可以由 Git 在适当的时候自动完成。这样既能避免手动同步的麻烦和风险，更能为程序员省下大量时间。

百度官方解释:Git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。Git是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

那版本控制系统又是什么呢?

1.简单的来说就是,服务器端有个初始的空间存储的你的工程,我们称它为版本'A'.

2.然后每一个开发者从服务器拷贝'A'到他们本地电脑的时候,由于他们会做不同的开发,所以本地的'A'版本就会发生变化.从而会有B,C,D,E,F等N多个基于'A'版的衍生版本.

3.这时候开发者1,首先完成版本的更替,将'B'版本提交到了服务器,这时,服务器的当前版本被更新为了'B'.

4.当另外的开发者2,想要提交他完成的'C'版本的时候,发现服务器中的版本并不是原始版本'A',而是其他版本'B',此时他想要更新服务器版本为'C'的话,必须合并修改'B'版本到他的'C'版本中,(其实就是'B'版本不兼容'C',只有'A'版兼容'C',毕竟'C'是基于'A'的,和'B'没有关系).

然而，大多数现代的版本控制系统十分高级，能够自动在开发者的本地拷贝上完成合并。有几种情况会产生冲突（例如：开发者1和开发者2同时修改了同一个文件 的同一行）。这就是一些VCS产品比其他更高级的地方。不论如何完成合并，现在开发者2在他们的本地系统上同时混合了版本B和版本C。

也就是说,开发者2的'C'版本在本地自动的完成了和服务器上'B'版的合成.用网上的一张图来解释吧:

 

上面的全过程就是版本的控制系统,能够自动在开发者的本地上拷贝完成版本的合并.

目前有很多不同类型的版本控制系统（Version Control System， VCS）。一些VCS，比如Subversion和CVS，以中央仓库（repository）为中心进行架构。此外，还有分布式的VCS（Distributed VCS，DVCS）， Git 和 Mercurial 是两个新近出现的DVCS。

那好,现在我们再回来说说Git:

分布式相比于集中式的最大区别在于开发者可以提交到本地，每个开发者通过克隆（git clone），在本地机器上拷贝一个完整的Git仓库。

Git的功能特性：

从一般开发者的角度来看，git有以下功能：

1、从服务器上克隆完整的Git仓库（包括代码和版本信息）到单机上。

2、在自己的机器上根据不同的开发目的，创建分支，修改代码。

3、在单机上自己创建的分支上提交代码。

4、在单机上合并分支。

5、把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。

6、生成补丁（patch），把补丁发送给主开发者。

7、看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。

8、一般开发者之间解决冲突的方法，开发者之间可以使用pull 命令解决冲突，解决完冲突之后再向主开发者提交补丁。

 

从主开发者的角度（假设主开发者不用开发代码）看，git有以下功能：

1、查看邮件或者通过其它方式查看一般开发者的提交状态。

2、打上补丁，解决冲突（可以自己解决，也可以要求开发者之间解决以后再重新提交，如果是开源项目，还要决定哪些补丁有用，哪些不用）。

3、向公共服务器提交结果，然后通知所有开发人员。

 

现在大家应该能够简单的了解Git了吧.