Git版本控制_姚伦.pptx

Git版本控制入门培训版本控制系统Git历史Git基础Git进阶Git实战 版本控制是一种记录若干文件内容变化，以便将来查阅 特定版本修订情况的系统。当我们仅对保存着软件源代码的文本文件 作版本控制管理，而实际上，你可以对任何类型的文件进行版本控制。 如果你是位图形或网页设计师，再或者是一名程序名，可能会需要保存某一幅图片、一个页面布局文件或一个代码文件的所有修订版 本。采用版本控制系统（VCS）是个明智的选择。有了它你就可以将某个文件回溯到之前的 状态，甚至将整个项目都回退到过去某个时间点的状态。你可以比较文件的变化细节，查 出是谁最后修改了什么地方从而造成某些怪异问题，又是谁在何时报告了某个功能缺陷，等等。使用版本控制系统通常还意味着，就算你胡来搞砸了整个项目，把文件改的改，删的删，你也可以轻松恢复到原先的样子。而由此额外增加的工作量却微乎其微。个人的版本控制? 时光机? 云存储? 在GitHub上的博客、“简历”? 项目的版本控制? 工作协同? 发布管理? Debug (git bisect)? 代码审核? 持续集成 许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单，不过坏处却不少：有时候会混淆所在的工作目录，弄错了文件丢了数据就没了后退的路。 为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？于是，集中化的版本控制系统（ Centralized Version Control Systems，简称 CVCS ）应运而生。这类系诸如 CVS，Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法（见图 1.2）。这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。现在，每个人都可以一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库轻松容易得多。事分两面，有好有坏。这么做最显而易见的缺点是中央服务器的单点故障。若是宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。如果中央服务器的磁盘发生故障，并且没做过备份或者备份得不够及时的话，还会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录，被客户端提取出来的某些快照数据除外，但这样的话依然是个问题，你不能保证所有的数据都已经有人提取出来。本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新信息的风险。于是分布式版本控制系统（ Distributed Version Control System，简称DVCS ）面世了。在这类系统中，诸如Git，Mercurial，Bazaar 还有Darcs 等，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份? CVS, 1986/1990? Subversion, 2001/2004? ClearCase, 1992? Visual SourceSafe, 1994? Perforce, 1995? Starteam, 1995? Team Foundation Server, 2005? Rational Team Concert, 2008? Linux Kernel? Perl? Eclipse? Gnome? KDE? Qt? Ruby on Rails? Android? PostgreSQL? PHP? Debian? X.org? Prototype, jQuery集中式版本控制优点缺点一台服务器共享；协同性能瓶颈；单点故障；备份网络操作分布式团队；远程开发慢；无法移动办法递增式提交历史不会破坏提交过时；频繁冲突集中授权基于路径的读写授权项目参与度低分布式版本控制优点缺点全是服务器最安全；无带宽和性能瓶颈习惯和方式的转变本地提交操作快；移动办公忘记推送（PUSH）数据校验版本库不被篡改历史变更影响最新数据非线性提交真正的分支；合并更容易提交版本号太长多样化协同模型对新人的审核；受控库习惯的转变提交可更改提交修正和重构提交丢失Git是一个分布式版本控制／软件配置管理软件，原来是linux内核开发者Linus Torvalds为了更好地管理linu