Git学习指南 pdf下载pdf下载

Git学习指南百度网盘pdf下载

作者:
简介:本篇提供书籍《Git学习指南》百度网盘pdf下载
出版社:
出版时间:2016-12
pdf下载价格:0.00¥

免费下载


书籍下载


内容介绍

编辑推荐

Git 是当今流行版本控制系统。本书并不偏重理论介绍,也不面面俱到,而是一本学习Git 的实用指南。本书介绍了Git 的基础知识,然后关注于敏捷开发,并给出工作流展示了解决现实问题所需的命令和选项。
本书包括以下内容:
● 入门教程:重点展示每一条重要Git 命令的用法。
● 技术介绍:介绍如何使用Git 处理一个团队开发中的各项事务,用大量的实例演示那些主要Git 命令的使用方式,并且解释其中的基本概念,如提交、版本库、分支、合并、重订等,帮助读者了解Git 的具体工作方式。
● 工作流:工作流是指在项目中使用Git 的实用场景,例如创建一个项目的发行版等。对于每个工作流,本书从以下几项来描述其目标场景。
解决的是什么问题;
需要增加什么必要条件;
解决问题的人以及解决的时间。
● “分步”指令:这是一组常用命令序列。例如,移动某个分支属于一条既定的“分步”指令。
本书适合于从事软件开发工作,想要掌握Git 工具的读者阅读参考。

内容简介

  Git是一款免费、开源的分布式版本控制系统,也是当今流行的版本控制系统之一,在众多的项目开发中普遍使用,得到程序员和工程师的欢迎和喜爱。
  《Git学习指南》是一本面向专业开发者的图书。全书内容分为26章,从基础概念讲起,陆续向读者介绍了有关Git的各种操作和使用技巧,不仅将提交、版本库、分支、合并等命令讲解到位,还介绍了工作流、基于分支的开发、二分法排错、发行版交付、项目的拆分与合并、项目的迁移等内容。
  《Git学习指南》适合从事项目开发的专业人士阅读,想要学习Git的读者也可以选用。

作者简介

René Preiel,Bjrn Stachmann,德国杰出软件开发人员。
凌杰,毕业于浙江大学远程教育学院,曾担任多个论坛C++版主。技术图书译者。翻译有《Python算法教程》等。

内页插图

目录

目录

