GitHub入门与实践_tarui2.0软件-优快云博客

本文链接：https://blog.youkuaiyun.com/andyyah/article/details/148825205

GitHub入门与实践

💻 GitHub与社会化编程
📘 GitHub简介
“GitHub 是一个全球最大的开源社区，为开发者提供了一个分享和协作的平台。”

GitHub的特点
不仅仅是仓库托管服务：GitHub 提供了版本控制、代码审核、任务管理等多种功能。
社会化编程：GitHub 促进了开发者之间的互动与协作，使得开发过程更加开放和透明。
🔑 社会化编程的意义
促进协作：开发者可以轻松共享和交流代码，互相学习、指正和改善。
提高效率：通过Pull Request等功能，代码审核和部署变得更加高效。
技术传播：开源项目使得开发者能够接触到更多的技术和文化。
📚 GitHub的主要功能
功能名称描述
Git 仓库用于存储和管理代码版本的地方。
组织（Organization）用于管理多个仓库和团队的结构。
问题追踪（Issue）用于跟踪和管理项目中的错误和任务。
维基（Wiki）用于项目文档的创建和维护。
Pull Request 用于代码审核和合并的请求，是GitHub的核心功能。
🛠️ Git的导入
版本管理的基础
集中型版本管理：所有版本控制信息存储在中央服务器上。
分散型版本管理：每个开发者都有完整的版本库，可以本地操作。
📖 使用GitHub的步骤
注册账户：需要创建一个免费的GitHub账户。
设置仓库：在GitHub上创建新的仓库并发布代码。
学习基本操作：掌握基本的Git命令和GitHub操作。
🔄 Pull Request的实践
Pull Request流程
创建分支：在自己的仓库中创建新分支进行开发。
提交更改：将修改提交到分支上。
发起Pull Request：请求将更改合并到主分支，并进行代码审查。
💡 GitHub Flow与Git Flow
GitHub Flow
适合快速开发：适合持续集成和频繁部署的场景。
Git Flow
适合复杂项目：适合需要多分支管理和版本发布的项目。
🛡️ 企业应用GitHub
引入GitHub的考虑
安全性：确保代码的安全和数据保护。
团队协作：如何在企业中促进团队之间的协作。
培训与支持：对员工进行GitHub使用的培训。
📑 附录
Gist
轻松共享代码：Gist 是一个GitHub的子功能，便于分享小段代码或笔记。
GUI客户端
辅助工具：对于不熟悉命令行的用户，可以使用GUI客户端来操作GitHub。
本指南旨在帮助读者深入理解GitHub及其在软件开发中的应用，促进高效的开发流程与社会化编程理念的实践。

📦 使用GitHub的前期准备
3.1 使用前的准备
创建账户
在使用GitHub之前，首先需要创建一个账户。
设置头像
设置你的头像可以帮助其他用户识别你。
设置SSH Key
SSH Key（安全外壳密钥）用于安全地连接到GitHub。
添加公开密钥
需要将生成的SSH密钥添加到你的GitHub账户中，以便进行安全连接。
使用社区功能
GitHub提供了多种社区功能，如讨论、评论等，鼓励用户互动。
3.2 实际动手使用
创建仓库
在GitHub上，你可以创建一个新的仓库（Repository）。
Repository name
仓库名称应简洁明了，便于识别。
Description
对仓库进行描述，说明其用途和内容。
Public、Private
选择仓库的可见性：公开（Public）或私有（Private）。
Initialize this repository with a README
可以选择用README文件初始化仓库，以提供基本信息。
Add .gitignore
使用**.gitignore**文件来指定哪些文件不应被版本控制。
Add a license
添加许可证以明确代码的使用和分发权限。
连接仓库
将本地仓库与GitHub上的远程仓库建立连接。
README.md
README.md文件用于解释项目的基本信息和使用方法。
GitHub Flavored Markdown
GitHub支持的Markdown语法使得文档的格式更加美观和易读。
公开代码
将你的代码公开以便其他用户查看和使用。
clone 已有仓库
使用git clone命令从GitHub克隆已有的仓库到本地。
编写代码
在本地仓库中编写代码，进行修改。
提交
使用git commit命令提交更改以保存历史记录。
进行push
使用git push命令将本地更改推送到远程仓库。
3.3 小结
在使用GitHub前，确保完成账户创建、SSH Key设置以及仓库的创建和初始化。掌握这些基本操作将为后续的版本控制打下良好的基础。
📊 控制面板
关于 UI
在本节中，我们将讨论控制面板的不同部分及其功能。

新闻推送 (News Feed)
用户可以查看最新的动态和更新。
拉取请求 (Pull Requests)
用于管理代码的合并请求，并进行讨论和评审。
问题 (Issues)
用户可以报告问题或提出功能请求。
收藏 (Stars)
用于标记用户感兴趣的仓库。
广播 (Broadcast)
用于发送通知和更新给用户。
参与的仓库 (Repositories you contribute to)
列出用户参与贡献的所有仓库。
你的仓库 (Your Repositories)
显示用户自己创建和管理的仓库。
🛠️ 个人信息
关于 UI
在个人信息部分，我们将看到用户的相关数据和活动。
用户信息
显示用户的基本信息和活动概况。
流行仓库 (Popular Repositories)
列出当前流行的仓库。
贡献的仓库 (Repositories contributed to)
列出用户贡献过的所有仓库。
公共贡献 (Public contributions)
显示用户的公共贡献记录。
贡献活动 (Contribution Activity)
用户在指定时间内的活动记录。
仓库 (Repositories)
列出用户管理的所有仓库。
公共活动 (Public Activity)
用户的公共活动记录。
📁 仓库
关于 UI
本节重点介绍仓库的结构和操作。
用户名（组织名）/仓库名
显示仓库的名称和所属组织。
关注/收藏/分叉 (Watch/Star/Fork)
用于管理用户对仓库的关注和交互。
代码 (Code)
显示仓库的源代码。
问题 (Issue)
管理与仓库相关的问题和讨论。
拉取请求 (Pull Requests)
管理代码合并请求。
维基 (Wiki)
提供文档和项目说明。
脉冲 (Pulse)
显示仓库的活动概况。
图表 (Graphs)
提供关于仓库活动的可视化统计。
网络 (Network)
显示仓库的分支和合并情况。
设置 (Settings)
仓库的配置和管理选项。
SSH 克隆 URL
提供通过 SSH 克隆仓库的链接。
在桌面端克隆 (Clone in Desktop)
提供在本地环境克隆仓库的选项。
下载 ZIP (Download ZIP)
提供下载仓库为压缩文件的选项。
📑 文件的相关操作
查看差别
查看分支间的差别
用户可以比较不同分支之间的代码差异。
查看与几天前的差别
用户可以查看与指定日期的代码差异。
查看与指定日期之间的差别
用户可以选择任意两个日期查看差异。
📝 Issue
简洁且表现力丰富的描述方法
语法高亮
支持代码的高亮显示。
添加图片
用户可以在问题中插入图片以增强描述。
添加标签以便整理
可以为问题添加标签，便于分类管理。
添加里程碑以便管理
可以设置里程碑来追踪问题的进度。
通过提交信息操作 Issue
用户可以通过提交信息直接与问题进行关联。
关闭 Issue
用户可以在解决问题后将其关闭。
将特定的 Issue 转换为拉取请求
可以将问题直接转换为拉取请求以便处理。
🔄 Pull Request
交流与审查
会话 (Conversation)
用户可以在此进行讨论和评论。
提交 (Commits)
显示与拉取请求相关的提交记录。
文件变更 (Files Changed)
显示拉取请求中涉及的文件更改。
📚 Wiki
页面与历史
页面
用户可以创建和编辑维基页面。
历史
查看维基页面的编辑历史记录。
📊 图表
贡献者与活动
贡献者
显示对仓库做出贡献的所有用户。
提交活动 (Commit Activity)
显示用户的提交记录。
代码频率 (Code Frequency)
展示代码提交的频率和趋势。
Punchcard
提供用户活动的时间分布图。
🌐 网络
设置
选项 (Options)
用户可以配置仓库的各种选项。
设置 (Settings)
管理仓库的各种设置。
功能 (Features)
启用或禁用某些功能。
GitHub Pages
设置 GitHub Pages 以托管静态网站。
危险区域 (Danger Zone)
进行一些高风险的操作，如删除仓库等。
合作者 (Collaborators)
管理与用户共享的合作者。
🛠️ GitHub 高级功能
部署密钥 (Deploy Keys)
部署密钥是用于安全地访问 GitHub 仓库的 SSH 密钥。这种密钥可以被赋予只读或只写访问权限，确保自动化部署过程的安全性。
通知 (Notifications)
在 GitHub 中，用户可以设置通知以获取对其仓库或项目相关的活动更新。通知可以通过多种方式接收，包括电子邮件和 GitHub 的通知中心。
其他功能
本节介绍了 GitHub 的其他功能，包括：

