Git版本控制_姚伦

《Git版本控制_姚伦》由会员分享，可在线阅读，更多相关《Git版本控制_姚伦（66页珍藏版）》请在金锄头文库上搜索。

1、GIT版本控制入门培训GIT实战GIT进阶GIT历史GIT基础版本控制系统什么是版本控制？我们们真的需要吗吗 ？ 版本控制是一种记录若干文件内容变化，以便将来查阅 特定版本修订情况的系 统。当我们仅对保存着软件源代码的文本文件 作版本控制管理，而实际上，你可以 对任何类型的文件进行版本控制。 如果你是位图形或网页设计师，再或者是一名程 序名，可能会需要保存某一幅图片、一个页面布局文件或一个代码文件的所有修订版 本。采用版本控制系统（VCS）是个明智的选择。有了它你就可以将某个文件回溯到 之前的 状态，甚至将整个项目都回退到过去某个时间点的状态。你可以比较文件的 变化细节，查 出是谁最后修改了什

2、么地方从而造成某些怪异问题，又是谁在何时报 告了某个功能缺陷，等等。使用版本控制系统通常还意味着，就算你胡来搞砸了整个 项目，把文件改的改，删的删，你也可以轻松恢复到原先的样子。而由此额外增加的 工作量却微乎其微。版本控制为我们解决的问题 项目的版本控制 工作协同 发布管理 Debug (git bisect) 代码审核 持续集成个人的版本控制 时光机 云存储 在GitHub上的博客、“简历”许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的 好处就是简单，不过坏处却不少：有时候会混淆所在的工作目 录，弄错了文件丢了数据就没了后退的路。为了解决这

3、个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。本地版本控制系统接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？于是，集中 化的版本控制系统（ Centralized Version Control Systems，简称 CVCS ）应运而 生。这类系诸如 CVS，Subversion 以及 Perforce 等，都有一个单一的集中管理的 服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务 器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法（见图 1.2）。这种做 法带来了许多好

4、处，特别是相较于老式的本地 VCS 来说。现在，每个人都可以一 定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者 的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库轻松容易得多。事分两 面，有好有坏。这么做最显而易见的缺点是中央服务器的单点故障。若是宕机一小 时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。如果中央服务器 的磁盘发生故障，并且没做过备份或者备份得不够及时的话，还会有丢失数据的风 险。最坏的情况是彻底丢失整个项目的所有历史更改记录，被客户端提取出来的某 些快照数据除外，但这样的话依然是个问题，你不能保证所有的数据都已经有人提 取出

5、来。本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单 一位置，就有丢失所有历史更新信息的风险。集中化的版本控制系统于是分布式版本控制系统（ Distributed Version Control System，简称DVCS ）面世了。在这类系统 中，诸如Git，Mercurial，Bazaar 还有Darcs 等，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜 像下来。这么一来，任何一处协同工作用的服务器发 生故障，事后都可以用任何一个镜像出来的本地仓库 恢复。因为每一次的提取操作，实际上都是一次对代 码仓库的完整备份分布式版本控制系统 CVS, 1986/1

6、990 Subversion, 2001/2004 ClearCase, 1992 Visual SourceSafe, 1994版本控制大爆发 Perforce, 1995 Starteam, 1995 Team Foundation Server, 2005 Rational Team Concert, 2008谁在用Git Linux Kernel Perl Eclipse Gnome KDE Qt Ruby on Rails Android PostgreSQL PHP Debian X.org Prototype, jQuery集中式版本控制优优点缺点一台服务器共享；协同性能瓶颈；单

7、点故障；备份网络操作分布式团队；远程开发慢；无法移动办法递增式提交历史不会破坏提交过时；频繁冲突集中授权基于路径的读写授权项目参与度低分布式版本控制优优点缺点全是服务器最安全；无带宽和性能瓶颈习惯和方式的转变本地提交操作快；移动办公忘记推送（PUSH）数据校验版本库不被篡改历史变更影响最新数据非线性提交真正的分支；合并更容易提交版本号太长多样化协同模 型对新人的审核；受控库习惯的转变提交可更改提交修正和重构提交丢失什么是GIT？Git是一个分布式版本控制软件配置管理软件，原来是 linux内核开发者Linus Torvalds为了更好地管理linux内核开 发而创立的。 http:/zh.wi

8、kipedia.org/wiki/GitLinus TorvaldsJunio C Hamano 濱野-純Git设计 目标 快速 简单的设计 非线性开发的强大支持（成千上万个分支） 完全分布式 高效率的处理大型项目，如linux kernel http:/git- History-of-GitGit做不到的？无锁定/解锁模式 不能排他式修改，所以Git不适合. 不能克隆子目录 所以Android有近200个Git库 整体的读授权，0/1 版本库拆分HTTPS:/GITHUB.COM/ GITHUB IS THE BEST PLACE TO SHARE CODE WITH FRIENDS, CO

