开源中国 Git 代码托管平台 —— http://git.oschina.net

如果你在读这篇文章，说明你跟大多数开发者一样对GIT感兴趣，如果你还没有机会来试一试GIT，我想现在你就要了解它了。

GIT不仅仅是个版本控制系统，它也是个内容管理系统(CMS),工作管理系统等。如果你是一个具有使用SVN背景的人，你需要做一定的思想转换，来适应GIT提供的一些概念和特征。所以，这篇文章的主要目的就是通过介绍GIT能做什么、它和SVN在深层次上究竟有什么不同来帮助你认识它。

那好，这就开始吧…

1.GIT是分布式的，SVN不是：

这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。如果你能理解这个概念，那么你就已经上手一半了。需要做一点声明，GIT并不是目前第一个或唯一的分布式版本控制系统。还有一些系统，例如Bitkeeper, Mercurial等，也是运行在分布式模式上的。但GIT在这方面做的更好，而且有更多强大的功能特征。

GIT跟SVN一样有自己的集中式版本库或服务器。但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提 交文件，查看历史版本记录，创建项目分支，等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。

同样，这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐，你不必再像以前那样做出补丁包，通过email方式发送出去，你只需要创建一个分支，向项目团队发送一个推请求。这能让你的代码保持最新，而且不会在传输过程中丢失。GitHub.com就是一个这样的优秀案例。

有些谣言传出来说subversion将来的版本也会基于分布式模式。但至少目前还看不出来。

2.GIT把内容按元数据方式存储，而SVN是按文件：

所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。如果你把.git目录的 体积大小跟.svn比较，你会发现它们差距很大。因为,.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分 支，版本记录等。

3.GIT分支和SVN的分支不同：

分支在SVN中一点不特别，就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支，你需要手工运行像这样的命令svn propget svn:mergeinfo，来确认代码是否被合并。感谢Ben同学指出这个特征。所以，经常会发生有些分支被遗漏的情况。

然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。

4.GIT没有一个全局的版本号，而SVN有：

目前为止这是跟SVN相比GIT缺少的最大的一个特征。你也知道，SVN的版本号实际是任何一个相应时间的源代 码快照。我认为它是从CVS进化到SVN的最大的一个突破。因为GIT和SVN从概念上就不同，我不知道GIT里是什么特征与之对应。如果你有任何的线 索，请在评论里奉献出来与大家共享。

更新：有些读者指出，我们可以使用GIT的SHA-1来唯一的标识一个代码快照。这个并不能完全的代替SVN里容易阅读的数字版本号。但，用途应该是相同的。

5.GIT的内容完整性要优于SVN：

GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。这里有一个很好的关于GIT内容完整性的讨论 –http://stackoverflow.com/questions/964331/git-file-integrity

GIT和SVN之间只有这五处不同吗？当然不是。我想这5个只是“最基本的”和“最吸引人”的，我只想到这5点。如果你发现有比这5点更有趣的，请共享出来，欢迎。

三、详细透彻解读Git与SVN的区别（集中式VS分布式）

• Git 只关心文件数据的整体是否发生变化，而SVN这类版本控制系统则只关心文件内容的具体差异。这类系统（如SVN）每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容，然而Git 并不保存这些前后变化的差异数据。实际上，Git更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一链接。

• 在Git 中的绝大多数操作都只需要访问本地文件和资源，不必联网就可以看到所有的历史版本记录，而SVN 却需要联网。因为 Git 在本地磁盘上就保存着所有当前项目的历史更新，所以处理起来速度飞快，但我们需要浏览项目的历史更新摘要，Git 不用跑到外面的服务器上去取数据回来，而直接从本地数据库读取后展示给你看。如果想要看当前版本的文件和一个月前的版本之间有何差异，Git 会取出一个月前的快照和当前文件作一次差异运算。

• SVN 断开网络或者断开VPN就无法commit代码，但是Git 可以先commit到本地仓库。用SVN的话，没有网络或者断开VPN时，你当然也可以继续在本地开发，但是无法commit代码，因为SVN 每次commit都必须联网，长时间不commit代码会丢失大量开发进程的历史纪录。有个比喻是：不能commit就像用word写文档不能save一样危险。而且有网络的情况下每一次commit都会花上数秒甚至更长时间。但用 Git 的话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新，因为是在本地仓库commit所以几乎不需要时间，而且commit一定要频繁，不然无法记录你的改动，如果你一天commit一次，中间的修改你就找不回来，然后等到了有网络的时候再将版本纪录和代码一起上传到远程仓库。

• Git 的内容完整性要优于SVN。因为Git 在commit（存储在本地）或者push（上传到远程仓库）之前，通过对文件的内容或目录的结构计算出一个 SHA-1哈希值，作为指纹字符串进行内容的校验，并将此结果作为数据的唯一标识和索引，在远处仓库接受到commit的文件之后，会再计算一遍哈希值然后跟传递过来的哈希值做比较，如果不一致，说明文件在传输时变得不完整，或者磁盘损坏导致文件数据损坏。另外在 Git 数据库中的东西都是用此哈希值来作索引，而不是靠文件名。

• Git 克隆一个完整项目的速度非常快，SVN 非常慢。我们以克隆一份拥有五个分支的完整项目以及版本库来说，SVN是同时复制5个版本的文件,也就是说重复五次同样的动作。而Git 只是获取文件的每个版本的元素，然后只载入主要的分支(master)在我的经验，克隆一个拥有将近一万个提交(commit)，五个分支，每个分支有大约1500个文件的 SVN，耗了将近一个小时！而Git只用了区区的1分钟。