GitHub Pages：用于托管静态网页的服务。
GitHub Jobs：提供与 GitHub 相关的工作机会。
GitHub Enterprise：为企业提供私有 GitHub 服务。
GitHub API：允许开发人员通过编程方式与 GitHub 进行交互。
4. 小结
对 GitHub 的高级功能有了基本的了解，这些功能可以帮助开发者更有效地管理项目和团队协作。

🔄 Pull Request 概要

什么是 Pull Request
Pull Request （拉取请求）是 GitHub 上一种用于协作开发的机制。开发者可以通过 Pull Request 提交代码更改，其他团队成员可以进行审查和讨论。
Pull Request 的流程
Pull Request 的基本流程包括以下步骤：

创建特性分支：在本地创建一个新的分支来进行开发。
添加代码并提交：在特性分支中进行代码修改并提交更改。
发送 Pull Request：将修改的代码提交到原始仓库的 Pull Request。
⚙️ 发送 Pull Request 前的准备

查看要修正的源代码
在发送 Pull Request 之前，确保你已查看并理解需要修正的源代码。
Fork 和 Clone
Fork：在 GitHub 上创建一个仓库的副本。
Clone：将 Fork 的仓库下载到本地进行修改。
创建特性分支
在 Fork 的仓库中创建一个新的分支，以便在其上进行开发工作。
添加代码和提交修改
在特性分支上进行必要的代码修改，并使用 Git 提交这些修改。
创建远程分支
将本地的特性分支推送到远程仓库，以便其他人可以访问。

📩 发送 Pull Request
确保所有准备工作完成后，可以正式发送 Pull Request。通过 GitHub 界面提交请求并添加相关说明，以便审查者理解更改的内容。

🛠️ 让 Pull Request 更加有效的方法

在开发过程中发送 Pull Request 进行讨论
在开发的早期阶段就发送 Pull Request，可以让团队成员参与讨论，有助于提高代码质量。
明确标出“正在开发过程中”
在 Pull Request 中标记为“正在开发中”，提示审查者该请求尚未完成。
不进行 Fork 直接从分支发送 Pull Request
在团队内部可以直接从分支发送 Pull Request，以简化流程。

🗂️ 仓库的维护

仓库的 Fork 与 Clone
了解如何管理 Fork 的仓库以及如何从原始仓库克隆代码。
获取最新数据
保持仓库最新状态，定期从原始仓库获取最新更新。
合并与删除分支
在 Pull Request 被审核通过后，可以将其合并到主分支，并删除不再需要的特性分支。

🛡️ 接收 Pull Request

采纳 Pull Request 的方法
在接收 Pull Request 时，需要进行代码审查，确保代码质量和功能符合预期。
代码审查
在合并 Pull Request 前，仔细审查代码，以确保没有引入新的错误。
查看图片的差别
使用 GitHub 提供的工具比较不同版本之间的差异，以便更好地理解代码的更改。

以上就是本次讲座的内容，涵盖了 GitHub 的高级功能和 Pull Request 的处理流程。请确保对每个部分的内容有清晰的理解，以便在实际应用中能够有效利用这些知识。

🛠️ Jenkins 的安装与设置
Jenkins 的安装
安装 Jenkins 需要遵循特定的步骤，确保环境的兼容性和功能的完整性。
创建 Bot 账户
创建 Bot 账户是为了实现自动化操作和集成。
权限设置：
确保 Bot 账户拥有适当的权限，以便执行所需的任务。
对象为个人账户时
在设置时，如果对象是个人账户，需要注意账户的权限和设置。
对象为 Organization 账户时
如果对象是组织账户，设置的权限和配置可能有所不同，需根据组织的需求进行调整。
检查设置
在完成设置后，务必对所有配置进行检查，确保其正确性和有效性。
给 Jenkins 设置 SSH 密钥
设置 SSH 密钥以便 Jenkins 能够安全地连接到 GitHub 或其他版本控制系统。
初次使用 Jenkins 时
初次使用 Jenkins 的用户需要遵循一些基本配置步骤，以便顺利开始。
已经在使用 Jenkins 时
对于已经在使用 Jenkins 的用户，可能需要进行一些更新和维护。
GitHub Pull Request Builder 插件的安装
安装 GitHub Pull Request Builder 插件可以帮助自动化处理 Pull Request。
Git 插件的设置
Git 插件的配置是确保 Jenkins 能够正确访问和管理 Git 仓库的关键。
GitHub Pull Requests Builder 的设置
配置 GitHub Pull Requests Builder 以便 Jenkins 能够响应 Pull Request 的事件。
GitHub 服务器 API URL
配置 GitHub 服务器的 API URL，以便 Jenkins 能够与 GitHub 进行通信。
Access Token
创建并配置 Access Token，以便 Jenkins 能够安全访问 GitHub 的资源和操作。
📋 管理作业与构建
Job 的创建与设置
创建作业（Job）是 Jenkins 的核心功能之一，涉及配置构建任务的详细信息。
GitHub 项目
在 Jenkins 中配置 GitHub 项目，以实现源代码管理和自动构建。
源码管理
配置源码管理以确保 Jenkins 能够访问和管理源代码库。
构建触发器
构建触发器是自动化构建的重要组成部分，允许根据特定事件触发构建。
构建
构建是 Jenkins 的基本操作，涉及从源代码生成可执行文件或其他输出。
通知结果
Jenkins 可以配置为在构建完成后发送通知，以便团队成员了解构建状态。
测试执行中的状态
在构建过程中，Jenkins 提供多种状态反馈，帮助用户了解构建进度和结果。
状态描述
Failed 构建失败
All is well 构建成功
commit status 提交状态
通过评论进行控制
Jenkins 允许通过 GitHub 评论对构建进行控制，增加了灵活性和可操作性。
执行任务
执行任务是 Jenkins 的核心功能，涉及从创建到构建的整个流程。
添加至白名单
为了安全起见，某些操作可能需要将特定账户或 IP 地址添加至白名单。
重新执行任务
Jenkins 提供了重新执行任务的功能，以便在任务失败或需要重新构建时使用。
变更指定评论
可以通过变更特定评论来影响构建过程，增强交互性。
🔄 GitHub 的开发流程
团队使用 GitHub 时的注意事项
团队在使用 GitHub 时需注意项目管理和版本控制的最佳实践。
GitHub Flow
GitHub Flow 是一种以部署为中心的开发模式，强调快速迭代和持续集成。
Git Flow
Git Flow 是另一种以发布为中心的开发模式，适合需要严格版本控制的团队。
模拟体验 GitHub Flow
实际操作中通过模拟体验 GitHub Flow，可以帮助团队更好地理解和应用这一流程。
团队实践 GitHub Flow 时的建议
建议描述
减小 Pull Request 的体积使得代码审查更为高效
准备可供试运行的环境确保测试和部署的顺利进行
不要积攒 Pull Request 保持代码提交的频率和更新的及时性
Git Flow 的小结
Git Flow 提供了一种结构化的方法来管理版本和发布，适合复杂的项目需求。
🐙 GitHub 介绍
1.1 什么是GitHub
“GitHub 是为开发者提供Git 仓库的托管服务。这是一个让开发者与朋友、同事、同学及陌生人共享代码的完美场所。”