9、-WORKERS, CLASSMATES, AND COMPLETE STRANGERS. OVER THREE MILLION PEOPLE USE GITHUB TO BUILD AMAZING THINGS TOGETHER.Git安装Git安装Windows Git程序 下载地址：https:/ TortoiseGit图形化工具 下载地址： https:/ 的时候，请不要尝试把各种概念和其他的版本控制系统诸如Subversion等相比拟 ，否则容易混淆每个操作的实际意义。 直接快照，而非比较差异其他系统在每个版本中记录着各个文件的具体差异Git 保存每次更新时的文件快照Git基础要点

10、近乎所有操作都可本地执行 时刻保持数据完整性Git 使用SHA-1 算法计算数据的校验和，通过对文件的内容或目录的结构计算出一个 SHA-1 哈希值，作为指纹字符串。该字串由40 个十六进制字符（0-9 及a-f）组成，看起 来就像是：24b9da6552252987aa493b52f8696cd6d3b00373 Git 的工作完全依赖于这类指纹字串，所以你会经常看到这样的哈希值。实际上，所有保 存在Git 数据库中的东西都是用此哈希值来作索引的，而不是靠文件名。 多数操作仅添加数据常用的Git 操作大多仅仅是把数据添加到数据库。因为任何一种不可逆的操作，比如删 除数据，要回退或重现都会非常

11、困难。在别的版本控制中，若还未提交更新，就有可能丢失或 者混淆一些修改的内容，但在Git 里，一旦提交快照之后就完全不用担心丢失数据，特别 是在养成了定期推送至其他镜像仓库的习惯的话。Git基础要点 三种状态对于任何一个文件，在Git 内都只有三种状态： 已提交（committed），已修改（modified）和已 暂存（staged）。已提交表示该文件已经被安全 地保存在本地数据库中了；已修改表示修改了某 个文件，但还没有提交保存；已暂存表示把已修 改的文件放在下次提交时要保存的清单中。工作目录，暂存区域和git 目录基本的Git 工作流程如下所示： 1. 在工作目录中修改某些文件。 2.

12、对这些修改了的文件作快照，并保存到暂存区 域。 3. 提交更新，将保存在暂存区域的文件快照转储到 git 目录中。初次运行Git 前的配置一般在新的系统上，我们都需要先配置下自己的Git 工作环境。配置工作只需一次，以后升级时还会 沿用现在的配置。当然，如果需要，你随时可以用相同的命令修改已有的配置。Git 提供了一个叫做git config 的工具，专门用来配置或读取相应的工作环境变量。而正 是由这些环境变量，决定了Git 在各个环节的具体工作方式和行为。这些变量可以存放在 以下三个不同的地方： /etc/gitconfig文件：系统中对所有用户都普遍适用的配置。若使用git config

13、时 用-system 选项，读写的就是这个文件。 /.gitconfig文件：用户目录下的配置文件只适用于该用户。若使用git config 时 用-global 选项，读写的就是这个文件。 当前项目的git 目录中的配置文件（也就是工作目录中的.git/config 文件）：这 里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 .git/config 里的配置会覆盖/etc/gitconfig 中的同名变量。在Windows 系统上，Git 会找寻用户主目录下的.gitconfig 文件。主目录即$HOME 变量 指定的目录，一般都是C:Documents and

14、Settings$USER。此外，Git 还会尝试找寻/ etc/gitconfig 文件，只不过看当初Git 装在什么目录，就以此作为根目录来定位。初次运行Git 前的配置用户信息 第一个要配置的是你个人的用户名称和电子邮件地址。这两条配置很重要，每次Git 提 交时都会引用这两条信息，说明是谁提交了更新，所以会随更新内容一起被永久纳入历史记 录： $ git config -global user.name “John Doe“ $ git config -global user.email 如果用了-global 选项，那么更改的配置文件就是位于你用户主目录下的那个，以后你 所有的项目

15、都会默认使用这里配置的用户信息。如果要在某个特定的项目中使用其他名字或 者电邮，只要去掉-global 选项重新配置即可，新的设定保存在当前项目的.git/config 文件里。初次运行Git 前的配置查看配置信息 要检查已有的配置信息，可以使用git config -list 命令： $ git config -list user.name=yaolun user.email= color.status=auto color.branch=auto color.interactive=auto color.diff=auto .有时候会看到重复的变量名，那就说明它们来自不同的配置文件（比如/etc/gitconfig 和/.gitconfig），不过最终Git 实际采用的是最后一个。 也可以直接查阅某个环境变量的设定，只要把特定的名字跟在后面即可，像这样： $ git config user.name yaolunGit基础-取得项目的Git仓库要对现有的某个项目开始用Git 管理，只需到此项目所在的目录，执行： $ git init 初始化后，在当前目录下会出现一个名为.git 的目录，所有G