• 其中最重要的区别是在于Git 上的分支远比SVN上的强大。下面具体介绍分支的概念。

• 在 SVN 这类的版本控制系统上，分支（branch）是一个完整的目录，且这个目录拥有完整的实际文件。如果工作成员想要开启新的分支，那将会影响“全世界”！每个人都会拥有和你一样的分支。如果你的分支是用来对系统模块进行安全检查测试的，那将会像传染病一样，你改一个分支，还得让其他人重新切分支重新下载，而且这些代码很可能对稳定版本还是具有破坏性的。

• 在 Git上，每个工作成员可以任意在自己的本地版本库开启无限个分支。举例：当我想尝试破坏自己的程序（安检测试），并且想保留这些被修改的文件供日后使用， 我可以开一个分支，做我喜欢的事。完全不需担心妨碍其他工作成员。只要我不合并及提交到主要版本库，没有一个工作成员会被影响。等到我不需要这个分支时， 我只要把它从我的本地版本库删除即可，无痛无痒。

• 我们在开发新的功能模块时，可能会遇到各种bug或者冲突，如果我们还在主分支上开发，万一冲突很严重，造成当前稳定版本的分支出问题，就会很麻烦。如果主分支始终保留着最新的稳定版本，在新的分支上开发，冲突严重时，最多也就是把当前分支删掉，从那个稳定分支重新分一支出来，这样处理起来就方便了，而且分支还可以保留开发中可能出现的各种bug方便修复但不影响主分支多的使用。

• 当我们需要切换分支，例如切换到主分支（master）时候，会保存当前分支（dev）的状态，以便日后继续开发，防止丢失开发进度。举个例子：你突然接到一个电话说1.0发布版本有个很严重的问题需要紧急修补，而我们正在dev分支上开发新的功能模块，这时我们先返回到主分支，为这次紧急修补建立一个新分支（repair分支），并在其中修复问题。通过测试后，回到主分支，将repair分支合并进来，然后push到远程仓库。最后，我们切换到之前开发新需求的dev分支，继续工作而不会丢失掉已经开发的进度。

• Git 中每个克隆(clone)的版本库都是平等的。可以从任何一个版本库的克隆来创建属于自己的版本库，同时你的版本库也可以作为源提供给他人，只要你愿意。
• Git 的每一次提取操作，实际上都是一次对代码仓库的完整备份。
• 提交完全在本地完成，无须别人给你授权，你的版本库你作主，并且提交总是会成功。
• Git 的提交不会被打断，直到你的工作完全满意了，PUSH给他人或者他人PULL你的版本库，合并会发生在PULL和PUSH过程中，不能自动解决的冲突会提示你手工完成。

• Git 没有严格的权限管理控制，一般通过系统设置文件读写权限的方式来做权限控制。
• 工作目录只能是整个项目。比如 checkout，建分支，都是基于整个项目的。而 svn 可以基于项目中的某一个目录

四、Git之CodeReview流程

为什么要codereview

. 整个团队的编码风格是统一的。

. 有高手能对自己的代码指点一二，从而提高编码水平。

. 减少低级错误的出现

. 约束自己写高质量的代码，因为是要给人看的。

我们对codereview的需求

. 很轻松可以发布自己写的代码。

. 很轻松的可以与老代码diff review。

. review的人和被review的人很轻松的交互，而且还能保存交互的历史。

Code Review流程

1、根据开发任务，建立git分支, 分支名称模式为feature/任务名，比如关于API相关的一项任务，建立分支feature/api。
git checkout -b feature/api

2、运行git branch 确认切换到了feature/api分支

3、编辑代码完成开发任务， commit相关代码
git add -A
git commit -m "implement api architecture"

4、将分支代码push到服务器
git push origin -u feature/api

5、登录到bitbucket的源代码库，如https://bitbucket.org/xxxx/ljq_web ，点击Pull request按钮去创建一个pull request

6、再pull request详细页面， 填写相关标题／说明／reviewer， 目前请将reviewer设成lijing_dkhs和zhuangqunxiong

7、请提醒reviewer去审核pull request，系统也会发邮件提醒reviewer

8、Reviewer打开pull request页面，查看代码修改情况，也可以在相应的代码处添加注视，提示代码作者哪里应该修正。

9、代码作者根据reviewer的要求，调整代码后commit／push到服务器。 然后reviewer继续设置， 如此循环，知道没有问题。

10、当代码没有问题以后， 需要将任务代码merge到主代码库， 有两种方法：
a、Reviewer可以在pull request页面点击Merge按钮， 把代码merge到主代码库
b、代码作者自己merge到主代码库， 并push到服务器。
git pull origin
git log ..master

如果看到master里有修改没在当前分支， 那么运行git rebase master来把master的修改加入到当前分支
运行一下合并命令
git checkout master
git merge --no-ff feature/api
git push

11、代码作者删除feature子分支。
git checkout master
git branch -D feature/api
git push origin :feature/api

git pull origin master #从主分支pull到子分支

本文出自：https://www.zhihu.com/question/19601997

https://www.cnblogs.com/muxiaoye/p/41233eef203781bde28a772cdb3731f5.html

https://blog.csdn.net/hellow__world/article/details/72529022

https://blog.csdn.net/june_y/article/details/50817993