GitHub 的特点
托管服务：GitHub 提供在线存储和管理Git（分布式版本控制系统）仓库的功能。
社交功能：开发者可以轻松共享代码并进行协作。
GitHub 的历史
创始人：Chris Wanstrath 设想创建一个便于与朋友分享代码的服务，进而诞生了GitHub。
使用情况：截至2013年12月，GitHub 托管的仓库数已超过1000万个，成为全球开发者的首选平台。
1.2 使用GitHub 会带来哪些变化
协作形式的变化
传统协作工具：以往的多人协作工具如群件和客户关系管理工具（CRM）逐渐退出历史舞台。
GitHub 的优势：它为程序员提供了一个集成的协作平台，允许多位开发者在同一项目上工作。
Pull Request 功能
定义：Pull Request 是开发者对源代码进行更改后，向GitHub 中托管的Git 仓库请求合并的功能。
交流方式：开发者可以在Pull Request 中通过评论交流，如请求合并或讨论代码更改的细节。
示例
plaintext
Copy
开发者：修正了BUG，可以合并一下吗？
审查者：没有关于本次实现的测试代码，请添加一份。
Issue 功能
任务管理：通过 Issue 功能，开发者可以报告BUG并进行任务管理。
通知功能：使用“@ 用户名”格式可以提醒特定用户查看问题。
1.3 社会化编程
“GitHub这一服务，为开源世界带来了社会化编程的概念。”

社会化编程的影响
革命性改变：社会化编程改变了软件开发的方式，使得全球开发者能够共同协作。
开源与企业的结合：在企业中使用GitHub可以让新入职的程序员快速融入开源软件开发的环境。
1.4 GitHub Flavored Markdown
简单标记：用户在GitHub 上的评论和文档可以使用 GitHub Flavored Markdown（GFM）语法进行描述，便于理解。
丰富的表达：支持添加文字表情，增强用户交流。
功能描述
Pull Request 请求合并代码并进行讨论
Issue 任务管理和BUG报告功能
GFM 简化的标记语言，便于编写评论和文档
1.5 GitHub 的进一步应用
观察功能
Watch 功能：用户可以将感兴趣的仓库添加至Watch中，以便在News Feed 中获取该仓库的更新信息。
团队间协作：通过关注其他团队的仓库，可以了解其开发动态，促进跨团队合作。
结论
GitHub 的出现不仅为开发者提供了强大的托管服务，还通过其多样的功能改变了软件开发的方式，促进了全球开发者的协作与交流。

🐱‍👤 GitHub 的革命性影响与功能

GitHub 的概念
“GitHub 是社会化编程的代表，允许软件开发者在全球范围内公开源代码，实现了源代码的民主化。”

1.1 GitHub 的历史
旧 LOGO（图1.7）与新 LOGO（图1.8）的演变，标志着GitHub的成长与发展。
GitHub 的出现为软件开发者提供了真正的源代码控制权，打破了以前特权阶级的垄断。
1.2 社会化编程的重要性
在GitHub 出现之前，只有少数人能够修改源代码，这限制了软件的创新。
GitHub 提供了一个平台，使得所有开发者都能平等地参与源代码的修改与发布。
2. 为什么需要社会化编程
2.1 IT行业变迁
人才流动性增加：程序员的工作频繁变动，面试官需要评估候选人的实际能力。
比较项能查看代码的程序员无法查看代码的程序员
对语言或软件差异的理解 ✅ ❌
精通最新技术 ✅ ❌
“理解社会化编程与 GitHub 对程序员的职业生涯至关重要。”

2.2 开放的文化与学习
鼓励接触不同的技术与文化，以避免技术陈旧。
社会化编程使程序员能够从全球最新的技术中获得灵感。
3. GitHub 提供的主要功能
功能描述
Git 仓库免费建立公共仓库，私有仓库则需支付费用。
组织适合公司统一管理账户与权限，支持免费公开创建。
Issue 任务或问题追踪与管理功能，便于与功能更改对应。
Wiki 允许多人共同编辑文档，支持版本控制与历史记录。
Pull Request 提交更改请求，便于开发者之间的代码审查与讨论。
3.1 具体功能详解
Git 仓库：任何用户可建立任意个仓库，私有仓库需要支付最低月费。
Issue：通过Issue追踪变更与讨论，提升管理效率。
Pull Request：通过Pull Request功能，开发者可请求合并代码，支持代码审查。
4. GitHub 的人性化设计
GitHub 不仅关注项目本身，更关注开发者个人。
通过关注他人，用户可以看到公开的源代码及其活动。
4.1 关注与交流
用户可以关注感兴趣的开发者，获取其最新动态。
这种设计促进了开发者之间的交流与合作。
5. 小结
GitHub 的出现彻底改变了软件开发的生态，使得开发者可以自由地共享与学习源代码。
未来，社会化编程将成为程序员的常态，GitHub 的作用将愈加重要。
🛠️ 使用 GitHub 的前期准备
生成 SSH 密钥
在使用 GitHub 进行身份验证时，首先需要生成 SSH 密钥对，其中包括私有密钥（id_rsa）和公开密钥（id_rsa.pub）。

生成的密钥可以通过以下命令查看公开密钥内容：

bash
Copy
$ cat ~/.ssh/id_rsa.pub
公开密钥的格式应为：

text
Copy
ssh-rsa 公开密钥的内容 your_email@example.com
添加公开密钥到 GitHub
登录 GitHub，点击右上角的账户设定按钮（Account Settings）。
选择 SSH Keys 菜单，点击 Add SSH Key。
在 Title 中输入密钥名称，在 Key 部分粘贴 id_rsa.pub 文件里的内容。
添加成功后，会收到一封提示“公共密钥添加完成”的邮件。

认证测试
使用命令测试 SSH 连接是否成功：

bash
Copy
$ ssh -T git@github.com
成功连接后会出现：
text
Copy
Hi hirocastest! You’ve successfully authenticated, but GitHub does not provide shell access.
使用 GitHub 社区功能
关注用户
在用户信息页面的右上角点击 Follow 按钮，可以关注其他用户，查看他们的活动。
关注仓库
使用 Watch 功能获取仓库的最新开发信息。
创建仓库
点击右上角的 New repository 按钮。
在 Repository name 栏中输入仓库名称（如：Hello-World）。
在 Description 栏中添加仓库的说明（可选）。
选择 Public 或 Private，公共仓库对所有人可见，私有仓库仅限特定用户访问。
勾选 Initialize this repository with a README，自动创建 README 文件。
连接仓库
创建完成后，仓库的 URL 格式为：

text
Copy
https://github.com/用户名/Hello-World
README.md 文件
README.md 文件在初始化时自动生成，通常用于描述仓库内容、使用流程和许可协议。
GitHub Flavored Markdown
GitHub 上的交流（如 Issue、评论、Wiki）使用 GitHub Flavored Markdown（GFM）语法。

学习 Markdown 语法已成为程序员的标准技能之一。
克隆已有仓库
使用以下命令克隆仓库到本地：

bash
Copy
$ git clone git@github.com:hirocastest/Hello-World.git
编写代码并提交
创建文件
创建 hello_world.php 文件，内容如下：

php
Copy

<?php echo "Hello World!"; ?>

提交文件
将文件添加至版本控制：
bash
Copy
$ git add hello_world.php
提交更改：
bash
Copy
$ git commit -m “Add hello world script by php”
查看提交日志
使用以下命令查看提交记录：

bash
Copy
$ git log
公开代码
执行以下命令将更改推送至 GitHub：

bash
Copy
$ git push
代码将在 GitHub 上公开，用户可以通过仓库 URL 访问。
许可协议
即便在 GitHub 上公开了源代码，代码的权利持有人仍需选择合适的许可协议。

MIT 许可协议特点
被授权人权利：有权使用、复制、修改、合并、发行、散布、再授权和贩售软件。
被授权人义务：在软件和副本中包含版权声明和许可声明。
小结
本章讲解了在 GitHub 上创建仓库和公开代码的流程，为后续的 Git 操作奠定基础。

📚 Git教程

工作树与暂存区的差别
“由于我们尚未用git add命令向暂存区添加任何东西，所以程序只会显示工作树与最新提交状态之间的差别。”

新添加的行：用“+”号标出
被删除的行：用“-”号标出
查看差别
使用命令将README.md文件加入暂存区：

bash
Copy
$ git add README.md
查看工作树和最新提交的差别：

bash
Copy
$ git diff HEAD
输出示例：

