了解 GitHub 在开发生命周期中的位置

学习目标

完成本单元后，您将能够：

• 列出现代开发人员工具包中的基本工具。
  
• 说明 Git 和 GitHub 如何在软件开发生命周期 (SDLC) 中协同工作。
  
• 描述 GitHub 在软件开发生态系统中的核心定位。
  

Git 和 GitHub 的区别

Git 和 GitHub 共享名称和用途，但它们并不是一回事。要准确划分 Git 和 GitHub 之间的界线可能需要一些时间，但这没关系。我们在上一单元中分别介绍了它们，但现在让我们仔细看看两者如何协同工作。

Git 是一个版本控制应用程序

简而言之，Git 是一个应用程序，它可以跟踪与随时间推移项目中的更改相关的所有内容。让我们先来定义几个关键术语：

• 存储库：用于编译项目的源文件的集合。
  
  
• 提交：您的项目在特定时间点的快照。在您处理项目时，通过创建提交来标记添加或删除各个工作单元的时间点。
  
  
• 分支：代表项目随时间变化的一系列提交。每个存储库都有一个默认分支，其中包含代码的生产就绪版本。构建新功能、修复错误或对项目进行其他更改时，则会创建额外的分支。这些分支会将您的实验代码与经过测试的生产代码分开保存。
  
  
• 合并：两个或多个分支的合并历史。大多数情况下，您会将功能分支合并到存储库的默认或已部署分支中，以便将功能转移到生产环境中。
  
  
• 标记：指向特定提交的指针，提供对事件的持久引用。通常，标签与语义版本控制一起使用以表示应用程序发布的时间点。
  

GitHub 是一个协作平台

GitHub 是一个 Git 存储库主机，具有用于应用和测试代码更改的协作功能。在 Git 中，GitHub 充当远程存储库，为开发人员的共享工作提供可访问的权威来源。除了可以访问存储库的所有 Git 数据之外，GitHub 还有一些自己的关键术语：

• 问题：对您的项目进行一般性讨论，为新功能制定计划，以及讨论错误。问题只是一个讨论，不会对代码进行实际的更改。
  
  
• 拉取请求：拉取请求是您请求合并到默认分支的提交包。拉取请求提供了一个供您讨论您提议的更改并邀请其他团队成员发表评论和完成代码审查的位置。您还可以在拉取请求中查看自动化测试和许多其他出色集成的结果。
  

GitHub 旨在提供一个高度透明的上下文环境，使开发人员能够发挥最好的工作水平。 

简而言之，Git 处理版本控制，而 GitHub 则处理协作。

现代开发人员工具包

Git 和 GitHub 共同构成了现代开发人员工具包的核心。与 Salesforce 应用程序类似，数百个集成商构建了大量工具，允许您根据自己的偏好自定义和扩展 GitHub 的功能。这个不断增长的生态系统负责项目管理、持续集成测试、发布和代码审查等关键任务。开发人员可能每天都使用 GitHub，但不太可能只使用这一个工具。 

以下是一些值得注意的例子：

GitHub 包含一个用于进行更改的简单 UI，但大多数开发人员更喜欢在本地集成开发环境 (IDE) 中工作。Sublime Text 和 VSCode with Salesforce Extensions 等现代文本编辑器越来越受欢迎，因为它们采用相同的可自定义方法，将简单的文本编辑功能与数以千计的用户创建的软件包相结合，以完善和自定义工作流。

持续集成 (CI) 和持续部署 (CD) 应用程序是您可以添加到工作流中的最强大的工具。通过 GitHub，这些 CI 和 CD 集成可以根据存储在存储库中的规范测试、构建和发布您的项目。这些集成减少了手动测试的时间和挫败感，减少了诸如“奇怪，在我的机器上就没问题”之类的不一致，并且无需等待其他人进行简单的审查和测试。

还有无数其他与 GitHub 配合使用的集成，例如代码质量检查工具、依赖项管理，甚至是自动安全检查。借助 GitHub 的 API 和 Webhook，您能够以开发人员需要的任何方式轻松添加和定制新的集成。

根据您的需要自定义工作流

GitHub 拥有无数选项，可供您根据您的特定项目需求和偏好进行定制。无论您是喜欢 GitHub 内置项目这样的紧凑型项目管理解决方案，还是喜欢 ZenHub 集成等功能齐全的解决方案，GitHub 生态系统都能为您提供大量选择。在下一个单元中，我们将带您了解基本的 GitHub 流程，但后续如何使用它将由您决定！