没有合适的资源?快使用搜索试试~ 我知道了~
温馨提示
试读
258页
本文来自网站-OPEN经验库-Git详解: http://www.open-open.com/lib/view/open1328069609436.html 作者以自己对git的深刻理解,以图文的形式通俗易懂地介绍了git的使用方式和工作原理。从中可以看出作者对git的很深的功力。只要你看你就会懂。 本文档只是对复制粘贴而已,非常推崇原作者的分享精神,对原作者表示崇高的敬意,所有版权归原作者所有。
资源推荐
资源详情
资源评论
注意,本文来自 http://www.open-open.com/lib/view/open1328069609436.html , 讲解的非常
好,在此处复制粘贴而已,对原作者表示崇高的敬意,所有版权归原作者所有。本人再次
表示这些劳动者的分享精神值得推崇,同时表示香蕉很好吃,也表示我的妞很可爱。
起步
本章介绍开始使用 Git 前的相关知识。我们会先了解一些版本控制工具的历史背景,然后
试着让 Git 在你的系统上跑起来,直到最后配置好,可以正常开始开发工作。读完本章,
你就会明白为什么 Git 会如此流行,为什么你应该立即开始使用它。
1.1
1.1
1.1
1.1 关于版本控制
什么是版本控制?我真的需要吗?版本控制是一种记录若干文件内容变化 , 以便将来查阅特
定版本修订情况的系统 。 在本书所展示的例子中 , 我们仅对保存着软件源代码的文本文件作
版本控制管理,但实际上,你可以对任何类型的文件进行版本控制。
如果你是位图形或网页设计师 , 可能会需要保存某一幅图片或页面布局文件的所有修订版本
(这或许是你非常渴望拥有的功能 ) 。采用版本控制系统 ( VCS )是个明智的选择。有了
它你就可以将某个文件回溯到之前的状态,甚至将整个项目都回退到过去某个时间点的状
态 。 你可以比较文件的变化细节 , 查出最 后是谁修改了哪个地方 , 从而导致出现怪异问题
,
又是谁在何时报告了某个功能缺陷等等 。 使用版本控制系统通常还意味着 , 就算你乱来一气
把整个项目中的文件改 的改删的删,你也照样可以轻松恢复到原先的样子。但额外增加的
工作量却微乎其微。
本地版本控制系统
许多人习惯用复制整个项目目录的方式来保存不同的版本 , 或许还会改名加上备份时间以示
区别 。 这么做唯一的好处就是简单 。 不过坏处也不少 : 有时候会混淆所在的工作目录 , 一旦
弄错文件丢了数据就没法撤销恢复。
为了解决这个问题 , 人们很久以前就开发了许多种本地版本控制系统 , 大多都是采用某种简
单的数据库来记录文件的历次更新差异(见图 1-1 ) 。
图 1-1. 本地版本控制系统其中最流行的一种叫做 rcs , 现今许多计算机系统上都还看得到
它的踪影 。 甚至在流行的 Mac OS X 系统上安装了开发者工具包之后 , 也可以使用 rcs 命
令 。 它的工作原理基本上就是保存并管理文件补丁 ( patch ) 。 文件补丁是一种特定格式的文
本文件,记录着对应文件修订前后的内容变化。所以,根据每次 修订后的补丁, rcs 可以
通过不断打补丁,计算出各个版本的文件内容。
集中化的版本控制系统
接下来人们又遇到一个问题 , 如何让在不同系统上的开发者协同工作?于是 , 集中化的版本
控制系统( Centralized Version Control Systems ,简称 CVCS )应运而生。这类系统 ,
诸如 CVS , Subversion 以及 Perforce 等 , 都有一个单一的集中管理的服务器 , 保存所有
文件的修订版本 , 而协同工作的人们都通过客户端连到这台服务器 , 取出最新的文件或者提
交更新。多年以来,这 已成为版本控制系统的标准做法(见图 1-2 ) 。
图 1-2. 集中化的版本控制系统这种做法带来了许多好处,特别是相较于老式的本地 VCS
来说 。 现在 , 每个人都可以在一定程度上看到项目中的其他人正在做些什么 。 而管理员也可
以轻松掌控每个开发者的权限 , 并且管理一个 CVCS 要远比在各个客户端上维护本地数据
库来得轻松容易。
事分两面 , 有好有坏 。 这么做最显而易见的缺点是中央服务器的单点故障 。 如果宕机一小时
,
那么在这一小时内,谁都无法提交更新,也就无法协同工作。要 是中央服务器的磁盘发生
故障 , 碰巧没做备份 , 或者备份不够及时 , 就还是会有丢失数据的风险 。 最坏的情况是彻底
丢失整个项目的所有历史更改记录,而被客户端 提取出来的某些快照数据除外,但这样的
话依然是个问题 , 你不能保证所有的数据都已经有人事先完整提取出来过 。 本地版本控制系
统也存在类似问题,只要整个项 目的历史记录被保存在单一位置,就有丢失所有历史更新
记录的风险。
分布式版本控制系统
于是分布式版本控制系统( Distributed Version Control System ,简称 DVCS )面世了
。
在这类系统中,像 Git , Mercurial , Bazaar 以及 Darcs 等,客户端并不只提取最新版本
的文件快照 , 而是把原始的代码仓库完整地镜像下来 。 这么一来 , 任何一处协同工作用的服
务器发生故障 , 事后都可以用任何一个镜 像出来的本地仓库恢复 。 因为每一次的提取操作
,
实际上都是一次对代码仓库的完整备份(见图 1-3 ) 。
图 1-3. 分布式版本控制系统更进一步 , 许多这类系统都可以指定和若干不同的远端代码仓
库进行交互 。 籍此 , 你就可以在同一个项目中 , 分别和不同工作小组的人相互协作 。 你可以
根据需要设定不同的协作流程 , 比如层次模型式的工作流 , 而这在以前的集中式系统中是无
法实现的。
1.2
1.2
1.2
1.2 Git
Git
Git
Git 简史
同生活中的许多伟大事件一样 , Git 诞生于一个极富纷争大举创新的年代 。 Linux 内核开源
项目有着为数众广的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归
档的繁琐事务上( 1991 - 2002 年间 ) 。到 2002 年,整个项目组开始启用分布式版本控制
系统 BitKeeper 来管理和维护代码。
到了 2005 年 , 开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束 , 他们
收回了免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区(特别是 Linux 的缔造者
Linus Torvalds ) 不得不吸取教训 , 只有开发一套属于自己的版本控制系统才不至于重蹈覆
辙。他们对新的系统制订了若干目标:
*
速度
*
简单的设计
*
对非线性开发模式的强力支持 ( 允许上千个并行开发的分支 )
*
完
全分布式
*
有能力高效管理类似 Linux 内核一样的超大规模项目(速度和数据量)
自诞生于 2005 年以来 , Git 日臻成熟完善 , 在高度易用的同时 , 仍然保留着初期设定的目
标 。 它的速度飞快 , 极其适合管理大项目 , 它还有着令人难以置信的非线性分支管理系统 ( 见
第三章 ) ,可以应付各种复杂的项目开发需求。
1.3
1.3
1.3
1.3 Git
Git
Git
Git 基础
那么 , 简单地说 , Git 究竟是怎样的一个系统呢?请注意 , 接下来的内容非常重要 , 若是理
解了 Git 的思想和基本工作原理 , 用起来就会知其所以然 , 游刃有余 。 在开始学习 Git 的
时候,请不要尝试把各种概念和其他版本控制系统(诸如 Subversion 和 Perforce 等 ) 相
比拟 , 否则容易混淆每个操作的实际意义 。 Git 在保存和处理各种信息的时候 , 虽然操作起
来的命令形式非常相近 , 但它与其他版本控制系统的做法颇为不同 。 理解这些差异将有助于
你准确地使用 Git 提供的各种工具。
直接记录快照,而非差异比较
Git 和其他版本控制系统的主要差别在于 , Git 只关心文件数据的整体是否发生变化 , 而大
多数其他系统则只关心文件内容的具体差异。这类系统 ( CVS , Subversion , Perforce
,
Bazaar 等等)每次记录有哪些文件作了更新,以及都更新了哪些行的什么内容,请看图
1-4 。
剩余257页未读,继续阅读
力乐天
- 粉丝: 119
- 资源: 216
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
- 1
- 2
前往页