text
Copy
diff --git a/README.md b/README.md
index e69de29…cb5dc9f 100644
— a/README.md
+++ b/README.md
@@ -0,0 +1 @@
+# Git教程
2. 提交操作
“不妨养成这样一个好习惯：在执行git commit命令之前先执行git diff HEAD命令，查看本次提交与上次提交之间有什么差别，等确认完毕后再进行提交。”

提交命令
执行提交命令：
bash
Copy
$ git commit -m “Add index”
查看提交日志：
bash
Copy
$ git log
3. 分支的操作
3.1 创建和切换分支
显示分支列表：

bash
Copy
$ git branch
创建并切换到新分支：

bash
Copy
$ git checkout -b feature-A
连续执行两条命令效果相同：

bash
Copy
$ git branch feature-A
$ git checkout feature-A
3.2 提交分支内容
在README.md中添加内容：

text
Copy

Git教程

feature-A
提交更改：

bash
Copy
$ git add README.md
$ git commit -m “Add feature-A”
3.3 切换分支
切换回master分支：
bash
Copy
$ git checkout master
4. 特性分支
“特性分支顾名思义，是集中实现单一特性（主题），除此之外不进行任何作业的分支。”

分支类型描述
特性分支实现单一特性，完成后与主干合并
主干分支通常为master，保持稳定，随时供人查看
4.1 合并分支
切换到master分支并合并feature-A：
bash
Copy
$ git checkout master
$ git merge --no-ff feature-A
5. 更改提交的操作
5.1 回溯历史版本
使用命令回溯到指定状态：
bash
Copy
$ git reset --hard fd0cbf0d4a25f747230694d95cac1be72d33441d
5.2 创建新的特性分支
创建fix-B分支并添加内容：
bash
Copy
$ git checkout -b fix-B
6. 解决合并冲突
合并fix-B分支：

bash
Copy
$ git merge --no-ff fix-B
处理冲突，编辑README.md文件，内容示例：

markdown
Copy

Git教程

feature-A
fix-B
提交解决后的结果：

bash
Copy
$ git add README.md
$ git commit -m “Fix conflict”
6.1 修改提交信息
修改上一条提交信息：

bash
Copy
$ git commit --amend
在编辑器中修改信息为：

text
Copy
Merge branch ‘fix-B’
通过以上操作，可以有效地管理Git中的工作状态、分支和提交，确保团队开发的高效性与代码的稳定性。

📚 Git 操作学习指南
📦 创建特性分支
“在合并特性分支之前，如果发现已提交的内容中有些许拼写错误等，不妨提交一个修改，然后将这个修改包含到前一个提交之中，压缩成一个历史记录。”

创建分支
使用命令创建特性分支：
bash
Copy
git checkout -b feature-C
切换到新建的 ‘feature-C’ 分支。

提交更改
在 README.md 文件中添加一行文字，并故意留下拼写错误，然后提交：
bash
Copy
git commit -am “Add feature-C”
📝 修正拼写错误
“错字漏字等失误称作 typo，所以我们将提交信息记为 ‘Fix typo’。”

修正过程
查看文件差异：
bash
Copy
git diff
修正拼写错误后提交：
bash
Copy
git commit -am “Fix typo”
🗂️ 更改历史记录
使用 git rebase
“将 ‘Fix typo’ 修正的内容与之前一次的提交合并，在历史记录中合并为一次完美的提交。”

使用以下命令开始 rebase：
bash
Copy
git rebase -i HEAD~2
在编辑器中，将需要合并的提交标记为 fixup：
text
Copy
pick 7a34294 Add feature-C
fixup 6fba227 Fix typo
完成合并
保存并关闭编辑器，成功合并后历史记录将更新。
🌐 推送至远程仓库
添加远程仓库
设置远程仓库：
bash
Copy
git remote add origin git@github.com:github-book/git-tutorial.git
推送命令
推送至 master 分支：
bash
Copy
git push -u origin master
🔄 从远程仓库获取内容
克隆远程仓库
克隆远程仓库到本地：
bash
Copy
git clone git@github.com:github-book/git-tutorial.git
获取远程分支
创建并切换到本地分支 feature-D：
bash
Copy
git checkout -b feature-D origin/feature-D
⚙️ 向分支提交更改
提交更改：
bash
Copy
git commit -am “Add feature-D”
推送更改
推送 feature-D 分支：
bash
Copy
git push
🔄 更新本地分支
从远程仓库更新本地 feature-D 分支：
bash
Copy
git pull origin feature-D
📖 参考资料
Pro Git: https://git-scm.com/book/zh/v1
LearnGitBranching: http://pcottle.github.io/learnGitBranching/
tryGit: http://try.github.io/
📝 小结
通过以上命令和操作，掌握了 Git 的基本使用方法，能够应对日常开发中的大部分操作。

📚 GitHub 功能详解

通知系统
通知图标
该图标用于提示用户是否有新的通知。当图标为蓝色时表示有未读通知。用户在新建Issue、被评论、进行Pull Request等时都会收到通知。

邮件通知设置
按照默认设置，用户在GitHub收到的通知会同时发送到该用户的注册邮箱。邮箱接收通知的相关设置在账户设置(Account settings)中进行。

搜索窗口
在这里输入想找的用户或代码片段，就可以搜索到与之相关的信息。
探索功能
热门软件介绍
GitHub公司特别介绍的软件（附开发者制作的视频），按语言筛选本日/周/月的热门仓库/开发者。

技术灵感
作为程序员，可以在上面找到许多灵感，建议定期关注。

Gist 功能
Gist 简介
Gist功能主要用于管理及发布一些没必要保存在仓库中的代码，比如小的代码片段等。

功能特点
系统会自动管理更新历史，并且提供Fork功能。
便于为同事编写代码示例，代码示例可以嵌入博客中，且会自动添加语法高亮。
5. 博客
这是到GitHub公司官方博客的超链接，GitHub公司会在上面发布通知、新功能的通知、新入职员工的介绍、聚会的信息等。

帮助
GitHub相关的帮助，虽然只有英文版，但用的都是比较简单的英文，遇到不懂的地方可在这里查一下。
个人信息页面
头像与用户名
点击后会显示用户的个人信息页面。
创建新项目
创建新仓库或组织
创建新的Git仓库或Organization，向Organization添加成员、小组、仓库，为仓库添加Issue或合作者等操作的菜单都聚集在这里。
控制面板
UI 介绍
登录GitHub时最先显示的控制面板，包括以下几个部分：

项目描述
News Feed 显示当前已Follow的用户和已Watch的项目的活动信息。
Pull Requests 显示用户已进行过的Pull Request。
Issues 查看用户拥有权限的仓库或分配给自己的Issue。
Stars 显示用户添加了Star的仓库。
Broadcast 接收GitHub公司发来的通知或使用技巧的小贴士。
Repositories you contribute to 显示用户做过贡献的仓库。
Your Repositories 显示用户的仓库，按更新时间排序。
10. 个人信息页面
访问个人信息
访问以下URL可以查看个人信息：
KaTeX can only parse string typed expression
https://github.com/用户名(https://github.com/用户名)

用户信息
显示注册用户的基本信息，包括姓名、所属公司、邮箱地址、已加入的Organization等。

仓库
仓库URL格式
仓库的URL形式如下所示：
KaTeX can only parse string typed expression
https://github.com/用户名/仓库名(https://github.com/用户名/仓库名)

仓库页面UI
仓库页面左上角显示用户名和仓库名，功能包括Watch、Star、Fork等。

项目描述
Watch 关注该仓库，今后更新信息会显示在用户的公开活动中。
Star 代表该仓库的关注人数，越高越受欢迎。
Fork 表示该仓库被Fork的次数，越多参与开发的人越多。
12. 文件的相关操作
文件操作菜单
点击文件后会显示出文件的内容，同时右上角会显示用于该文件的操作菜单，包括Edit、Raw、Blame、History、Delete等。

行号高亮
点击文件中的行号可以高亮标记该行，方便讨论。

Issue 管理
Issue 简介
用于跟踪BUG及进行软件相关讨论，GitHub也为自身加入了BTS功能。

Issue 用途
可以用于发现软件的BUG、向作者询问、探讨以及列出今后准备实施的任务。

GFM 语法
GitHub的Issue及评论可以使用GFM（GitHub Flavored Markdown）语法进行描述，增强表现力。

