Git
趙常春
这个作者很懒,什么都没留下…
展开
-
9.6 Git 内部原理 - 传输协议
传输协议Git 可以以两种主要的方式跨越两个仓库传输数据:基于HTTP协议之上,和 file://, ssh://, 和git:// 等智能传输协议。这一节带你快速浏览这两种主要的协议操作过程。哑协议Git 基于HTTP之上传输通常被称为哑协议,这是因为它在服务端不需要有针对 Git 特有的代码。这个获取过程仅仅是一系列GET请求,客户端可以假定服务端的Git仓库中转载 2014-09-21 00:55:59 · 739 阅读 · 0 评论 -
5.1 分布式 Git - 分布式工作流程
分布式工作流程同传统的集中式版本控制系统(CVCS)不同,开发者之间的协作方式因着 Git 的分布式特性而变得更为灵活多样。在集中式系统上,每个开发者就像是连接在集线器上的节点,彼此的工作方式大体相像。而在 Git 网络中,每个开发者同时扮演着节点和集线器的角色,这就是说,每一个开发者都可以将自己的代码贡献到另外一个开发者的仓库中,或者建立自己的公共仓库,让其他开发者基于自己的工作开始转载 2014-09-20 23:28:44 · 475 阅读 · 0 评论 -
4.10 服务器上的 Git - Git 托管服务
Git 托管服务如果不想经历自己架设 Git 服务器的麻烦,网络上有几个专业的仓库托管服务可供选择。这样做有几大优点:托管账户的建立通常比较省时,方便项目的启动,而且不涉及服务器的维护和监控。即使内部创建并运行着自己的服务器,同时为开源项目提供一个公共托管站点还是有好处的 — 让开源社区更方便地找到该项目,并给予帮助。目前,可供选择的托管服务数量繁多,各有利弊。在 Git 官方转载 2014-09-20 23:26:44 · 382 阅读 · 0 评论 -
4.9 服务器上的 Git - Git 守护进程
Git 守护进程对于提供公共的,非授权的只读访问,我们可以抛弃 HTTP 协议,改用 Git 自己的协议,这主要是出于性能和速度的考虑。Git 协议远比 HTTP 协议高效,因而访问速度也快,所以它能节省很多用户的时间。重申一下,这一点只适用于非授权的只读访问。如果建在防火墙之外的服务器上,那么它所提供的服务应该只是那些公开的只读项目。如果是在防火墙之内的服务器上,可用于支撑大转载 2014-09-20 23:22:45 · 396 阅读 · 0 评论 -
4.7 服务器上的 Git - Gitosis
Gitosis把所有用户的公钥保存在 authorized_keys 文件的做法,只能凑和一阵子,当用户数量达到几百人的规模时,管理起来就会十分痛苦。每次改删用户都必须登录服务器不去说,这种做法还缺少必要的权限管理 — 每个人都对所有项目拥有完整的读写权限。幸好我们还可以选择应用广泛的 Gitosis 项目。简单地说,Gitosis 就是一套用来管理 authorized_转载 2014-09-20 23:20:55 · 432 阅读 · 0 评论 -
4.6 服务器上的 Git - GitWeb
GitWeb现在我们的项目已经有了可读可写和只读的连接方式,不过如果能有一个简单的 web 界面访问就更好了。Git 自带一个叫做 GitWeb 的 CGI 脚本,运行效果可以到 http://git.kernel.org 这样的站点体验下(见图 4-1)。Figure 4-1. 基于网页的 GitWeb 用户界面如果想看看自己项目的效果,不转载 2014-09-20 23:18:06 · 433 阅读 · 0 评论 -
4.5 服务器上的 Git - 公共访问
公共访问匿名的读取权限该怎么实现呢?也许除了内部私有的项目之外,你还需要托管一些开源项目。或者因为要用一些自动化的服务器来进行编译,或者有一些经常变化的服务器群组,而又不想整天生成新的 SSH 密钥 — 总之,你需要简单的匿名读取权限。或许对小型的配置来说最简单的办法就是运行一个静态 web 服务,把它的根目录设定为 Git 仓库所在的位置,然后开启本章第一节提到的 post-转载 2014-09-20 23:14:08 · 362 阅读 · 0 评论 -
4.4 服务器上的 Git - 架设服务器
架设服务器现在我们过一边服务器端架设 SSH 访问的流程。本例将使用 authorized_keys 方法来给用户授权。我们还将假定使用类似 Ubuntu 这样的标准 Linux 发行版。首先,创建一个名为 'git' 的用户,并为其创建一个.ssh 目录。$ sudo adduser git$ su git$ cd$ mkdir .ssh接下来,把开发者的 S转载 2014-09-20 23:13:42 · 408 阅读 · 0 评论 -
4.3 服务器上的 Git - 生成 SSH 公钥
生成 SSH 公钥大多数 Git 服务器都会选择使用 SSH 公钥来进行授权。系统中的每个用户都必须提供一个公钥用于授权,没有的话就要生成一个。生成公钥的过程在所有操作系统上都差不多。 首先先确认一下是否已经有一个公钥了。SSH 公钥默认储存在账户的主目录下的 ~/.ssh 目录。进去看看:$ cd ~/.ssh$ lsauthorized_keys2 id_dsa转载 2014-09-20 23:08:06 · 360 阅读 · 0 评论 -
4.2 服务器上的 Git - 在服务器上部署 Git
在服务器上部署 Git开始架设 Git 服务器前,需要先把现有仓库导出为裸仓库 — 即一个不包含当前工作目录的仓库。做法直截了当,克隆时用 --bare 选项即可。裸仓库的目录名一般以 .git 结尾,像这样:$ git clone --bare my_project my_project.gitCloning into bare repository 'my_project.g转载 2014-09-20 22:58:51 · 502 阅读 · 0 评论 -
4.1 服务器上的 Git - 协议
协议Git 可以使用四种主要的协议来传输数据:本地传输,SSH 协议,Git 协议和 HTTP 协议。下面分别介绍一下哪些情形应该使用(或避免使用)这些协议。值得注意的是,除了 HTTP 协议外,其他所有协议都要求在服务器端安装并运行 Git。本地协议最基本的就是本地协议(Local protocol),所谓的远程仓库在该协议中的表示,就是硬盘上的另一个目录。这转载 2014-09-20 22:52:02 · 358 阅读 · 0 评论 -
3.5 Git 分支 - 远程分支
远程分支远程分支(remote branch)是对远程仓库中的分支的索引。它们是一些无法移动的本地分支;只有在 Git 进行网络交互时才会更新。远程分支就像是书签,提醒着你上次连接远程仓库时上面各分支的位置。我们用 (远程仓库名)/(分支名) 这样的形式表示远程分支。比如我们想看看上次同 origin 仓库通讯时master 分支的样子,就应该查看 origin/master转载 2014-09-20 22:48:56 · 408 阅读 · 0 评论 -
5.2 分布式 Git - 为项目作贡献
为项目作贡献接下来,我们来学习一下作为项目贡献者,会有哪些常见的工作模式。不过要说清楚整个协作过程真的很难,Git 如此灵活,人们的协作方式便可以各式各样,没有固定不变的范式可循,而每个项目的具体情况又多少会有些不同,比如说参与者的规模,所选择的工作流程,每个人的提交权限,以及 Git 以外贡献等等,都会影响到具体操作的细节。首当其冲的是参与者规模。项目中有多少开发者是转载 2014-09-20 23:40:22 · 470 阅读 · 0 评论 -
5.3 分布式 Git - 项目的管理
项目的管理既然是相互协作,在贡献代码的同时,也免不了要维护管理自己的项目。像是怎么处理别人用 format-patch 生成的补丁,或是集成远端仓库上某个分支上的变化等等。但无论是管理代码仓库,还是帮忙审核收到的补丁,都需要同贡献者约定某种长期可持续的工作方式。使用特性分支进行工作如果想要集成新的代码进来,最好局限在特性分支上做。临时的特性分支可以让你随意尝试,进退自如转载 2014-09-20 23:52:02 · 458 阅读 · 0 评论 -
9.1 Git 内部原理 - 底层命令 (Plumbing) 和高层命令 (Porcelain)
底层命令 (Plumbing) 和高层命令 (Porcelain)本书讲解了使用 checkout, branch, remote 等共约 30 个 Git 命令。然而由于 Git 一开始被设计成供 VCS 使用的工具集而不是一整套用户友好的 VCS,它还包含了许多底层命令,这些命令用于以 UNIX 风格使用或由脚本调用。这些命令一般被称为 "plumbing" 命令(底层命令),转载 2014-09-21 00:39:00 · 510 阅读 · 0 评论 -
8.2 Git 与其他系统 - 迁移到 Git
迁移到 Git如果在其他版本控制系统中保存了某项目的代码而后决定转而使用 Git,那么该项目必须经历某种形式的迁移。本节将介绍 Git 中包含的一些针对常见系统的导入脚本,并将展示编写自定义的导入脚本的方法。导入你将学习到如何从专业重量级的版本控制系统中导入数据—— Subversion 和 Perforce —— 因为据我所知这二者的用户是(向 Git)转换的主要群体转载 2014-09-21 00:33:22 · 566 阅读 · 0 评论 -
7.4 自定义 Git - Git 强制策略实例
Git 强制策略实例在本节中,我们应用前面学到的知识建立这样一个Git 工作流程:检查提交信息的格式,只接受纯fast-forward内容的推送,并且指定用户只能修改项目中的特定子目录。我们将写一个客户端脚本来提示开发人员他们推送的内容是否会被拒绝,以及一个服务端脚本来实际执行这些策略。这些脚本使用 Ruby 写成,一半由于它是作者倾向的脚本语言,另外作者觉得它是最接近伪代码的转载 2014-09-21 00:28:59 · 630 阅读 · 0 评论 -
6.3 Git 工具 - 交互式暂存
交互式暂存Git提供了很多脚本来辅助某些命令行任务。这里,你将看到一些交互式命令,它们帮助你方便地构建只包含特定组合和部分文件的提交。在你修改了一大批文件然后决定将这些变更分布在几个各有侧重的提交而不是单个又大又乱的提交时,这些工具非常有用。用这种方法,你可以确保你的提交在逻辑上划分为相应的变更集,以便于供和你一起工作的开发者审阅。如果你运行git add时加上-i或者--inte转载 2014-09-21 00:00:30 · 476 阅读 · 0 评论 -
6.2 Git 工具 - 储藏(Stashing)
储藏(Stashing)经常有这样的事情发生,当你正在进行项目中某一部分的工作,里面的东西处于一个比较杂乱的状态,而你想转到其他分支上进行一些工作。问题是,你不想提交进行了一半的工作,否则以后你无法回到这个工作点。解决这个问题的办法就是git stash命令。“‘储藏”“可以获取你工作目录的中间状态——也就是你修改过的被追踪的文件和暂存的变更——并将它保存到一个未完结变更的转载 2014-09-21 00:00:28 · 587 阅读 · 0 评论 -
7.2 自定义 Git - Git属性
Git属性一些设置项也能被运用于特定的路径中,这样,Git 以对一个特定的子目录或子文件集运用那些设置项。这些设置项被称为 Git 属性,可以在你目录中的.gitattributes文件内进行设置(通常是你项目的根目录),也可以当你不想让这些属性文件和项目文件一同提交时,在.git/info/attributes进行设置。使用属性,你可以对个别文件或目录定义不同的合并策略,让转载 2014-09-21 00:24:56 · 668 阅读 · 0 评论 -
7.1 自定义 Git - 配置 Git
配置 Git如第一章所言,用git config配置 Git,要做的第一件事就是设置名字和邮箱地址:$ git config --global user.name "John Doe"$ git config --global user.email johndoe@example.com从现在开始,你会了解到一些类似以上但更为有趣的设置选项来自定义 Git。转载 2014-09-21 00:21:41 · 443 阅读 · 0 评论 -
6.7 Git 工具 - 子树合并
子树合并现在你已经看到了子模块系统的麻烦之处,让我们来看一下解决相同问题的另一途径。当 Git 归并时,它会检查需要归并的内容然后选择一个合适的归并策略。如果你归并的分支是两个,Git使用一个递归策略。如果你归并的分支超过两个,Git采用章鱼策略。这些策略是自动选择的,因为递归策略可以处理复杂的三路归并情况——比如多于一个共同祖先的——但是它只能处理两个分支的归并。章鱼归并可以处理多个转载 2014-09-21 00:14:51 · 1451 阅读 · 0 评论 -
6.6 Git 工具 - 子模块
子模块经常有这样的事情,当你在一个项目上工作时,你需要在其中使用另外一个项目。也许它是一个第三方开发的库或者是你独立开发和并在多个父项目中使用的。这个场景下一个常见的问题产生了:你想将两个项目单独处理但是又需要在其中一个中使用另外一个。这里有一个例子。假设你在开发一个网站,为之创建Atom源。你不想编写一个自己的Atom生成代码,而是决定使用一个库。你可能不得不像CPAN in转载 2014-09-21 00:10:03 · 449 阅读 · 0 评论 -
6.4 Git 工具 - 重写历史
重写历史很多时候,在 Git 上工作的时候,你也许会由于某种原因想要修订你的提交历史。Git 的一个卓越之处就是它允许你在最后可能的时刻再作决定。你可以在你即将提交暂存区时决定什么文件归入哪一次提交,你可以使用 stash 命令来决定你暂时搁置的工作,你可以重写已经发生的提交以使它们看起来是另外一种样子。这个包括改变提交的次序、改变说明或者修改提交中包含的文件,将提交归并、拆分或者完全转载 2014-09-21 00:02:16 · 440 阅读 · 0 评论 -
6.5 Git 工具 - 使用 Git 调试
使用 Git 调试Git 同样提供了一些工具来帮助你调试项目中遇到的问题。由于 Git 被设计为可应用于几乎任何类型的项目,这些工具是通用型,但是在遇到问题时可以经常帮助你查找缺陷所在。文件标注如果你在追踪代码中的缺陷想知道这是什么时候为什么被引进来的,文件标注会是你的最佳工具。它会显示文件中对每一行进行修改的最近一次提交。因此,如果你发现自己代码中的一个方法存在缺陷,转载 2014-09-21 00:07:30 · 378 阅读 · 0 评论 -
3.4 Git 分支 - 利用分支进行开发的工作流程
利用分支进行开发的工作流程现在我们已经学会了新建分支和合并分支,可以(或应该)用它来做点什么呢?在本节,我们会介绍一些利用分支进行开发的工作流程。而正是由于分支管理的便捷,才衍生出了这类典型的工作模式,你可以根据项目的实际情况选择一种用用看。长期分支由于 Git 使用简单的三方合并,所以就算在较长一段时间内,反复多次把某个分支合并到另一分支,也不是什么难事。也就是说,你转载 2014-09-20 22:46:14 · 382 阅读 · 0 评论 -
3.3 Git 分支 - 分支的管理
分支的管理到目前为止,你已经学会了如何创建、合并和删除分支。除此之外,我们还需要学习如何管理分支,在日后的常规工作中会经常用到下面介绍的管理命令。git branch 命令不仅仅能创建和删除分支,如果不加任何参数,它会给出当前所有分支的清单:$ git branch iss53* master testing注意看 master 分支前的 * 字符:转载 2014-09-20 22:43:39 · 265 阅读 · 0 评论 -
3.1 Git 分支 - 何谓分支
何谓分支为了理解 Git 分支的实现方式,我们需要回顾一下 Git 是如何储存数据的。或许你还记得第一章的内容,Git 保存的不是文件差异或者变化量,而只是一系列文件快照。在 Git 中提交时,会保存一个提交(commit)对象,该对象包含一个指向暂存内容快照的指针,包含本次提交的作者等相关附属信息,包含零个或多个指向该提交对象的父对象指针:首次提交是没有直接祖先的,普通提交有一个转载 2014-09-20 22:37:22 · 472 阅读 · 0 评论 -
2.7 Git 基础 - 技巧和窍门
技巧和窍门在结束本章之前,我还想和大家分享一些 Git 使用的技巧和窍门。很多使用 Git 的开发者可能根本就没用过这些技巧,我们也不是说在读过本书后非得用这些技巧不可,但至少应该有所了解吧。说实话,有了这些小窍门,我们的工作可以变得更简单,更轻松,更高效。自动补全如果你用的是 Bash shell,可以试试看 Git 提供的自动补全脚本。下载 Git 的源代码,进入con转载 2014-09-20 17:01:41 · 308 阅读 · 0 评论 -
2.6 Git 基础 - 打标签
打标签同大多数 VCS 一样,Git 也可以对某一时间点上的版本打上标签。人们在发布某个软件版本(比如 v1.0 等等)的时候,经常这么做。本节我们一起来学习如何列出所有可用的标签,如何新建标签,以及各种不同类型标签之间的差别。列显已有的标签列出现有标签的命令非常简单,直接运行 git tag 即可:$ git tagv0.1v1.3显示的标签按字母顺转载 2014-09-20 16:57:04 · 263 阅读 · 0 评论 -
2.4 Git 基础 - 撤消操作
撤消操作任何时候,你都有可能需要撤消刚才所做的某些操作。接下来,我们会介绍一些基本的撤消操作相关的命令。请注意,有些撤销操作是不可逆的,所以请务必谨慎小心,一旦失误,就有可能丢失部分工作成果。修改最后一次提交有时候我们提交完了才发现漏掉了几个文件没有加,或者提交信息写错了。想要撤消刚才的提交操作,可以使用 --amend 选项重新提交:$ git commit --转载 2014-09-20 16:53:17 · 375 阅读 · 0 评论 -
2.2 Git 基础 - 记录每次更新到仓库
记录每次更新到仓库现在我们手上已经有了一个真实项目的 Git 仓库,并从这个仓库中取出了所有文件的工作拷贝。接下来,对这些文件作些修改,在完成了一个阶段的目标之后,提交本次更新到仓库。请记住,工作目录下面的所有文件都不外乎这两种状态:已跟踪或未跟踪。已跟踪的文件是指本来就被纳入版本控制管理的文件,在上次快照中有它们的记录,工作一段时间后,它们的状态可能是未更新,已修改或者已放入暂存转载 2014-09-20 16:47:28 · 327 阅读 · 0 评论 -
1.5 起步 - 初次运行 Git 前的配置
1.5 起步 - 初次运行 Git 前的配置初次运行 Git 前的配置一般在新的系统上,我们都需要先配置下自己的 Git 工作环境。配置工作只需一次,以后升级时还会沿用现在的配置。当然,如果需要,你随时可以用相同的命令修改已有的配置。Git 提供了一个叫做 git config 的工具(译注:实际是 git-config 命令,只不过可以通过 git 加一个名字来呼转载 2014-09-20 16:35:13 · 497 阅读 · 0 评论 -
1.2 起步 - Git 简史
Git 简史同生活中的许多伟大事件一样,Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众广的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上(1991-2002年间)。到 2002 年,整个项目组开始启用分布式版本控制系统 BitKeeper 来管理和维护代码。到了 2005 年,开发 BitKeeper 的商业公司同转载 2014-09-20 16:29:17 · 381 阅读 · 0 评论 -
2.3 Git 基础 - 查看提交历史
查看提交历史在提交了若干更新之后,又或者克隆了某个项目,想回顾下提交历史,可以使用 git log 命令查看。接下来的例子会用我专门用于演示的 simplegit 项目,运行下面的命令获取该项目源代码:git clone git://github.com/schacon/simplegit-progit.git然后在此项目中运行 git log,应该会看到下面转载 2014-09-20 16:49:17 · 903 阅读 · 0 评论 -
2.1 Git 基础 - 取得项目的 Git 仓库
取得项目的 Git 仓库有两种取得 Git 项目仓库的方法。第一种是在现存的目录下,通过导入所有文件来创建新的 Git 仓库。第二种是从已有的 Git 仓库克隆出一个新的镜像仓库来。在工作目录中初始化新仓库要对现有的某个项目开始用 Git 管理,只需到此项目所在的目录,执行:$ git init初始化后,在当前目录下会出现一个名为 .git 的目录,所有转载 2014-09-20 16:42:22 · 501 阅读 · 0 评论 -
1.4 起步 - 安装 Git
安装 Git是时候动手尝试下 Git 了,不过得先安装好它。有许多种安装方式,主要分为两种,一种是通过编译源代码来安装;另一种是使用为特定平台预编译好的安装包。从源代码安装若是条件允许,从源代码安装有很多好处,至少可以安装最新的版本。Git 的每个版本都在不断尝试改进用户体验,所以能通过源代码自己编译安装最新版本就再好不过了。有些 Linux 版本自带的安装包更新起来并不及转载 2014-09-20 16:32:09 · 440 阅读 · 0 评论 -
1.6 起步 - 获取帮助
获取帮助想了解 Git 的各式工具该怎么用,可以阅读它们的使用帮助,方法有三:$ git help $ git --help$ man git-比如,要学习 config 命令可以怎么用,运行:$ git help config我们随时都可以浏览这些帮助信息而无需连网。 不过,要是你觉得还不够,可以到 Freenode IRC 服务器(irc.free转载 2014-09-20 16:36:29 · 376 阅读 · 0 评论 -
3.6 Git 分支 - 分支的衍合
分支的衍合把一个分支中的修改整合到另一个分支的办法有两种:merge 和 rebase(译注:rebase 的翻译暂定为“衍合”,大家知道就可以了。)。在本章我们会学习什么是衍合,如何使用衍合,为什么衍合操作如此富有魅力,以及我们应该在什么情况下使用衍合。基本的衍合操作请回顾之前有关合并的一节(见图 3-27),你会看到开发进程分叉到两个不同分支,又各自提交了更新。转载 2014-09-20 22:50:44 · 388 阅读 · 0 评论 -
4.8 服务器上的 Git - Gitolite
Gitolite本节作为Gitolite的一个快速指南,指导基本的安装和设置。不能完全替代随Gitolite自带的大量文档。而且可能会随时改变本节内容,因此你也许想看看最新的版本。Gitolite是在Git之上的一个授权层,依托sshd或者httpd来进行认证。(概括:认证是确定用户是谁,授权是决定该用户是否被允许做他想做的事情)。Gitolite允许你定义访问许可而不转载 2014-09-20 23:22:23 · 620 阅读 · 0 评论