第 1章 基本概念 1
1.1 分布式版本控制,有何过人之处 1
1.2 版本库,分布式工作的基础所在 3
1.3 分支的创建与合并很简单 5
1.4 本章小结 6
第 2章 入门 8
2.1 准备Git环境 8
2.2 第 一个Git项目 8
2.2.1 创建版本库 9
2.2.2 首 次提交 9
2.2.3 检查状态 10
2.2.4 提交修改 11
2.2.5 显示历史 11
2.3 Git的协作功能 12
2.3.1 克隆版本库 12
2.3.2 从另一版本库中获取修改 12
2.3.3 从任意版本库中取回修改 14
2.3.4 创建共享版本库 14
2.3.5 用push命令上载修改 15
2.3.6 Pull命令:取回修改 16
2.4 本章小结 17
第3章 提交是什么 18
3.1 访问权限与时间戳 18
3.2 add命令与commit命令 19
3.3 再谈提交散列值 19
3.4 提交历史 20
3.5 一种略有不同的提交查看方法 21
3.6 同一项目的多部不同历史 21
3.6.1 部分输出:-n 22
3.6.2 格式化输出:--format、
--oneline 23
3.6.3 统计修改信息:--stat、
--shortstat 23
3.6.4 日志选项:--graph 23
3.7 本章小结 24
第4章 多次提交 25
4.1 status命令 25
4.2 存储在暂存区中的快照 28
4.3 怎样的修改不该被提交 28
4.4 用.gitignore忽略非版本控制文件 30
4.5 储藏 31
4.6 本章小结 31
第5章 版本库 33
5.1 一种简单而高效的存储系统 33
5.2 存储目录:Blob与Tree 34
5.3 相同数据只存储一次 35
5.4 压缩相似内容 35
5.5 当不同文件的散列值相同时,
情况会很糟糕吗 35
5.6 提交对象 36
5.7 提交历史中的对象重用 36
5.8 重命名、移动与复制 37
5.9 本章小结 39
第6章 分支 40
6.1 并行式开发 40
6.2 修复旧版本中的bug 41
6.3 分支 41
6.4 泳道 42
6.5 当前活跃分支 42
6.6 重置分支指针 44
6.7 删除分支 44
6.8 清理提交对象 45
6.9 本章小结 45
第7章 合并分支 46
7.1 合并过程中发生的事 47
7.2 冲突 48
7.3 编辑冲突 48
7.4 冲突标志 49
7.5 解决编辑冲突 50
7.6 内容冲突又是什么呢 51
7.7 快进合并 52
7.8 第 一父级提交历史 53
7.9 棘手的合并冲突 54
7.10 无论如何,终会有可行的方式 55
7.11 本章小结 56
第8章 通过变基净化历史 57
8.1 工作原理:复制提交 57
8.2 避免“钻石链” 58
8.3 什么情况下会遇到冲突呢 59
8.4 移植分支 60
8.5 执行变基后原提交的情况 61
8.6 为什么提交的原件与副本存在
于同一版本库中是有问题的 61
8.7 捡取 62
8.8 本章小结 62
第9章 版本库间的交换 64
9.1 克隆版本库 64
9.2 如何告知Git其他版本库的位置 65
9.3 给别处的版本库起个名字 65
9.4 获取数据 66
9.5 远程跟踪分支:监控其他分支 67
9.6 利用本地分支操作别处的版本库 68
9.7 Pull = Fetch + Merge 69
9.8 讨厌钻石链的人:请用--rebase
选项 69
9.9 push:pull的反面 69
9.10 命名分支 71
9.11 本章小结 72
第 10章 版本标签 73
10.1 创建标签 73
10.2 当前存在哪些标签 74
10.3 打印标签的散列值 74
10.4 将标签添加到日志输出中 74
10.5 在哪个版本里呢 75
10.6 如何修改标签呢 75
10.7 当我们需要一个浮动标签时 75
10.8 本章小结 75
第 11章 版本库之间的依赖 77
11.1 与子模块之间的依赖 77
11.2 与子树之间的依赖 82
11.3 本章小结 85
第 12章 技巧 86
12.1 不要慌,我们有一个引用日志 86
12.2 忽略临时性的本地修改 87
12.3 检查对文本文件的修改 88
12.4 别名—Git命令的快捷方式 88
12.5 为临时指向的提交创建分支 89
12.6 将提交移动到另一分支 89
第 13章 工作流简介 91
13.1 我们会在什么时候使用这些
工作流呢 91
13.1.1 项目开始阶段 91
13.1.2 项目开发阶段 92
13.1.3 项目交付阶段 92
13.1.4 项目重构阶段 92
13.2 工作流的结构 93
13.2.1 条目 93
13.2.2 概述 93
13.2.3 使用要求 93
13.2.4 工作流简述 93
13.2.5 执行过程及其实现 94
13.2.6 何不换一种做法 94
第 14章 项目设置 95
14.1 概述 96
14.2 使用要求 96
14.3 工作流简述:设置项目 97
14.4 执行过程及其实现 98
14.4.1 基于项目目录创建一个
新的版本库 98
14.4.2 以文件访问的方式
共享版本库 101
14.4.3 用Git daemon来共享
版本库 102
14.4.4 用HTTP协议来共享
版本库 103
14.4.5 用SSH协议来共享
版本库 106
14.5 何不换一种做法 107
何不放弃推送操作 107
14.6 纯拉取操作 108
第 15章 相同分支上的开发 109
15.1 概述 110
15.2 使用要求 111
15.3 工作流简述:相同分支上
的开发 111
15.4 执行过程及其实现 111
在master分支上操作 111
15.5 何不换一种做法 114
何不用变基来代替合并 114
第 16章 基于特性分支的开发 116
16.1 概述 116
16.2 使用要求 117
16.3 工作流简述:基于特性分支
的开发 118
16.4 执行过程及其实现 118
16.4.1 创建特性分支 118
16.4.2 在master分支上集成
某一特性 119
16.4.3 将master分支上所发生的修改传递给特性分支 124
16.5 何不换一种做法 125
16.5.1 何不直接在部分交付后
的合并版本上继续
后续工作 125
16.5.2 何不到发行版即将成型时
再集成特性分支 126
16.5.3 何不交换特性分支之间
的提交 126
第 17章 二分法排错 130
17.1 概述 130
17.2 使用要求 131
17.3 工作流简述:二分法排错 131
17.4 执行过程及其实现 131
17.4.1 用二分法人工排错 132
17.4.2 用二分法自动排错 134
17.5 何不换一种做法 138
何不用合并操作将测试脚本添加到
旧提交中去 138
第 18章 基于构建服务器的工作 139
18.1 概述 139
18.2 使用要求 140
18.3 工作流简述:基于构建服务器
的工作 140
18.4 执行过程及其实现 141
18.4.1 预备构建服务器 141
18.4.2 构建服务器上的Git 142
18.4.3 比对本地开发版本
与**后成功构建版本
之间的差异 145
18.4.4 基于构建历史的排错 146
18.5 何不换一种做法 149
18.5.1 何不使用标签 149
18.5.2 何不将构建历史放在中央
版本库中 149
第 19章 发行版交付 150
19.1 概述 150
19.2 使用要求 151
19.3 工作流简述:“发行版
交付” 152
19.4 执行过程及其实现 152
19.4.1 预备阶段:创建stable
分支 152
19.4.2 预备并创建发行版 154
19.4.3 创建补丁 157
19.5 何不换一种做法 159
19.5.1 为什么不能只用标签 159
19.5.2 何不干脆不用标签 159
19.5.3 为什么不能用快进式
合并 160
19.5.4 为什么不直接在stable分支
上实现补丁 160
第 20章 拆分大项目 161
20.1 概述 161
20.2 使用要求 163
20.3 工作流简述:“拆分大项目” 163
20.4 执行过程及其实现 163
20.4.1 拆分模块版本库 163
20.4.2 将拆分出的模块作为外部
版本库集成 165
20.5 何不换一种做法 166
20.5.1 何不采用一个全新
的版本库 166
20.5.2 为什么不采用--subdirectory
-filter选项 167
第 21章 合并小型项目 168
21.1 概述 168
21.2 使用要求 169
21.3 工作流简述:“合并小项目” 170
21.4 执行过程及其实现 170
合并版本库 170
21.5 何不换一种做法 172
为什么不直接合并,跳过创建
项目文件目录 172
第 22章 外包长历史记录 173
22.1 概述 173
22.2 使用要求 174
22.3 工作流简述:
“外包长历史记录” 175
22.4 执行过程及其实现 175
22.4.1 外包项目历史 175
22.4.2 链接到当前活动
版本库 178
22.5 何不换一种做法 179
为什么不获取档案版本库
(而是采用链接) 179
第 23章 与其他版本控制系统
并行使用 180
23.1 概述 180
23.2 使用要求 182
23.3 工作流简述:“与其他版本控制
系统并行使用” 182
23.4 执行过程及其实现 182
23.4.1 初始部署版本库 183
23.4.2 得到中央版本控制管理中
的更新修改 184
23.4.3 将修改提交传输到中央本
版控制系统 185
23.5 何不换一种做法 188
为什么不选择一个Git版本库 188
第 24章 迁移到Git 189
24.1 概述 189
24.2 使用要求 190
24.3 工作流简述:“迁移到Git” 190
24.4 执行过程及其实现 190
24.4.1 学习和练习使用Git 190
24.4.2 做出迁移的决定 191
24.4.3 找到分支 193
24.4.4 准备版本库 194
24.4.5 获取分支 195
24.4.6 以怀疑的态度使用接受
这个版本库 197
24.4.7 清理工作 199
24.5 何不换一种做法 199
24.5.1 为什么不接收整个项目
历史 199
24.5.2 是否可以没有遗产
分支 199
24.5.3 没有双版本控制工作区
可以吗 200
第 25章 还有一些其他任务 201
25.1 交互式变基操作——完善
历史记录 201
25.2 补丁处理 202
25.3 用E-mail发送补丁 202
25.4 打包操作——离线模式下的
推送操作 203
25.5 创建归档 203
25.6 Git的图形化工具 204
25.7 与Subversion的协作 205
25.8 命令别名 205
25.9 标注提交 206
25.10 用钩子扩展Git 206
25.11 将版本库托管到Github上 207
第 26章 Git的缺点 208
26.1 高复杂度 208
26.2 复杂的子模块 209
26.3 大型二进制文件的资源消耗 210
26.4 版本库只能作为一个整体
被处理 211
26.5 版本库只能作为整体被授权 211
26.6 能用于历史分析的图形化
工具偏弱 212