添加标签与里程碑
Issue可以通过添加标签进行整理，也可以通过添加里程碑来管理任务。

任务列表语法
使用GFM的Tasklist语法可以创建复选列表，方便管理任务。

提交信息操作Issue
提交信息格式
通过特定格式描述提交信息，可以关联并自动处理Issue的状态，如Close Issue等。

🔄 Pull Request
什么是 Pull Request
“Pull Request 是用户修改代码后向对方仓库发送采纳请求的功能，也是 GitHub 的核心功能。”

在 GitHub 上，如果给 Issue 添加源代码，它就会变成 Pull Request。Issue 与 Pull Request 的编号相互通用，通过 GitHub 的 API 可以将特定的 Issue 转换为 Pull Request。

Pull Request 的功能
用户可以通过 Pull Request 请求对方仓库采纳自己的代码修改。
它帮助开发者轻松地加入开源开发的队伍。
状态查看
在 Pull Request 页面能够列表查看当前处于 Open 状态的 Pull Request。通过点击页面左部和上部的选项可以进行筛选和重新排列。

Pull Request 页面详解
点击特定的 Pull Request 进入详细页面：

页面上方显示着这次是从谁的哪个分支向谁的哪个分支发送了 Pull Request。
各个标签页的功能如下：
标签页功能说明
Conversation 查看与当前 Pull Request 相关的所有评论以及提交的历史记录。可以添加评论参与讨论。
Commits 按时间顺序列出与当前 Pull Request 相关的提交。每个提交右侧的哈希值可以链接到该提交的代码。
Files Changed 查看当前 Pull Request 更改的文件内容以及前后差别。可通过添加 ?w=1 来不显示空格的差别。
引用评论
在 Conversation 标签页中，用户可以通过选中评论后按 R 键来引用该评论，方便进行讨论。

获取文件差异
对于长期投身于软件开发的人，有时可能希望以 diff 格式文件和 patch 格式文件的形式来处理 Pull Request。获取格式文件的方法如下：

获取 diff 格式文件：在 Pull Request 的 URL 末尾添加 .diff。
获取 patch 格式文件：在 Pull Request 的 URL 末尾添加 .patch。
例如，假设 Pull Request 的 URL 为 https://github.com/用户名/仓库名/pull/28：

diff 格式：https://github.com/用户名/仓库名/pull/28.diff
patch 格式：https://github.com/用户名/仓库名/pull/28.patch
统计信息
在 Graphs 页中，可以通过四种图表查看该仓库的相关统计信息：

图表类型功能说明
Contributors 显示每个用户在相应日期中的提交数量、添加代码和删除代码的数量。
Commit Activity 显示一年内每周收到的提交数量，判断仓库是否有人在积极更新的重要指标。
Code Frequency 显示代码行数的增加量和删除量，直观把握仓库的代码变动情况。
Punchcard 直观掌握一周内每天何时收到的提交最多，了解开发者的工作时间规律。
设置与权限
在 Settings 页面中，用户可以对仓库进行各种设置，包括：

Options：修改仓库名称，设置默认显示的分支。
Collaborators：设置仓库的访问权限，添加用户赋予其读写权限。
Webhooks & Services：添加 Hook 与其他服务集成。
Deploy Keys：添加用于部署的公开密钥，允许以只读方式访问仓库。
通知功能
GitHub 提供了 Notifications 功能，用户可以及时查看 GitHub 所有活动的通知。

通知功能功能说明
未读通知显示所有未读的通知。
与我相关显示与当前用户相关的通知。
按仓库分类将通知按仓库分类查看。
通过以上功能，用户可以大幅提高合作开发的效率。

🛠️ Pull Request 的概念与流程
“Pull Request（拉取请求）是自己修改源代码后，请求对方仓库采纳该修改时采取的一种行为。”

Pull Request 的基本流程
当你在使用 GitHub 上的开源软件时，若发现了 BUG 并手动修复后，可以通过以下步骤发送 Pull Request：

发送 Pull Request：

通过 GitHub 发送 Pull Request 后，接收方的仓库会创建一个附带源代码的 Issue，记录详细内容。
Pull Request 也常被简称为 PR。
等待审核：

发送的 Pull Request 是否被采纳，由接收方仓库的管理者判断。
一般情况下，只要代码没有问题，对方都会采纳。如果存在问题，我们会收到评论。
成为贡献者：

一旦 Pull Request 被采纳，你将成为该项目的 Contributor（贡献者），所编写的代码将被全世界的用户使用。
发送 Pull Request 前的准备
整体概念
操作说明
Fork 在 GitHub 上点击 Fork 按钮创建自己的仓库
Clone 将仓库克隆到本地开发环境
创建特性分支在特性分支中进行代码修改
Fork 和 Clone
Fork：

点击 GitHub 仓库页面中的 Fork 按钮，创建名为“自己的账户名/first-pr”的新仓库。
Clone：

使用命令 git clone git@github.com:用户名/first-pr.git 将仓库克隆到本地。
创建特性分支
使用特性分支的原因：

当前 Git 的主流开发模式都会使用特性分支，以便于让 Pull Request 拥有更明确的特性，提升代码审查的效率。
创建特性分支的命令示例：
bash
Copy
git checkout -b work gh-pages
修改代码与提交
修改源代码：

打开 index.html 文件，添加感想内容。
查看修改：

使用 git diff 命令查看修改是否正确。
提交修改：

使用以下命令将修改提交至本地仓库：
bash
Copy
git add index.html
git commit -m “Add my impression”
创建远程分支：

将本地 work 分支推送至 GitHub：
bash
Copy
git push origin work
发送 Pull Request
登录 GitHub：

切换至 work 分支，查看分支间的差别。
创建 Pull Request：

点击 “Create Pull Request” 按钮，填写请求对方采纳的评论。
查看状态：

早期发送 Pull Request
在开发过程中，如果想发起讨论，可以尽早创建 Pull Request，获取反馈，避免大幅更改。
标记“正在开发中”
在标题前加上 “[WIP]” 字样，表示仍在开发过程中。
直接从分支发送 Pull Request
如果用户对仓库有编辑权限，可以直接创建分支，免去 Fork 的麻烦。
仓库的维护
设置原仓库名称：

使用 git remote add upstream 命令将原仓库设置为远程仓库。
获取最新数据：

使用 git fetch upstream 和 git merge upstream/master 命令保持本地仓库与最新源代码一致。
小结
本章学习了 Pull Request 的发送方法和相关的准备工作。
尝试使用 Pull Request 可以提高代码质量和开发效率，建议积极实践。
📸 图像比较工具
鼠标拖动分界线
“鼠标可以拖动分界线左右移动，帮助用户对比细节差异和细微的颜色差异。”

功能介绍
用户可以通过拖动分界线来查看两张图片之间的差异，方便进行细致的比较。
Onion Skin（洋葱皮）
“Onion Skin 能够将新旧两张图片重叠放置，分阶段从旧图片慢慢过渡至新图片，用户可以自由调节过渡比例。”

特点
允许用户逐步确认新旧图片的变化，增强了对比效果。
Difference（差异）功能
“Difference 功能让笔者都感到吃惊，它能够直接抽出两张图片不一样的部分进行比较。”

应用实例
例如，Difference 功能可以识别出单片眼镜这一差别之处，适用于“大家来找茬”的游戏。
在本地开发环境中反映Pull Request的内容
更新本地仓库
将Pull Request接收方的仓库克隆到本地：

bash
Copy
$ git clone git@github.com:ituring/first-pr.git
如果已经克隆过，需进行pull操作更新至最新状态。

获取发送方的远程仓库
设置Pull Request发送方的仓库为本地仓库的远程仓库：
bash
Copy
$ git remote add PR发送者 git@github.com:PR发送者/first-pr.git
$ git fetch PR发送者
创建用于检查的分支
创建一个用于模拟采纳Pull Request后状态的分支：
bash
Copy
$ git checkout -b pr1
合并操作
将“PR发送者/work”的修改内容与pr1分支进行合并：
bash
Copy
$ git merge PR发送者/work
删除分支
检查结束后，可以删除pr1分支：
bash
Copy
$ git branch -D pr1
采纳Pull Request流程
打开Pull Request页面
如果Pull Request的内容没有问题，点击“Merge pull request”按钮进行合并。
手动合并操作
切换至gh-pages分支：

