标签分类
当前位置:首页 > 程序设计电子书 > Git电子书网盘下载
Git学习指南 Git学习指南
langyifan

langyifan 提供上传

资源
29
粉丝
19
喜欢
203
评论
12

    Git学习指南 PDF 扫描清晰版

    Git电子书
    • 发布时间:

    给大家带来的一篇关于Git相关的电子书资源,介绍了关于Git、学习指南方面的内容,本书是由人民邮电出版社出版,格式为PDF,资源大小165 MB,René Prei?el 普莱贝尔 Bj编写,目前豆瓣、亚马逊、当当、京东等电子书综合评分为:7.6,更多相关的学习资源可以参阅 程序设计电子书、等栏目。

  • Git学习指南 PDF 下载
  • 下载地址:https://pan.baidu.com/s/1et_68hokQ6rpLI2cmCIT-w
  • 分享码:dr83
  • Git学习指南 PDF

    Git 是现如今时髦版本自动控制系统。这书并不是侧重基础理论介绍,都不考虑周全,只是一本学习培训Git 的好用手册。这书最先介绍了Git 的基本知识,随后关心于敏捷开发,并得出工作流展现了处理实际难题需要的指令和选择项。 这书包含以下几点: ● 入门教程:重中之重展现每一条关键Git 指令的使用方法。 ● 技术性介绍:介绍怎么使用Git 解决一个精英团队开发设计中的各类事务管理,用很多的案例演试这些关键Git 指令的应用方法,而且表述在其中的基本要素,如递交、版本库、分支、合拼、重订等,协助读者掌握Git 的实际工作中方法。 ● 工作流:工作流就是指在项目中应用Git 的好用情景,比如建立一个项目的发行版等。针对每一工作流,这书从下列几类来叙述其总体目标情景。 处理的是啥难题; 必须提升哪些先决条件; 解决困难的人及其处理的時间。 ● “逐层”命令:它是一组常用命令编码序列。比如,挪动某一分支就归属于一条明确的“逐层”命令。 这书合适于从业开发软件工作中,愿意把握Git 专用工具的读者阅读文章参照。Git是一款完全免费、开源系统的分布式系统版本自动控制系统,都是现如今时髦的版本自动控制系统之一,在诸多的项目开发设计中广泛应用,获得程序猿和技术工程师的热烈欢迎和钟爱。 这书是一本朝向技术专业开发人员的书籍。本书內容分成26章,从基本定义说起,相继向读者介绍了相关Git的各种各样实际操作和应用方法,不但将递交、版本库、分支、合拼等指令解读及时,还介绍了工作流、根据分支的开发设计、二分法排错、发行版交货、项目的分拆与合拼、项目的转移等內容。 这书合适从业项目开发设计的专业人员阅读文章,愿意学习培训Git的读者还可以采用。

    目录

    • 第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

    上一篇:程序化广告实战  下一篇:Ceph源码分析

    展开 +

    收起 -

    码小辫二维码
     

    Git相关电子书
    学习笔记
    网友NO.382678

    详解Eclipse提交项目到GitHub以及解决代码冲突

    前言:来这家公司上班后,开始使用Git作为项目版本控制系统,由于以前用的是SVN,所以对Git也就简单学习了一下。但是,实践出真知,当开始使用Git后,发现遇到了不少问题,也遇到过血的教训,于是决定记录一下,方便以后查看。 一、Eclipse安装Git插件 如果是比较新的Eclipse版本,默认就已经安装了Git插件。 菜单栏 -- Help -- About Eclipse ,如下图: 如果有这个图标,表示Eclipse已经安装了Git插件,如果没有这个图标,就到Eclipse插件市场下载Git插件,具体步骤自行百度谷歌。 二、Eclipse提交代码到GitHub 1、登录GitHub,创建代码仓库 登录 github ,然后在右上角 + 号下拉列表里找到 New repository ,创建一个新的仓库。在 Repository name 填入 testgit ,其他保持默认设置,点击 Create repository 按钮,就成功地创建了一个空的Git仓库。 创建完成后如下图: 将最上方的仓库地址(也就是这个: https://github.com/你的GitHub账号名称/Git仓库名称.git )复制下来,后面要用到。 2、在Eclipse中创建要发布到GitHub的项目 我这里是创建了一个最简单的Spring Boot项目,结构如下: 3、与GitHub建立连接,发布项目到GitHub 3.1 share project及创建本地Git仓库 选中要发布的项目 -- 右击 -- Team -- Share Project... , 勾选 Use or create repository in parent folder ofproject, 点击红色箭头处……

    网友NO.375756

    vue项目实现github在线预览功能

    最近在使用 vue-cli 脚手架工具构建自己的第一个 vue 项目,有点小激动,想把它上传到 github 并展示一下预览效果,结果踩了好多坑,折腾了大半天才弄好。 这里假设你也是和我一样使用了 vue-cli 搭建了自己的项目,并且项目也已经上传到了 github 问题1 当我们在命令行执行 npm run build 后,项目的目录下会生成一个 dist 文件夹,它里面又包含一个 static 文件夹和一个 index.html 文件,这是 webpack 最终打包好的文件 我们先尝试在浏览器打开 index.html 咦,为什么页面显示是空白的?打开控制台,细心的朋友可能会发现, script 标签的引入路径好像不对啊,因为 static 文件夹和 index.html 是在同一个目录下的,这里却是从根目录引入 static 下的文件,正确的路径应该是 ./ 开头的相对路径: src='./static/...' 或者 src='static/...' 是哪里出了问题?其实这跟配置资源的路径有关,打开项目根目录 config 文件夹下的 index.js ,定位到 build 下的 assetsPublicPath (dev下也有一个assetsPublicPath,别搞错了,我就是在这里踩了第一个坑),把 assetsPublicPath: '/' 修改为 assetsPublicPath: './' 这下可找出原因,因为这里把静态资源路径设置为在根目录下,所以 script 标签的引入路径就找不到 static 文件夹下的文件了 重新执行 npm run build ,再打开 index.html 文件 OK!在浏览器可……

    网友NO.763299

    pycharm配置git(图文教程)

    下载git客户端 FileàDefault Settingà Version Controlà Git Path to Git executable 填写git客户端的git.exe路径,点击OK,如图下 Git Repository URL的地址填写 其形式如:http://gitlab.AAAA.com/redredava/semantic.git,以 .git结束的链接; Parent Directory路径是本地保存路径,点击Clone 比较不同修改的变化,如下图所示: 展示结果: 双击任意一个,点击第一个查看变化 展示结果如上,不同部分会通过不同颜色展示出来 新加分支,点击之后,会将当前分支全部copy到新建的分支下面,可以避免反复创建文件夹、文件等问题 以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持码农之家。 ……

    网友NO.614434

    使用GitHub和Python实现持续部署的方法

    借助 GitHub 的网络钩子webhook,开发者可以创建很多有用的服务。从触发一个 Jenkins 实例上的 CI(持续集成) 任务到配置云中的机器,几乎有着无限的可能性。这篇教程将展示如何使用 Python 和 Flask 框架来搭建一个简单的持续部署(CD)服务。 在这个例子中的持续部署服务是一个简单的 Flask 应用,其带有接受 GitHub 的网络钩子webhook请求的 REST 端点endpoint。在验证每个请求都来自正确的 GitHub 仓库后,服务器将拉取pull更改到仓库的本地副本。这样每次一个新的提交commit推送到远程 GitHub 仓库,本地仓库就会自动更新。 Flask web 服务 用 Flask 搭建一个小的 web 服务非常简单。这里可以先看看项目的结构。 ├── app│ ├── __init__.py│ └── webhooks.py├── requirements.txt└── wsgi.py 首先,创建应用。应用代码在 app 目录下。 两个文件(__init__.py 和 webhooks.py)构成了 Flask 应用。前者包含有创建 Flask 应用并为其添加配置的代码。后者有端点endpoint逻辑。这是该应用接收 GitHub 请求数据的地方。 这里是 app/__init__.py 的内容: import osfrom flask import Flaskfrom .webhooks import webhookdef create_app(): """ Create, configure and return the Flask application """ app = Flask(__name__) app.config['GITHUB_SECRET'] = os.environ.get('GITHUB_SECRET') app.config['REPO_PATH'] = os.environ.get('REPO_PATH') ap……

    Copyright 2018-2019 xz577.com 码农之家

    版权责任说明