前言/序言

  欢迎阅读本书。
  在前言中,我们将会为你介绍Git究竟能做什么,以及为什么你会需要这本书。
  为什么要用Git
  Git的背后有着一个非常精彩的成功故事。2005年4月,Linus Torvalds因不满当时任何一个可用的开源版本控制系统,就亲自着手实现了Git。
  时至今日,如果我们在Google中搜索“git version control”这几个关键词,都会看到数以百万计的返回结果。Git已经俨然成为了新型开源项目的一个标准。许多大型的开源项目都已经或正在计划迁移到Git上来。
  下面,我们来看一下这么多人之所以会选择Git的原因。
  ●Git允许我们利用分支来开展工作:在一个由多个开发者并行协作的项目中,开发者各自会有很多不同的开发路线。Git的优势在于,它提供了一整套针对开发链的重新整合工具,以便我们对其进行合并、变基和捡取等操作。
  ●工作流上的灵活性:Git非常灵活。不但单一开发者可以用它,敏捷团队也可以找到使用它工作的合适方法,甚至一个由众多开发者在不同的工作地点参与的大型国际项目也可以用它开发出一个很好的工作流。
  ●适合奉献合作:大多数开源项目所依靠的都是开发者的无私奉献。因此,让这种无私奉献的方式尽可能地简单化是一件非常重要的事。而这在一个集中式的版本控制系统中通常是很难做到的,因为我们不可能让所有人都有权限去写版本库。但如果我们使用Git,那么每个人都先可以克隆一个独立的工作版本库,然后再对其进行后续的改动。
  ●高性能:Git在处理拥有许多文件且历史悠久的项目时速度也依然是非常快的。例如,使用Git将Linux内核源码的当前版本切换到6年前的旧版本时,在一台MacBook Air上所需的时间不到1分钟。考虑这两个版本之间有着超过200000次的提交和40000个更改文件,这已经足以让人印象深刻了。
  ●强大的抗故障和抗攻击能力:由于项目历史被分散存储在多个分布式版本库中,因此数据严重流失的可能性不大。再加上版本库中有着巧妙简单的数据结构,这确保了其中的数据即使在遥远的未来也仍然会被正确地解释。而且,它还使用了统一的加密校验,这使得攻击者难以对版本库进行篡改。
  ●离线开发与多点开发:分布式的体系结构可以使得离线开发或者边旅行边开发的方式变得非常容易。而且该结构在多点开发模式下,我们既不需要设置中央服务器,也不需要固定的网络连接。
  ●强大的开源社区:除官方提供的详细文档外,你还可以在该社区找到无数相关的手册、论坛、维基网站等,另外还有各种工具生态系统、托管平台、出版物、服务以及针对各个开发环境的插件,整个社区都正在茁壮成长。
  ●可扩展性:Git为用户提供了许多实用命令,其中包括了能使我们更便于直接访问其远程版本库的命令。这可以让Git变得非常灵活,这种灵活性将允许其各种独立应用提供比默认的Git版本更为强大的功能。
  一本面向专业开发者的书
  如果你在某一团队中从事开发工作,希望了解如何才能有效地使用Git,那么这本书就是一个正确的选择。本书既不是那种偏重于理论的大部头,也不是一本面面俱到的参考书。我们并不打算解释所有的Git命令(这里可有100多条命令呢)及其全部选项(有些命令甚至有50多个选项)。相反,我们打算在这本书中教你如何在典型的项目环境中使用Git,例如,如何建立起一个Git项目、如何创建一个Git发行版等。
  本书相关内容
  你将在本书中看到以下内容。
  ●入门教程:这部分会重点演示每一个重要Git命令的用法,篇幅不会超过十几页。