bash
Copy
$ git checkout gh-pages
合并“PR发送者/work”分支的内容：

bash
Copy
$ git merge PR发送者/work
进行push操作：

bash
Copy
$ git push
Pull Request状态变更
处理完毕后，Pull Request会自动从Open状态变为Close状态。
小结
以上流程展示了如何安全地接收Pull Request。尽管示例中只是简单的Pull Request，实际开发场景中可能会涉及更复杂的情况。
代码管理技术提升
灵活运用分支的创建及合并技术，可以在确保安全性的前提下并行开发多个功能，适合团队合作。建议在GitHub上通过发送Pull Request进行实践。
🛠️ GitHub 与持续集成工具

配置 GitHub Enterprise
“通过命令 hub --add hub.host my.example.org 来配置 GitHub Enterprise 的主机名。”

设置步骤
将 my.example.org 替换为 GitHub Enterprise 的实际主机名。
在 ~/.gitconfig 文件中添加以下设置：
text
Copy
[hub]
host = my.example.org
功能说明
效果：设置后，从 GitHub Enterprise 克隆的仓库将使用该主机执行 hub 命令，而从 GitHub 克隆的仓库则继续使用 GitHub。
2. Travis CI
概要
“Travis CI 是一款免费服务，专门为开源开发组织提供持续集成（Continuous Integration，CI）功能。”

CI 的定义
持续集成：一种软件开发实践，允许自动测试和构建，以确保代码质量。
Travis CI 的优势
监视仓库，自动执行测试和构建，检测意外提交或逻辑偏差。
支持多种编程语言，如 Ruby、PHP、Perl、Python、Java、JavaScript。
设置 Travis CI
创建配置文件：在仓库中添加 .travis.yml 文件。

yaml
Copy
language: ruby
rvm:

1.9.2
1.9.3
script: bundle exec rspec spec
描述内容：

使用的语言
版本
执行测试的命令
检测配置文件
使用 Travis WebLint 检测 .travis.yml 文件是否存在问题。
与 GitHub 集成
登录 Travis CI 网站，使用 GitHub 认证。
在账户页面中，将仓库的开关设置为 ON。
访问 GitHub 的 Webhooks & Services 页面，配置 Travis。
自动测试验证
点击 “Test Hook” 按钮进行试验性自动测试，确保设置正常。
3. Coveralls
概要
“Coveralls 是一款代码覆盖率检测服务，支持多种编程语言。”

功能
提供自动测试的覆盖率报告，支持 Ruby/Rails、Python、PHP 等。
可查看代码每部分的执行次数，帮助改进测试效率。
安装步骤
注册账户：访问 Coveralls 首页，点击 “FREE SIGN UP”。

添加仓库：在 Coveralls 首页点击 “ADD REPO” 并设置为 ON。

编写配置文件：创建 .coveralls.yml 文件，内容如下：

yaml
Copy
service_name: travis-ci
添加 gem（如果使用 Ruby）：

ruby
Copy
gem ‘coveralls’, require: false
查看报告
Push 操作后，Coveralls 会生成报告，报告可以在 GitHub 的 README.md 中显示。
4. Jenkins
概要
“Jenkins 是代表性的持续集成服务器，支持与 GitHub 集成。”

安装步骤
从 Jenkins 官网下载相应的安装包，使用标准方法进行安装。
访问 http://jenkins所在服务器的IP地址:8080/ 查看初始界面。
创建 bot 账户
新建 GitHub 账户以便 Jenkins 访问仓库，创建无密码短语的 SSH 密钥。
设置权限
公开仓库：需要写入权限。
组织账户：在团队中添加 bot 账户并设置为 Write Access。
设置 SSH 密钥
Jenkins 需要用 bot 账户的私钥访问仓库，配置私钥路径。
使用 Pull Request 进行自动测试
安装 GitHub pull request builder plugin 插件，确保 Pull Request 的自动测试。
工具功能描述
Travis CI 提供持续集成服务，自动测试和构建
Coveralls 提供代码覆盖率检测，生成测试覆盖率报告
Jenkins 代表性持续集成服务器，与 GitHub 集成自动测试
🛠️ Jenkins 与 GitHub 集成
Pull Request 合并的安全性
“Jenkins 内部构建出 Pull Request 合并之后的状态并执行自动测试。由于其结果会自动发送到 GitHub，所以能够让我们避免‘Pull Request 合并后出现了某些问题导致测试未通过’的情况。”

通过使用 Jenkins 和 GitHub 的集成，Pull Request 的合并过程变得更加安全，确保在合并前经过充分的测试。

Jenkins 插件安装
安装 GitHub Pull Request Builder 插件
访问 Jenkins 主界面
依次选择“系统管理”→“管理插件”
选择“可选插件”标签页
找到并勾选 GitHub pull request builder plugin
点击“直接安装”
Git 插件设置
进入“系统管理”→“系统设置”页面，配置 Git 插件。
在 Global Config user.name 中输入姓名
在 Global Config user.email 中输入邮箱地址（这两项为必填项）
GitHub Pull Requests Builder 设置
API 和 Access Token 配置
Github server api URL: 普通用户无需更改，GitHub Enterprise 用户需配置。
Access Token: 通过 bot 账户的 Access Token 与 GitHub 的 API 进行互动。
填写 Username 和 Password 后点击 Create access token。
成功获取后，将生成的字符串复制到 Access Token 栏中。
Admin List 配置
通过在 Admin list 中添加 GitHub 用户名，赋予该用户执行 Jenkins 任务的权限。

Jenkins 任务创建与设置
创建新任务
点击“创建一个新任务”，输入任务名称，选择“构建一个自由风格的软件项目”。
在 GitHub project 中输入 GitHub 仓库的 URL，例如 https://github.com/github-book/ghprb/。
在“源码管理”中选择 Git。
Repository URL 输入 SSH 协议的 URL，例如 git@github.com:github-book/ghprb.git。
若在 ~/.ssh/config 中进行了设置，需替换主机名。
Repositories 的高级设置
在 Repositories 的“高级”中，输入以下内容：
Refspec: +refs/pull/:refs/remotes/origin/pr/
Branch Specifier: ${sha1}
构建触发器设置
勾选 GitHub Pull Requests Builder。
输入管理者的用户名到 Admin list。
配置 Crontab line，例如每 5 分钟检查一次 Pull Request。
在 White list 中填写可能发送 Pull Request 的 GitHub 用户名。
自动测试结果的通知
自动测试的结果会通过 GitHub pull request builder plugin 发送到 GitHub，使用 Commit Status API 进行状态更新。

Pull Request 状态显示
自动测试进行中时，状态显示为执行中的状态。
测试未通过时，会标记为失败，点击 Details 链接可查看详细信息。
测试全部通过时，状态将显示为绿色。
通过评论控制任务执行
执行任务与添加至 White List
Admin list 外的用户发来 Pull Request 时，bot 账户会询问“Can one of the admins verify this patch?”。
Admin list 用户可通过评论“ok to test”开始任务。
若需将用户添加至 White list，使用“add to whitelist”的评论。
重新执行任务
若需重新执行任务，Admin list 或 White list 中的用户只需发送“retest this please”的评论。

结论
通过 Jenkins 和 GitHub pull request builder plugin 的集成，开发者可以在合并 Pull Request 时保证代码的质量和安全性。持续集成变得更加简单和有效。

🛠️ GitHub Flow 开发流程
GitHub Flow 概述
“GitHub Flow 是一种轻量级的分支工作流，非常适合持续部署和持续集成的环境。”

主要步骤
从主分支创建新分支：无论是添加新功能还是修复BUG，都需要从最新的主分支（master）创建一个新的分支。
进行代码修改：在新分支中进行所有实际的代码修改。
提交更改：将代码修改提交到新分支。
创建 Pull Request：请求将新分支的更改合并到主分支。
接受反馈：等待其他开发者的审查和反馈。
合并分支：在代码审查通过后，将新分支合并到主分支。
合并与部署
合并后部署：代码合并至主分支后，必须立即进行部署，并确认合并的代码是否存在问题。
实践 GitHub Flow 的前提条件
自动化部署
“部署的相关作业必须实现自动化，以避免人为失误和时间浪费。”

使用 Capistrano 等部署工具，简化部署流程为一条指令，并减少人为错误。
部署工具通常具有回滚功能，确保在出现问题时可以轻松恢复到之前的版本。
Web 界面部署工具
Webistrano 和 Strano 等工具提供了通过Web界面执行部署指令的功能，方便非开发人员操作。
部署工具名称 URL 备注
Capistrano 链接 Ruby 开发的代表性部署工具
Mina 链接 Ruby 开发的部署工具
Fabric 链接 Python 开发的部署工具
Cinnamon 链接 Perl 开发的部署工具
Webistrano 链接可通过Web执行Capistrano的工具
Strano 链接可通过Web执行Capistrano的工具
开发中的注意事项
重视测试
自动化测试：每次部署前必须在测试环境中进行自动化测试，以确保代码没有被意外破坏。
测试代码的编写：每个 Pull Request 必须包含测试代码，且代码必须在本地通过所有测试后才能推送到远程仓库。
维护测试代码
测试代码需要定期维护，以适应快速发展的开发流程。
模拟体验 GitHub Flow
添加新功能
假设我们需要在 Fizzbuzz 软件中添加一个新功能：当输出数字中包含7时显示“GitHub”。

创建新的分支：从主分支创建一个名为 7-case-output-github 的新分支。

bash
Copy
git checkout -b 7-case-output-github
实现新功能：在 fizzbuzz.rb 中添加代码逻辑。

ruby
Copy
elsif number.to_s.include? ‘7’
‘GitHub’
提交更改：

bash
Copy
git commit -am “Add output GitHub”
推送到远程仓库：

bash
Copy
git push
创建 Pull Request：将新分支的更改请求合并到主分支。

接收反馈与修复
其他开发者可能会反馈代码中的问题，比如缩进不规范和缺少测试代码。
修正缩进
修正代码缩进后，提交并推动更改。
bash
Copy
git commit -am “Fix indent”
git push
添加测试代码
根据反馈，添加测试代码以保证新功能的正确性。
ruby
Copy
context ‘GitHub number’ do
it { subject.calculate(17).should eq ‘GitHub’ }
it { subject.calculate(27).should eq ‘GitHub’ }
it { subject.calculate(75).should eq ‘GitHub’ }
it { subject.calculate(77).should eq ‘GitHub’ }
end
执行测试并确保所有测试通过。
重要提示
在 GitHub Flow 中，任何没有测试代码的功能都不应被合并至主分支。
🛠️ GitHub 开发流程
代码测试与确认
在代码开发过程中，测试是确保代码正确性的重要环节。以下是代码测试的基本流程：

使用 rspec 进行测试，确保所有代码通过。
示例输出：
text
Copy
$ rspec
…
Finished in 0.00353 seconds
14 examples, 0 failures
“测试代码已经添加，新功能也已实现。”

Pull Request 的培育
在将新功能合并到主分支（master）之前，需进行以下步骤：

提交代码：
bash
Copy
$ git commit -am “Fix output GitHub”
推送变更：
bash
Copy
$ git push
“确认Pull Request没有问题之后，便可以通过评论请求与master合并了。”

Pull Request 过程
步骤操作
提交代码 $ git commit -am “Fix output GitHub”
推送代码 $ git push
确认合并请求通过评论请求与master合并
Pull Request 合并
一旦代码通过审查，便可将其合并至主分支。合并完成后，主分支将被部署至正式环境。

团队实践 GitHub Flow 时的建议
在实际开发中，遵循以下建议可以提高团队协作效率：

减小 Pull Request 的体积
分功能细分：将一个大功能拆分为多个小功能，减少每次提交的代码量。
频繁提交：每几小时至几天向主分支发送一次 Pull Request。
“开发时间越长或代码量越大，代码审查成本越高。”

准备可供试运行的环境
创建一个与正式环境高度相似的预演环境，确保关键修改的安全性。
部署前先在预演环境中进行测试，降低风险。
避免 Pull Request 中的过多反馈
交流不足：如果Pull Request的理由没有获得认同，应选择其他方式进行讨论。
技术或能力不足：团队应制定编程规则，避免频繁出现问题。
结对编程与学习小组
结对编程：通过结对编程提高代码质量与团队成员的技能。
知识共享：组织学习小组，分享参考资料，提升整体开发水平。
Pull Request 管理
为防止 Pull Request 堆积，建议团队制定以下规则：

审查与反馈：想创建 Pull Request 的开发者先对其他人的 Pull Request 进行审查。
及时合并：在可部署时及时合并 Pull Request。
“在以部署为中心的开发流程中，积攒 Pull Request 会导致长期无法部署，影响开发效率。”

Git Flow 的概述
Git Flow 是一种以发布为中心的开发模式，适用于管理软件发布。

Git Flow 流程简述
创建分支：从开发分支（develop）创建工作分支（feature branches）。
合并分支：功能完成后，将工作分支合并到开发分支。
发布管理：创建发布分支（release branches），处理发布工作。
修复 BUG：发布后如遇 BUG，使用热修复（hotfixes）进行修正。
流程步骤描述
创建工作分支从开发分支创建功能分支
合并工作分支功能完成后与开发分支合并
创建发布分支用于发布的分支，处理发布相关工作
合并至主分支发布完成后与主分支合并，并打上版本标签
修复 BUG 针对发布的软件出现的 BUG 进行热修复
Git Flow 的准备
在实施 Git Flow 之前，需进行以下准备：

安装 git-flow
根据操作系统安装 git-flow 工具，以简化 Git Flow 的使用。

Mac 安装：

bash
Copy
$ brew install git-flow
Linux 安装：

bash
Copy
$ sudo apt-get install git-flow
仓库初始设置
创建 GitHub 仓库。
克隆仓库：
bash
Copy
$ git clone git@github.com:hirocaster/blog.git
初始化 Git Flow：
bash
Copy
$ git flow init -d
分支管理
master 分支：保持软件正常运行的状态，不允许直接修改。
develop 分支：开发过程中的代码中心，不允许直接修改。
feature 分支的工作流程
从 develop 分支创建 feature 分支。
在 feature 分支中进行功能开发。
向 develop 分支发送 Pull Request。
经审查后，将 Pull Request 合并至 develop 分支。
“通过以上流程，确保代码的高质量与高效的团队合作。”

🛠️ GitHub 开发流程
创建分支
在分支中进行作业时，首先在刚刚创建的 feature/add-user 分支中实现目标功能并进行提交。实际编写代码以及提交的过程在此不再赘述，进行几次提交后，会呈现如下状态：

text
Copy
feature/add-user
start
commit
develop
commit
发送 Pull Request
功能实现之后，需要通过 GitHub 发送 Pull Request（合并请求），请求将 feature/add-user 分支的内容合并到 develop 分支。注意，这里不能与本地的 Git 仓库进行合并，而是要利用 GitHub 的 Pull Request 功能接受代码审查，然后再合并到远程仓库的分支中。这样可以让其他开发者看到我们的代码，从而指出其中的问题。

推送分支到远程仓库
首先将 feature/add-user 分支推送到 GitHub 端远程仓库：

bash
Copy
$ git push origin feature/add-user
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 452 bytes | 0 bytes/s, done.
Total 5 (delta 1), reused 0 (delta 0)
To git@github.com:hirocaster/blog.git

[new branch] feature/add-user -> feature/add-user
更新本地分支
如果与其他开发者共同开发同一个 feature 分支，确保通过 pull 操作获取 feature/add-user 分支的最新代码。此外，在开发 feature 分支的过程中，develop 分支可能已更新，因此要养成在推送之前先获取最新 develop 分支的习惯。

创建 Pull Request
在 GitHub 的仓库页面切换到 feature/add-user 分支，确认页面中显示的是 develop 分支和 feature/add-user 分支的差异。如果发现是 master 等其他分支，需要点击右侧的 Edit 按钮进行切换。确认页面中显示的对象为 develop…feature/add-user 后，点击 Click to create a pull request for this comparison。

通过代码审查提高代码质量
发送 Pull Request 后，通过以下步骤利用 Pull Request 从其他开发者那里获取反馈，不断精炼代码：

由其他开发者进行代码审查，在 Pull Request 中提供反馈。
修正代码以反映反馈内容（在本地 feature/add-user 分支中）。
将 feature/add-user 分支推送到远程仓库（自动添加至之前的 Pull Request）。
重复前三步。
确认 Pull Request 没有问题后，由其他开发者将其合并至 develop 分支。
反馈要点
没有测试或测试未通过
违反编码规则
代码质量过低（命名不明确，方法冗长等）
还有重构的余地
有重复部分
更新本地的 develop 分支
发送的 Pull Request 在 GitHub 端与 develop 合并后，为了让其反映到本地的 develop 分支中，需要进行以下操作：

切换至 develop 分支
执行 git pull（fetch & merge）
bash
Copy
$ git checkout develop
Switched to branch ‘develop’
$ git pull
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (1/1), done.
From github.com:hirocaster/blog
ad139da…9299f28 develop -> origin/develop
Updating ad139da…9299f28
Fast-forward
add-user-1 | 0
add-user-2 | 0
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 add-user-1
create mode 100644 add-user-2
在 release 分支中进行的工作
假设已经通过 feature 分支为 develop 分支添加了多个功能，软件进入发布阶段。在这一阶段，实现所有要发布的功能，发送 Pull Request 并与 develop 分支合并。

创建 release 分支
从最新的 develop 分支着手，开始 1.0.0 版本的 release 工作：

bash
Copy
$ git checkout develop
$ git pull
$ git flow release start ‘1.0.0’
Switched to a new branch ‘release/1.0.0’
分支内的工作
在 release 分支中，只处理与发布前准备相关的提交，例如版本编号变更等元数据的添加工作。该分支中绝对不可以包含需求变更或功能变更等重大修正。

进行发布与合并
发布前的修正处理完后，结束这一分支：

bash
Copy
$ git flow release finish ‘1.0.0’
查看版本标签
通过前面一系列操作，创建了与发布版本号相同的 Git 标签：

bash
Copy
$ git tag
1.0.0
更新到远程仓库
对多个分支进行了修改后，利用 push 操作将修改更新到远程仓库。

bash
Copy
$ git push origin develop
$ git push origin master
$ git push --tags
在 hotfix 分支中进行的工作
hotfix 分支是紧急应对措施，只有当前发布的版本中出现 BUG 或漏洞时，才会创建该分支。

创建 hotfix 分支
如果在发布版本中发现 BUG 或漏洞，且需要立即处理，则需要创建 hotfix 分支：

bash
Copy
$ git fetch origin
$ git flow hotfix start ‘1.0.1’ ‘1.0.0’
创建标签和进行发布
假设发送的 Pull Request 经过审查并与 master 分支合并，现在可以利用 GitHub 的功能创建 1.0.1 的标签。访问 GitHub 的仓库页面，选择 Release，打开该仓库的发布信息。

🏷️ Git 分支管理与版本控制
📚 Git 分支的合并
分支合并操作
在版本 1.0.1 发布后，之前的版本完成了生命周期。执行以下命令来确认标签是否成功创建：

bash
Copy
$ git fetch origin
标签获取：此命令用于从远程仓库获取最新的标签信息。

查看当前标签
执行以下命令查看当前已有的标签：

bash
Copy
$ git tag
标签列表：返回所有标签，例如 1.0.0 和 1.0.1。

🔄 从 hotfix 分支合并至 develop 分支
合并步骤
从 hotfix/1.0.1 分支向 develop 分支发送 Pull Request。
经过其他开发者审查后，修改内容会被合并到 develop 分支。
注意事项
异常处理：如果合并后 develop 分支出现异常，不要在 hotfix/1.0.1 分支中进行修正。应先完成 hotfix 与 develop 的合并，再在 develop 分支中进行修复。

hotfix 分支的使命
hotfix 分支只对 master 分支的内容进行最小限度的修改，合并后可以被删除。
📊 Git Flow 的小结
版本号分配规则
版本控制策略中，软件版本号的分配规则如下：

版本号格式规则说明
x.y.z 采用三位数字表示版本号
x 重大功能变更时加1，y与z归0
y 添加新功能或删除功能时加1，z归0
z 进行内部修改后加1
版本示例
1.0.0：最初发布的版本
1.0.1：修正了轻微 BUG
1.1.0：添加新功能
2.0.0：更新整体 UI 并添加新功能
🏢 将 GitHub 应用到企业
引入 GitHub 的好处
有助于程序员按照自己的习惯进行开发，降低压力。
新入行的程序员可以快速熟悉开源开发环境。
使用 Organization 账户
企业建议使用 Organization 账户来统一管理团队和权限。
确认安全性
安全保障：GitHub 提供严格的数据安全管理，用户数据存储在其数据中心，并有完善的操作规范。

维护时间注意事项
GitHub 会定期进行系统维护，建议关注维护时间，以免影响项目开发。
🛠️ GitHub Enterprise 的优缺点
引入的好处
GitHub Enterprise 使企业内部开发者能够构建社会化编程环境。
引入的弊端
需要额外的服务器和人力成本进行维护。
适合引入 GitHub Enterprise 的情况
适合场景说明
源代码不可外传源代码作为企业的财产，需在内部网络管理。
希望控制维护与故障时间需在既定时间发布的软件。
🖥️ Git 托管的软件
开源替代软件
软件名称说明
GitBucket 类似于 GitHub 的开源项目。
GitLab 提供完整的 Git 托管解决方案。
Bitbucket 支持 Git 与 Mercurial 的版本管理。
使用 Gist 进行代码共享
Gist 是一款简单的 Web 应用程序，用于共享示例代码和错误信息。

Gist 的特点
支持版本管理，用户可放心编辑。
提供语法高亮，增强代码可读性。
创建 Gist
用户可以在 GitHub 上创建 Gist，方便记录和分享代码段。

📂 Gist 的创建与使用

文件命名
“用户可以指定文件名，系统会自动识别扩展名并相应设置编程语言。”

用户输入的文件名（如“hello_gist.rb”）将自动设置语言为Ruby。
默认情况下，未指定文件名时，系统会以“gistfile1.扩展名”的形式自动分配名称。
2. 选择编程语言
在创建文件时，用户可以选择编程语言。
如果未指定文件名，文件的扩展名将基于所选语言进行设定。
语法高亮功能会依赖于所选择的语言。
3. ACE 编辑器设置
该复选框可用于指定ACE编辑器是否有效。
建议保持有效，以便进行常规的插入和缩进操作。
用户可以选择用空格或Tab进行缩进，并设置缩进幅度。
4. 文件内容编辑
文件文本框用于手动编写或粘贴内容。
与常用编辑器或集成开发环境（IDE）相似，内容会根据选择的语言进行即时语法高亮。
5. 添加另一个文件
一个Gist中可以包含多个文件。
点击按钮可添加新的文件信息输入框。
6. 创建私密或公开的Gist
创建私密Gist：只有知道URL的人可以访问。
创建公开Gist：在“Discover Gists”中可以看到创建的Gist，每个Gist会自动分配一个URL（如：https://gist.github.com/hirocaster/8374839）。
7. 查看Gist
登录GitHub后，用户可以在Gist中添加评论和编辑自己的Gist。
Gist 页面菜单
菜单项描述
Edit 编辑自己的Gist
Delete 删除自己的Gist
Report as Abuse 举报不良内容
Star 将Gist标记为Star以便快速查找
Fork 根据他人的Gist创建自己的Gist
8. Gist详细信息
访问Gist的URL时，会显示文件内容和评论等详细信息。

Gist的功能
功能描述
Revisions 查看Gist的变更历史
Download Gist 将Gist以tar.gz格式下载
Clone this gist 显示克隆所需的路径
Embed this gist 获取分享至博客所需的HTML代码
Link to this gist 显示当前Gist的URL
9. Your Gists 页面
用户可以通过点击“Your Gists”按钮或直接访问URL查看自己的Gist列表。
列表中显示通过Fork创建的Gist和已标记Star的Gist数量。
10. 小结
“通过Gist，我们可以轻松共享笔记、错误信息及一些不必要放入仓库的代码片段。”

鼓励用户在日常中多加利用Gist，与他人共享琐碎信息。
在这里插入图片描述