1. 学习基础知识

版本控制系统（VCS）是一种帮助开发者管理代码随时间变化的工具。它允许多个项目版本同时存在，使得与他人协作和维护所有修改记录变得更加容易。

◇什么是版本控制？

版本控制是一种管理和跟踪文件随时间变化的系统，允许多人在项目上协作，同时维护所有修改的历史记录。它记录文件的更改，如代码、文档或配置文件，并将它们存储在仓库中。通过版本控制，开发者可以恢复到以前的版本，比较不同版本之间的差异，并了解项目的演变过程。它支持分支功能，允许不同的开发线独立进行，以及合并功能，将不同分支的更改结合起来。总的来说，版本控制确保更改是有组织的、可恢复的，并且易于管理，使其成为软件开发和协作项目中的关键工具。

◇为什么要使用版本控制？

使用版本控制对于管理软件开发中的更改至关重要，因为它能够跟踪修改、协作并维护项目的历史记录。它允许多个开发者同时在同一代码库上工作，而不会覆盖彼此的工作，并提供了谁进行了更改以及为什么进行更改的清晰记录。版本控制系统支持回滚到以前的版本，如果出现问题，它们还支持分支和合并，这对于尝试新功能和管理开发的不同阶段至关重要。总的来说，版本控制确保了代码质量、责任和项目中的高效协作。

◇Git与其他VCS的对比

Git已经成为软件开发中源代码控制的事实标准，但它并不是唯一的版本控制系统（VCS）。以下是Git与其他流行的VCS之间的一些关键区别：

  • Mercurial：Mercurial是一个分布式VCS，使用与Git类似的架构。然而，它采用更中心化的方法，并且不使用哈希来跟踪更改。

  • Subversion：Subversion是一个中心化的VCS，经常与Git进行比较。虽然两者都支持分支和合并，但Subversion需要一个中央服务器来管理仓库。

  • Perforce：Perforce是一个商业VCS，专为大规模开发项目设计。它采用中心化方法，并具有构建自动化和问题跟踪等功能。

  • CVS：CVS是一个较旧的版本控制系统，至今仍在使用。然而，它缺乏许多现代功能，通常被认为是过时的。

  • 文章 Git与其他VCS的对比分析

◇在本地安装Git

要在本地机器上使用Git，首先需要安装它。安装过程因操作系统而异：

在Windows上：从官方Git或GitHub发布页面下载二进制文件，并按照安装说明进行操作。 在macOS上（使用Homebrew）：在终端中运行brew install git。 在Linux上：根据你的发行版运行sudo apt-get install git或sudo yum install git。 安装完成后，可以通过在终端中运行git --version来验证Git版本。这将显示当前安装的Git版本。

2. 什么是仓库

仓库是存储项目代码、文档和其他文件的地方。它作为协作、版本控制和代码管理的中心枢纽，允许多人在同一项目上工作而不会覆盖彼此的工作。

◇git init

git init命令创建一个新的Git仓库。它可以用于将现有的未版本化的项目转换为Git仓库，或者初始化一个新的空仓库。大多数其他Git命令在未初始化的仓库之外不可用，因此这通常是你在新项目中运行的第一个命令。

◇git config

git config命令是一个便捷函数，用于在全局或本地项目级别设置Git配置值。这些配置级别对应于.gitconfig文本文件。执行git config将修改一个配置文本文件。

git config最基本的用例是使用配置名称调用它，这将显示该名称的设置值。配置名称是由“部分”和“键”组成的点分隔字符串，基于它们的层次结构。例如：user.email

◇本地与全局配置

要管理本地和全局配置设置，可以使用git config命令与--local和--global选项。

◇工作目录

Git中的工作目录是存储和修改项目文件的本地环境。它反映了项目文件的当前状态，允许开发者编辑、添加或删除文件。在工作目录中所做的更改可以暂存以提交，这意味着它们已准备好包含在下次提交中。工作目录与Git仓库相连，并帮助管理提交历史与文件当前状态之间的差异。它在跟踪更改、测试和开发新功能中起着核心作用。

◇暂存区

在Git中，暂存区是本地仓库更改与实际提交之间的中间步骤。

◇提交更改

在Git中提交更改是版本控制的关键部分，允许你保存进度并记录项目当前状态的快照。

◇.gitignore

忽略的文件在一个名为.gitignore的特殊文件中进行跟踪，该文件在仓库的根目录中检入。没有明确的git ignore命令：相反，当你希望忽略新文件时，必须手动编辑并提交.gitignore文件。.gitignore文件包含与仓库中文件名匹配的模式，以确定是否应忽略它们。

◇查看提交历史

查看提交历史是Git的一个关键方面，允许用户检查仓库更改的时间顺序记录。此功能对于理解项目演变、跟踪修改和促进有效的团队协作至关重要。Git提供了各种命令，如git log及其选项（例如--oneline、--graph、--patch、--stat），以不同格式显示提交历史。用户可以通过作者、日期范围和其他条件过滤提交。通过定期查看提交历史并遵循最佳实践，如编写清晰的提交消息和使用标签，开发者可以获得有关项目开发的宝贵见解，并对未来的更改做出明智的决策。

3. 分支基础

Git中的分支作为独立的开发线，允许多个功能或更改同时进行，而不会影响主代码库。通过分支，你可以为不同的任务创建隔离的环境，与他人协作，并管理复杂的工作流程。

◇创建分支

在Git中创建分支是使用版本控制的基本部分，允许你在不影响主代码库的情况下处理不同的功能或修复。你可以通过终端或GitHub界面创建分支。

◇重命名分支

在Git中重命名分支意味着将分支的名称更改为不同的名称，同时保留其历史和包含的提交。分支本身在代码和历史方面保持不变，但引用（你用来引用它的名称）会更新。

◇删除分支

删除Git分支意味着从Git仓库中移除一条开发线。Git中的分支本质上是指向特定提交的指针，代表一条独立的开发线。当你删除一个分支时，你移除了这个指针，使得该开发线不再通过分支名称访问。

◇检出分支

在Git中，“检出”分支意味着将你的工作目录切换到该分支，使其成为活动分支。这将更新你的文件以匹配该分支的状态，并允许你对其进行工作。

◇合并基础

Git中的合并是将一个分支的更改合并到另一个分支的过程。当你想要将一个分支（源分支）的更新集成到另一个分支（目标分支）时，你需要执行合并。这涉及解决两个分支之间的冲突（如果存在）。合并的目标是创建一个新的提交，代表两个分支的合并更改，从而为你的项目创建一个单一的、连贯的历史记录。

4. GitHub 基础

GitHub 基础指的是构成 GitHub 版本控制和协作平台核心功能的基本要素。这些基础包括用于存储和管理代码的仓库、用于并行开发的分支、用于代码审查和合并的拉取请求、用于跟踪任务和问题的议题，以及项目板和 Wiki 等协作工具。理解并掌握这些基本组件，开发者可以有效地管理他们的项目，与团队成员协作，并为开源项目做出贡献，使 GitHub 成为现代软件开发工作流程中不可或缺的工具。

◇创建账户

要开始使用 GitHub，你需要在 GitHub.com 上创建一个免费的个人账户并验证你的电子邮件地址。每个使用 GitHub.com 的人都会登录到一个个人账户。你的个人账户是你在 GitHub.com 上的身份标识，拥有用户名和个人资料。

◇GitHub 界面

GitHub 界面是一个基于 Web 的平台，为管理和协作软件项目提供了一个用户友好的环境。它通过直观的布局提供了一套全面的工具和功能，包括仓库管理、代码浏览、议题跟踪、拉取请求和项目板。该界面旨在简化工作流程，促进团队沟通，并提高各级开发者的生产力。凭借其简洁有序的结构，用户可以轻松地在项目的不同部分之间导航，审查代码更改，管理任务并与团队成员互动，使其成为现代软件开发和版本控制的重要工具。

◇设置个人资料

在 GitHub 上，创建个人资料是展示自己作为开发者或贡献者的重要一步。

  • 分享信息：你的个人资料页面允许他人了解更多关于你的信息，包括你的兴趣和技能。

  • 展示项目：你可以展示你的重要项目和贡献，让他人了解你的工作经验。

  • 表达身份：个人资料也是一个表达个人身份的机会，允许你在 GitHub 社区中传达你独特的个性和风格。

  • 官方 设置你的个人资料

  • 视频 GitHub 个人资料 README

个人资料 README

GitHub 个人资料 README 是一个特殊的仓库，允许用户直接在他们的 GitHub 个人资料上展示他们的技能、项目和个性。要创建一个，你需要新建一个与你的 GitHub 用户名相同的仓库。该仓库应包含一个 README.md 文件，GitHub 会自动在你的个人资料页面上显示该文件。README 可以使用 Markdown 格式进行自定义，允许你添加文本、图片、链接，甚至动态内容如 GitHub 统计数据或最近的博客文章。此功能为你提供了一个独特的机会，使你的 GitHub 个人资料对访问者更具吸引力和信息量，有效地作为你 GitHub 存在的个性化登录页面。

◇创建仓库

创建一个 Git 仓库意味着设置一个系统来跟踪项目文件随时间的变化。这对于版本控制至关重要，允许你高效地管理、审查和协作代码。

私有 vs 公开

GitHub 提供私有和公开仓库，每种仓库在软件开发中都有不同的用途。公开仓库对互联网上的所有人可见，非常适合开源项目、协作和向更广泛的受众展示工作。它们鼓励社区贡献，并可以帮助开发者建立他们的作品集。另一方面，私有仓库仅对仓库所有者和指定的协作者可见。这些仓库适用于专有代码、敏感项目或尚未准备好公开的工作。私有仓库提供了更大的访问和可见性控制，使其成为需要保密代码的企业和个人的必备工具。

5. Git 远程仓库

在 Git 中，远程仓库是指存在于另一台服务器或系统上的仓库的引用。远程仓库允许你访问和交互存储在其他地方的仓库副本，从而使得与他人协作、分享你的工作以及为备份和灾难恢复目的维护多个仓库副本成为可能。当你向本地仓库添加远程仓库时，Git 会创建一个对远程仓库的引用，使你能够将更改从本地仓库推送到远程仓库，从远程仓库拉取更改到本地仓库，或从远程仓库获取更改而不更新本地副本。这使得分布式开发成为可能，并有助于维护项目历史的集中版本，从而更容易跟踪更改、管理冲突并确保每个人都能访问最新的代码。

◇克隆仓库

在 Git 和 GitHub 中克隆仓库涉及在计算机上创建远程仓库的本地副本。这允许你在本地处理项目，提交更改，然后将这些更改推送回远程仓库。

◇管理远程仓库

在 Git 中，远程仓库是指存储在服务器或其他机器上的项目源代码的副本。

  • 添加远程仓库：使用 git remote add [name] [url] 添加一个新的远程仓库。这允许你跟踪更改并从远程推送/拉取更新。

  • 列出远程仓库：运行 git remote -v 列出所有配置的远程仓库及其 URL。

  • 重命名远程仓库：使用 git remote rename [old-name] [new-name] 更新现有远程仓库的名称。

  • 删除远程仓库：使用 git remote remove [name] 删除远程仓库。 管理远程仓库对于协作项目或跟踪上游源的更改至关重要。

  • 官方 管理远程仓库

◇推送 / 拉取更改

当你在 Git 中拉取更改时，你正在从远程仓库获取并将更改集成到本地仓库中。此操作会使用远程分支的最新更改更新你的本地分支。而当你在 Git 中推送更改时，你正在将本地提交发送到远程仓库，如 GitHub、GitLab 或 Bitbucket。此操作会使用你的最新更改更新远程仓库。

◇获取而不合并

运行 git fetch 会从远程仓库获取更改到本地克隆，但不会自动将这些更改合并到本地工作目录中。这与 git pull 不同，后者会同时获取和合并远程更改。通过使用获取而不合并，你可以确保本地克隆与远程仓库的最新信息保持同步，同时保持工作目录不变。然后，你可以选择使用合并或变基来应用这些更改。这种方法有助于保持本地状态的干净和一致，从而更容易管理和提交更改。

6. 合并策略

当将一个分支的更改合并到另一个分支时，Git 提供了多种合并策略可供选择。这些方法允许在将代码更新集成到主分支时具有灵活性和自定义性。可用的选项包括：

  • 快进合并 (Fast Forward, FF)

  • 非快进合并 (Non-Fast Forward)

  • 变基 (Rebase)

  • 压缩 (Squash)

  • 精选 (Cherry Picking)

  • 官方 Git 合并策略

  • 文章 Git 合并选项

◇快进合并 vs 非快进合并

在 Git 中，当你合并分支时，主要有两种类型的合并：快进合并和非快进合并（No-FF）。这些术语描述了 Git 在合并分支时如何处理历史和指针。理解这两种合并类型之间的差异对于有效管理项目的提交历史至关重要。

快进合并发生在你正在合并的分支（通常是主分支或主分支）尚未从你正在合并的分支（通常是功能分支）分叉时。换句话说，目标分支的提交历史是被合并分支的严格子集。在快进合并中，Git 只需将目标分支的指针向前移动到被合并分支的最新提交。不会创建新的合并提交；历史是线性的。

非快进合并（No-FF）发生在目标分支已从被合并分支分叉或你明确选择创建合并提交时。在这种情况下，Git 会创建一个新的提交，代表两个分支的合并。Git 会创建一个新的合并提交，该提交有两个父提交：一个来自目标分支，一个来自被合并分支。合并提交是合并工作的快照，保留了两个分支的历史。

◇变基

Git 中的变基是一个强大且可能复杂的功能，用于重新组织或修改一系列提交。变基的主要目的是通过将一个分支的更改移动或合并到另一个分支上，创建一个更干净、更线性的项目历史。

◇压缩

Git 中的压缩是指将多个提交合并为一个提交的过程。这通常用于创建更干净、更简洁的提交历史，尤其是在将功能分支合并到主分支之前。

◇处理冲突

当多个开发者同时处理同一个项目时，在合并过程中可能会出现冲突。当不同个体在特定代码文件中做出的更改重叠或相互矛盾时，就会发生这种情况。在这种情况下，Git 的冲突解决机制就会发挥作用，允许用户手动解决这些问题并合并冲突的更改。

◇精选提交

Git 中的精选提交允许你将一个分支中的特定提交应用到另一个分支，而无需合并整个分支。当你想从一个分支引入特定功能或修复到另一个分支而不合并源分支的所有更改时，这非常有用。

7. GitHub 协作

GitHub 上的协作是一种强大的方式，允许多人使用 Git 作为版本控制系统在同一项目上协同工作。GitHub 提供了各种工具和工作流程，使协作高效且有条理。

◇Forking 与 Cloning

Forking 和 Cloning 是 Git 中的两个基本概念，尤其是在使用 GitHub、GitLab 或 Bitbucket 等平台托管的仓库时。虽然这两种操作都涉及复制仓库，但它们的目的和工作流程不同。克隆仓库意味着在本地机器上创建远程服务器（例如 GitHub）上存在的仓库的本地副本。这允许您在本地工作，进行更改，然后如果您有必要的权限，将这些更改推回远程仓库。Forking 仓库是 GitHub、GitLab 和 Bitbucket 等平台特有的操作。当您 fork 一个仓库时，您会在自己的账户中创建他人仓库的副本。这个 fork 的仓库独立于原始仓库，可以修改而不影响原始项目。

◇Issues

在 GitHub 上，Issue 是一种跟踪和报告仓库中的错误、功能请求或其他问题的方式。以下是 Issue 的一些关键方面：

  • 创建 Issue：用户可以通过在仓库的 Issues 页面上提交表单来创建新的 Issue。
  • Issue 标题和描述：每个 Issue 都有一个标题和正文（描述），为问题或请求提供上下文。
  • 分配：Issue 可以分配给特定用户，这些用户负责解决问题。
  • 标签：标签用于按主题、优先级或其他标准对 Issue 进行分类。这有助于过滤和组织仓库中的 Issue。
  • 状态：Issue 有反映其状态的状态，例如“Open”、“Closed”或“Pending”。
  • 评论：用户可以对现有 Issue 进行评论，以讨论或提供更多上下文。
  • 标签和里程碑：Issue 可以与标签（主题）和里程碑（截止日期）关联，这有助于过滤和优先处理它们。

Issue 是 GitHub 仓库的核心功能，使团队能够有效地协作解决问题和实现新功能。

◇Pull Requests

Pull Request 是一种将一组更改从一个分支合并到另一个分支的提议。在 Pull Request 中，协作者可以在将更改集成到主代码库之前审查和讨论提议的更改集。Pull Request 显示源分支和目标分支之间的差异（diff）。

从 Fork 创建 PR

在 GitHub 上从 Fork 创建 Pull Request 是为开源项目做贡献或协作您没有直接写权限的仓库的常见工作流程。将原始仓库 fork 到您的 GitHub 账户后，您可以在您的 fork 中进行更改，提交它们，然后创建一个 Pull Request 以将这些更改提议给原始仓库。这个过程允许项目维护者审查您的贡献，讨论任何必要的修改，并最终在批准后将您的更改合并到主项目中。这是一个促进分布式开发环境中协作和代码审查的重要功能。

协作者

GitHub 中的协作者是由仓库所有者或组织管理员授予仓库直接访问权限的用户。协作者可以执行推送提交、创建分支以及管理 Issue 或 Pull Request 等操作，具体取决于授予他们的权限。他们通常被添加到私有仓库或需要更多控制贡献的公共仓库中。

◇标记 Issue / PR

在 GitHub 上，标签是一种按主题、优先级或其他标准对 Issue 和 Pull Request（PR）进行分类的方式。一些常用的标签包括：

  • Bug

  • Duplicate

  • Enhancement

  • Feature request

  • High priority

  • Needs feedback

  • 官方 管理标签

◇保存的回复

GitHub 允许您保存常用的评论，并在讨论 Issue 或 Pull Request 时重复使用它们。

◇提及

GitHub 上的提及功能允许您通知特定用户或团队有关评论、Issue、Pull Request 或其他活动。此功能通过鼓励团队成员之间的参与和讨论、提高重要主题的可见性以及简化仓库内的沟通来改善协作。要使用提及功能，只需在评论中键入 @username 或 @teamname，GitHub 将在您键入时自动完成提及，自动将其用户名链接到评论并通知他们有关讨论。

◇反应

GitHub 中的反应是用户表达他们对 Issue、Pull Request、评论和其他讨论的感受或意见的一种方式，而无需添加额外的评论。它们类似于社交媒体平台上的“点赞”或“表情符号”，提供了一种快速且非语言的参与内容的方式。

◇GitHub Discussions

GitHub Discussions 是 GitHub 仓库内的一个协作通信功能，为社区对话、问题和知识共享提供了一个专用空间。它允许团队成员、贡献者和用户在特定代码更改或 Issue 之外参与线程讨论、分享想法、寻求帮助和发布公告。此功能通过集中重要对话、减少 Issue 跟踪器中的噪音以及围绕开源项目或团队计划培养社区意识来增强项目协作。

8. 最佳实践

◇提交信息

Git 提交信息是对特定提交中引入的更改的简要说明。它帮助其他人（以及未来的您）理解更改的目的及其背后的上下文。编写清晰且信息丰富的提交信息是维护组织良好且易于导航的项目历史的重要实践。

◇分支命名

一个定义良好的分支命名约定对于维护干净且有序的 Git 工作流程至关重要。建议使用描述性和有意义的名称，清楚地表明每个分支的目的。例如，使用前缀如 feature/、fix/ 或 docs/ 可以帮助识别分支是否与新功能开发、错误修复或文档更新相关。此外，包含 Issue 或任务 ID（例如 issue/123）可以提供上下文，并使团队成员更容易找到相关信息。通过遵循一致的命名约定，您可以改善协作，减少混淆，并提高 Git 工作流程的整体效率。

◇PR 指南

Pull Request（PR）指南对于在协作开发环境中维护顺畅且高效的代码审查流程至关重要。这些指南通常概述了创建、格式化和提交 PR 的最佳实践，确保更改得到良好记录、易于审查并符合项目的标准。它们可能涵盖 PR 大小、提交信息格式、文档要求和测试期望等方面。通过建立清晰的 PR 指南，团队可以简化工作流程，提高代码质量，并促进贡献者之间的有效沟通。

◇代码审查

软件开发中代码审查的目的是帮助确保代码符合组织的标准和要求，具有高质量且可维护。除了识别错误和漏洞外，代码审查还促进了开发团队之间的学习和协作文化。

代码审查的一些好处包括：

  • 通过在代码合并到上游分支之前识别代码中的缺陷和问题（如安全漏洞和性能问题）来提高代码质量。

  • 确保符合组织标准、法规和团队的代码风格。

  • 通过在软件开发过程的早期发现问题来节省时间和金钱，避免问题变得更加复杂和昂贵。

  • 通过提供一个讨论代码和提问、分享想法和最佳实践以及相互学习的论坛，促进开发人员之间的协作、沟通和知识共享。

  • 通过识别任何软件维护问题并提出改进建议，确保代码的可维护性。

  • 文章 更好、更快的代码审查实用指南

  • 文章 如何通过代码审查改进代码

◇贡献指南

贡献指南对于 GitHub 上的协作项目至关重要，因为它们有助于简化协作、设定贡献期望并保持项目的质量和一致性。

◇清理 Git 历史

清理 Git 历史可以使您的提交历史更具可读性、简洁性和组织性。以下是您可能希望清理 Git 历史的一些原因：

9. 文档

一个维护良好的仓库应包含帮助他人理解项目、其背景以及如何为其做出贡献的文档。这对于围绕您的项目培养社区并使新手更容易加入至关重要。

以下是您应考虑在每个仓库中包含的一些关键文档部分：

  • README.md：项目的简要介绍，解释其内容、存在的原因以及如何开始。

  • CONTRIBUTING.md：关于其他人如何为项目做出贡献的指南，包括报告问题、提交 Pull Request 或建议新功能的步骤。

  • LICENSE：有关仓库发布许可证的信息，确保用户在使用您的代码时了解其权利和责任。

  • CHANGELOG：项目随时间变化的历史记录，突出显示重大更新、错误修复或功能添加。

  • 这些文档有助于确保贡献者的顺利入职过程，使他们能够更有效地协作并增强整体项目。

  • 文章 如何在 GitHub 仓库中管理文档：初级开发者指南

◇Markdown

Markdown 是一种简单的方式，可以在不使用 HTML 标签或其他复杂语法的情况下为文本添加格式。它易于阅读和编写，适合用于文档、README 文件等。一些基本的 GitHub Markdown 功能包括：

  • 基本语法：使用标题（# Heading）、粗体/斜体文本（粗体，斜体）和列表（- 项目）来格式化文本。
  • 链接：使用 [text](url) 或 [text][ref] 创建链接。
  • 图片：使用 [![alt-text](image-url)] 嵌入图片。

通过使用 Markdown，您可以轻松地在 GitHub 仓库中格式化文本，使其更易于阅读和理解。

◇项目 Readme

GitHub 项目 README 是一个关键文档，作为仓库的首页，提供有关项目的基本信息。它通常包括项目目的的简要描述、安装说明、使用指南和贡献程序。一个精心编写的 README 帮助访问者快速了解项目的目标、如何开始以及他们如何参与。它通常包含指示构建状态、代码覆盖率和其他指标的徽章，以及文档、问题跟踪器和社区频道的链接。通过有效传达项目的价值并指导新用户和潜在贡献者，一个好的 README 显著增强了项目在 GitHub 上的可见性、采用和协作潜力。

◇GitHub Wikis

GitHub Wikis 是直接集成到 GitHub 仓库中的协作文档空间。它们为团队提供了一个创建、编辑和组织项目相关信息（如文档、指南和常见问题解答）的平台。Wikis 支持 Markdown 格式，使得结构化内容和包含图片或链接变得容易。通过版本控制和克隆 wiki 仓库的能力，团队可以协作维护与代码一起的最新文档，增强项目理解并促进贡献者和用户之间的知识共享。

◇CITATION 文件

您可以在仓库的根目录中添加一个 CITATION.cff 文件，以告知其他人您希望他们如何引用您的工作。引用文件格式是包含人类和机器可读引用信息的纯文本。

10. 团队协作

在 GitHub 上团队协作涉及使用 Git 的分布式版本控制系统进行协作开发。团队成员可以在不同的分支上工作，创建拉取请求进行代码审查，并将更改合并到主代码库中。GitHub 的功能如问题（Issues）、项目（Projects）和讨论（Discussions）有助于沟通和项目管理。在 GitHub 上进行有效的团队协作需要清晰的沟通、遵守商定的工作流程，并正确使用 Git 命令来管理代码更改和解决冲突。这种协作方式使团队能够高效地处理复杂项目，保持代码质量，并有效跟踪进度。

GitHub 还提供了组织和团队管理界面，允许团队管理项目、成员和协作设置。

◇协作者 / 成员

在 GitHub 中，协作者和成员是指为您的仓库做出贡献或有权访问您的仓库的个人。协作者是被授予权限以贡献代码、进行更改并推送更新到您的仓库的用户，而成员是仓库的所有者，包括对其团队仓库拥有完全控制的组织所有者。成员可以是个人协作者，也可以是组织团队的一部分，根据他们在团队中的角色拥有不同级别的访问权限。

◇GitHub 组织

GitHub 组织是共享账户，为多个项目和团队提供集中管理和协作。它们提供了增强的管理控制，允许所有者创建具有特定访问权限的团队，管理成员角色，并大规模监督仓库。组织有助于更好的项目协调、资源共享和团队沟通，使其成为企业、开源项目和大规模协作的理想选择。通过团队讨论、项目板和审计日志等功能，GitHub 组织简化了工作流程管理，并促进了更结构化和安全的开发环境。

◇组织内的团队

GitHub 组织允许您在组织内创建团队，这有助于根据成员的角色和职责组织成员。

11. GitHub 项目

GitHub 项目是一个灵活的项目管理工具，直接集成到 GitHub 仓库中。它允许团队创建可定制的项目板，跟踪问题和拉取请求，并使用看板风格的列或表格视图管理工作流程。通过自动化工作流、自定义字段和各种可视化选项等功能，GitHub 项目帮助团队组织、优先排序和跟踪跨多个仓库的工作。该工具增强了协作，提高了透明度，并简化了项目管理流程，使开发人员和利益相关者更容易在项目目标和进度上保持一致。

◇项目规划

GitHub 上的项目规划是一个综合过程，利用平台的内置工具高效地组织、跟踪和管理软件开发项目。它通常涉及使用问题（Issues）进行任务跟踪、项目（Projects）进行看板风格的板、里程碑（Milestones）进行分组相关问题和拉取请求，以及标签（Labels）进行分类。这些工具与 GitHub 的协作功能（如拉取请求和代码审查）相结合，使团队能够创建结构化的工作流，设置优先级，分配任务，并在整个开发生命周期中监控进度。通过将项目管理集中在用于版本控制的同一平台上，GitHub 简化了沟通，并提高了各种规模开发团队的生产力。

◇看板

在 GitHub 上，看板提供了问题在开发过程中移动的可视化表示。

看板通常有代表不同阶段或状态的列，如“待办”、“进行中”和“已完成”。每个问题由板上的卡片表示，随着其状态的变化，可以在列之间移动。用户可以拖放问题卡片以将其从一个列移动到另一个列，反映进度或完成情况。

◇路线图

GitHub 路线图是一个功能，帮助您可视化和组织项目计划，允许您创建里程碑和目标的高级视图，并与团队成员协作规划和跟踪进度。

◇自动化

要为您的 GitHub 项目添加自动化，请使用内置工作流，这些工作流可以触发操作，例如在项目项更改时设置字段或归档符合特定条件的项，还可以根据匹配条件从仓库自动添加项。

12. Git Stash 基础

Git stash 允许您暂时保存尚未准备好提交的更改，或“暂存”。当您需要处理多个任务并希望在未完成更改的情况下切换任务时，此功能非常有用。通过使用 git stash，您可以快速暂存未提交的更改，将工作目录重置为干净状态，然后在准备好提交时应用暂存的更改。这有助于避免用不完整的工作混乱提交历史，并允许您通过分离不同任务的进度来保持仓库的整洁和组织。

要在 Git 中应用暂存，您可以使用以下命令：

  • git stash apply：此命令默认应用最顶部的暂存（最近的暂存）。它将暂存的更改合并到当前工作目录中。

  • git stash apply <stash_name>：如果您想指定特定的暂存，可以使用其名称而不是默认值。例如，如果您存储了多个暂存并希望应用较早的暂存，可以使用 <stash_name>。

  • git stash pop：此命令与 apply 类似，但它还会自动从暂存列表中删除应用的暂存。如果您需要更多控制应用哪个暂存，使用 pop 可能是更好的选择。

  • 文章 Git stash

  • 文章 使用 git stash 命令的实用指南

13. 历史记录

Git 仓库的历史记录是所有提交的时间记录，包括文件的更改、提交消息和元数据。这个历史记录以一系列快照的形式存储，每个提交代表代码库的一个新版本。

◇线性 vs 非线性

在 Git 中，线性和非线性历史记录指的是管理提交历史的不同方式。

HEAD 文件是 Git 在运行诸如 git branch <branch> 等命令时知道最后一次提交的 SHA-1 的核心。它作为一个符号引用，指向当前分支。然而，在极少数情况下，HEAD 可以包含 Git 对象的实际 SHA-1 值，例如在检出标签、提交或远程分支时，这会使你的仓库处于“分离 HEAD”状态。

◇分离 HEAD

在 Git 中，当你直接使用提交的哈希值而不是分支名称检出提交时，就会发生分离 HEAD。这会使仓库的 HEAD 指针直接指向该提交，而不是链接到特定分支。要查看分离 HEAD 中的历史记录和更改，请使用 git log 或 git show。如果你想查看当前分离 HEAD 与另一个分支之间的差异，请使用 git diff <branch>。分离 HEAD 可以是一个有用的临时状态，用于探索特定提交或功能，但在与他人共享之前，必须将这些更改合并回分支。

◇git log 选项

git log 是 Git 中的一个命令，用于显示仓库的提交历史。它提供了所有提交的详细视图，包括它们的哈希值、作者、日期和消息。

以下是一些常见的 git log 选项：

  • -2：仅显示最后两个提交。
  • -- <file-name>：显示修改了特定文件的提交。
  • --all：显示仓库中的所有分支。
  • --graph：以图形形式显示提交历史。
  • --pretty：启用干净的彩色输出。
  • --no-color：禁用彩色输出。
  • --stat：显示更改的统计摘要。
  • **-S：仅显示修改了文件的提交。

你可以组合这些选项以根据需要定制日志输出。

例如，git log -2 --graph 将以图形形式显示最后两个提交。

14. 撤销更改

如果错误或不需要的更改已提交到你的 Git 仓库，有方法可以纠正它们。两种常见的撤销更改的方法包括：

◇git revert

Git revert 是一个允许你“撤销”或还原 Git 仓库中特定提交的命令。它创建一个新的提交，反转指定提交所做的更改，从而有效地将代码回滚到之前的状态。

以下是关于 git revert 的一些关键点：

还原更改，不移动 HEAD：与 git reset 不同，git reset 可以将当前分支的 HEAD 移动到历史记录中的不同点，而 git revert 创建新的提交以反转特定提交所做的更改。 创建新提交：每次使用 git revert 时，它都会创建一个新的提交以撤销指定的更改。这意味着你的 Git 历史记录仍将包含所有以前的提交。 可以与多个提交一起使用：如果你想还原多个提交，只需用逗号分隔它们的哈希值或引用（例如分支名称）。

◇git reset

Git reset 是一个允许你通过移动其 HEAD 指针“撤销”或将当前分支重置为之前状态的命令，从而有效地丢弃自那时以来的更改。使用 git reset 时，必须指定三种模式之一：soft、hard 或 mixed。你选择的模式将决定 Git 如何与工作目录和暂存区中的文件交互。

—soft

在此模式下，仅将 HEAD 指针移动到指定的提交。工作目录中的文件不会被修改，但它们保持在你开始重置时的状态。

—hard

使用此选项，HEAD 指针和工作目录的内容都会更新以匹配指定的提交。自那时以来的任何更改都将丢失。

—mixed

使用 mixed 模式时，HEAD 指针会移动到指定的提交。然而，工作目录中的文件保持重置之前的状态。暂存区（索引）会更新以匹配指定的提交。

15. 查看差异

在 Git 中查看差异对于理解代码的更改至关重要。这在与他人协作或随着时间的推移审查自己的工作时尤为重要。差异显示了你文件的不同版本之间添加、修改或删除的确切行。此功能有助于代码审查过程、排查问题以及维护项目演变的清晰历史记录。Git 提供了各种命令和工具来查看这些差异，从而更容易有效地跟踪和管理更改。

◇提交之间

要比较 Git 历史记录中的两个特定提交，请使用 git diff 后跟提交的哈希值。这将显示这两个点之间所做的更改，包括添加、修改和删除的行。

◇分支之间

当比较两个分支之间的差异时，例如功能分支与其上游父分支，请使用 git diff <branch1>..<branch2>。此命令显示功能分支相对于父分支所做的更改。在将新功能或更改合并到主线之前，这对于审查其影响非常有用。

◇暂存的更改

要查看你已使用 git add 暂存但尚未提交的更改，请使用 git diff --cached。此命令将暂存的文件与仓库中的原始版本进行比较。这是在最终提交之前快速审查你将要提交的内容的方法。

◇未暂存的更改

对于尚未使用 git add 暂存的更改，例如未跟踪的新文件或修改的现有文件，请使用 git diff。此命令将你的工作目录（当前更改）与暂存区（已使用 git add 暂存的更改）进行比较。这是在决定是否将它们暂存以备将来提交之前审查本地修改的有用工具。

--unified 选项（或 -U）控制差异输出中显示的上下文行数。默认情况下，Git 显示每个更改周围的 3 行上下文。例如，git diff --unified=5 将显示每个更改周围的 5 行上下文，从而更容易理解周围的代码或内容。

16. 重写历史

在某些情况下，您可能需要修改或删除 Git 仓库历史中的提交。这可以通过多种方法实现：

  • git commit --amend：允许您编辑最近的提交。
  • git rebase：用一个分支替换另一个分支，保留提交历史。
  • git filter-branch：从分支中删除特定提交，而不改变原始分支。
  • git push --force：在尊重现有拉取请求的同时更新远程仓库。

在以下情况下，通常需要重写 Git 历史：

  • 修复错误：更正提交消息中的错误或拼写错误。

  • 删除敏感数据：从提交中删除机密信息，如 API 密钥或数据库凭据。

  • 简化复杂历史：重新组织分支以提高清晰度并减少复杂性。

  • 官方 Git 工具 - 重写历史

  • 文章 Git 中重写历史的方法

◇git commit —amend

git commit --amend 是一个命令，用于通过更新其消息、添加或删除文件或更改提交的元数据来修改仓库历史中的最近提交。这使您可以在提交后进行更正或改进提交描述。使用 --amend 时，Git 将用一个新的提交替换现有提交，该提交包含自上次提交以来的任何更改，从而有效地“修正”前一个提交。

◇git rebase

Git rebase 是 Git 中的一个强大命令，允许您将一个分支的更改集成到另一个分支中。与 git merge 不同，git merge 会创建一个新的提交来合并两个分支的历史，而 git rebase 将一个分支的提交移动或应用到另一个分支之上，从而有效地重写提交历史。

◇git filter-branch

您可以使用 git filter-branch 通过对每个修订应用自定义过滤器来重写 Git 修订历史。

  • 过滤器类型：您可以修改树（例如，删除文件或运行 Perl 脚本）或有关每个提交的信息。
  • 保留原始数据：该命令保留所有原始提交时间、合并信息和其他详细信息，除非另有说明。
  • 重写特定分支：仅重写命令行中提到的正引用；如果未指定过滤器，则提交将重新提交而不进行更改。

值得注意的是，有一个更简单、更安全、更强大的替代方案：git filter-repo。该工具由 Git 积极推广，提供了一种简化的修订过滤方法，使其成为重写 Git 历史的首选工具，尤其是在管理大型仓库时。

◇git push —force

git push --force 是一个命令，允许您用本地仓库中的新提交覆盖或“强制”远程仓库中的现有提交。这在某些情况下非常有用，例如当您需要用之前被拒绝的更改更新远程分支时，或者当您想要删除不再相关的提交时。然而，在使用 git push --force 时必须小心，因为它可能会覆盖其他人所做的更改，甚至您自己之前的工作。在使用此命令之前，请始终验证远程仓库上没有冲突的更改。

17. 标签

在 Git 中，标签用于标识仓库历史中的特定点，这些点被认为是重要的。此功能允许开发人员标记发布点或里程碑。

  • 标记发布点：标签通常用于标记项目的发布版本（例如，v1.0、v2.0）。

  • 标签类型：有不同类型的标签，包括轻量标签和附注标签。

  • 官方 Git 基础 - 标签

◇管理标签

在 Git 中，标签是对项目历史中特定提交的命名引用。

  • 创建标签：使用 git tag [name] [commit-hash] 创建新标签。您还可以使用 git tag -a [name] -m "[message]" [commit-hash] 创建附注标签。
  • 列出标签：运行 git tag 显示所有现有标签。
  • 删除标签：使用 git tag -d [tag-name] 删除现有标签。

标签可用于标记发布、里程碑或项目历史中的其他重要事件。

◇推送标签

在 Git 中推送标签是将本地标签与远程仓库共享的过程。Git 中的标签用于标记仓库历史中的特定点，通常用于表示发布或里程碑。

◇检出标签

Git 中的标签通常用于标记历史中的特定点，例如发布版本。检出标签意味着将您的工作目录切换到创建该标签时的仓库状态。

◇GitHub 发布

GitHub 发布是一个功能，允许开发人员打包和分发软件版本给用户。它提供了一种在仓库历史中创建标记点、附加二进制文件（如编译的可执行文件或打包代码）并包含发布说明的方法。此功能使跟踪和管理项目的不同版本、与不想从源代码构建的用户共享预编译的二进制文件以及向社区传达更改和更新变得容易。GitHub 发布与 Git 标签无缝集成，并可以作为持续集成和部署管道的一部分自动化。

18. Git 钩子

Git 钩子是在 Git 工作流程中的特定点自动运行的脚本，例如在提交、推送或从仓库拉取更改时。这些脚本可用于执行各种任务，如验证代码、格式化文件，甚至发送通知。

Git 钩子有两种类型：

◇commit-msg

commit-msg 钩子是一个客户端钩子，在您提交更改到仓库后运行。它通常用于在提交消息记录到 Git 历史之前验证或修改提交消息。

◇post-checkout

Git post-checkout 钩子是在成功执行 git checkout 操作后自动运行的脚本。这些钩子提供了一种自定义 Git 行为的方法，并在切换分支或更新工作目录时执行特定操作。post-checkout 钩子可用于更新依赖项、重新生成文件或根据新检出的分支调整项目设置等任务。它们为开发人员提供了一个强大的工具，可以自动化工作流程并维护 Git 仓库中不同分支之间的一致性。

◇post-update

Git post-update 钩子是在成功推送到仓库后自动运行的脚本。这些钩子在远程仓库上执行，通常用于服务器端任务，如更新其他服务、触发持续集成过程或通知团队成员有关更改。post-update 钩子提供了一种强大的机制，用于自动化工作流程并维护项目基础设施不同部分之间的一致性，使其成为简化开发流程和增强 Git 项目中协作的重要工具。

◇pre-commit

Git pre-commit 钩子是在创建提交之前自动运行的脚本，允许开发人员强制执行代码质量标准并在开发过程的早期发现问题。这些钩子可以执行诸如代码检查、格式化、运行测试或检查敏感信息等任务，确保只有干净且合规的代码被提交到仓库。通过拦截提交过程，pre-commit 钩子有助于维护代码一致性、减少错误并简化整体开发工作流程，使其成为强制执行最佳实践和提高项目代码质量的宝贵工具。

◇pre-push

Git pre-push 钩子是在执行推送操作之前自动运行的脚本，提供最终检查点以在更改与远程仓库共享之前验证更改。这些钩子允许开发人员执行最后一分钟的检查，例如运行测试、检查代码或验证提交消息，以确保只推送高质量且合规的代码。通过拦截推送过程，pre-push 钩子有助于维护代码完整性，防止意外推送不完整或损坏的代码，并强制执行项目特定规则，使其成为维护代码质量和分布式开发团队之间一致性的宝贵工具。

◇什么是 Git 钩子及其作用？

Git 钩子是 Git 在特定事件（如提交、推送或合并）之前或之后自动执行的可自定义脚本。这些钩子允许开发人员自动化任务、强制执行编码标准、运行测试或在 Git 工作流程中的关键点执行其他操作。通过利用 Git 钩子，团队可以增强其开发过程、维护代码质量并确保项目之间的一致性。钩子可以在本地实现或在团队成员之间共享，为简化工作流程和在整个开发生命周期中强制执行最佳实践提供了强大的机制。

◇客户端与服务器端钩子

与许多其他版本控制系统一样，Git 有一种在发生某些重要操作时触发自定义脚本的方式。这些钩子分为两组：客户端和服务器端。客户端钩子由诸如提交和合并等操作触发，而服务器端钩子则在网络操作（如接收推送的提交）时运行。

19. Git 补丁

在 Git 中，补丁是一个包含对项目代码库所做更改的文件。它本质上是一个差异（diff）文件，显示了提交或分支的两个版本之间的修改。然而，尽管在某些情况下补丁非常有用，但随着更现代和高效的代码管理方式的出现，Git 补丁的使用有所减少。

20. 子模块

在 Git 中，子模块允许你在项目中包含另一个仓库。这一功能使得可以将外部依赖作为主项目的一部分进行管理。

  • 包含外部仓库：子模块可用于在项目中包含其他 Git 仓库。

  • 管理依赖：它们提供了一种管理和跟踪外部依赖变化的方式。

  • 官方 Git 子模块

  • 文章 Git 子模块教程

◇什么是子模块以及为什么要使用？

Git 子模块是一个允许你在一个 Git 仓库中包含另一个 Git 仓库的功能。它们对于管理外部依赖或跨项目共享组件非常有用。

关键点

  1. 独立的仓库，具有独立的历史记录
  2. 父仓库跟踪特定的子模块提交
  3. 支持代码重用和模块化项目结构
  4. 帮助管理依赖并保持主仓库的专注
  5. 促进复杂项目的协作

好处

  • 包含第三方库
  • 共享通用代码
  • 管理多组件项目
  • 保持主仓库轻量级

注意：虽然功能强大，但子模块可能会增加工作流程的复杂性，因此在实施之前需要仔细考虑。

◇添加/更新

要向仓库添加子模块，请使用 git submodule add https://github.com/user/submodule-repo.git，这是指定子模块仓库 URL 的典型格式。这将为子模块创建一个新文件夹，并在指定的修订版本中检出它。要将现有子模块更新到其最新提交，请运行 git submodule update。如果你想在保持子模块历史记录完整的同时从上游拉取更改，请使用 git submodule sync，然后运行 git submodule update。

21. GitHub CLI

GitHub CLI 是一个命令行界面工具，它将 GitHub 功能带到你的终端。它允许开发者直接从命令行与 GitHub 交互，使他们能够管理仓库、创建问题、拉取请求以及执行各种 GitHub 操作，而无需离开终端环境。这个强大的工具简化了工作流程，提高了生产力，并提供了本地开发和 GitHub 协作功能之间的无缝集成，使开发者更容易将 GitHub 融入他们的日常编码工作中。

◇安装和设置

GitHub CLI 可以安装在 Windows、macOS 和 Linux 操作系统上。安装选项包括直接从发布页面下载二进制文件或使用包管理器（如 homebrew、pip 等）。

安装完成后，设置 GitHub CLI 通常涉及通过运行 gh auth login 在你的终端中与你的 GitHub 账户进行身份验证。此步骤对于将你的 GitHub 凭证链接到 CLI 至关重要，允许你与你的仓库交互并执行各种操作。

◇仓库管理

使用 GitHub CLI 进行仓库管理可以简化任务并提高工作效率。你可以使用以下命令来管理仓库：

◇问题管理

GitHub CLI 提供了一系列功能来管理仓库中的问题。以下是一些你可以执行的关键操作：

  • 列出问题：运行 gh issue list 以查看所有打开和关闭问题的列表。

  • 创建问题：使用 gh issue create --title "问题标题" --body "问题内容" 创建一个具有指定标题和内容的新问题。

  • 分配问题：运行 gh issue assign <问题编号> <用户名> 将问题分配给特定用户。

  • 标记问题：使用 gh issue label <问题编号> <标签名称> 为现有问题添加标签。

  • 关闭问题：运行 gh issue close <问题编号> 将问题标记为已关闭。

  • 官方 gh issue

  • 视频 使用 GitHub CLI 从命令行管理 GitHub 问题

◇拉取请求

你可以使用以下命令来管理拉取请求：

  • gh pr create：创建一个新的拉取请求。

  • gh pr merge：将拉取请求合并到目标分支。

  • gh pr list：列出仓库的所有拉取请求。

  • gh pr view：查看特定拉取请求的详细信息。

  • 官方 gh pr

  • 视频 使用 GitHub CLI 进行命令行拉取请求管理

◇在自动化中使用

GitHub CLI 是一个强大的工具，可以直接从命令行自动化与 GitHub 相关的任务。它使开发者能够简化工作流程，并将 GitHub 流程集成到脚本和自动化系统中。

自动化中的关键用途：

  1. CI/CD：自动化 PR 创建、审查、合并和发布管理
  2. 问题和项目管理：创建、更新和关闭问题；管理项目板
  3. 仓库管理：克隆仓库、创建分支、管理设置和协作者
  4. GitHub Actions 集成：触发和监控工作流，管理密钥
  5. 脚本和批量操作：跨多个仓库执行批量操作

要在自动化中使用 GitHub CLI：

  1. 安装 GitHub CLI
  2. 与你的 GitHub 账户进行身份验证
  3. 学习基本命令和语法
  4. 将 CLI 命令集成到脚本或自动化工具中

22. GitHub Actions

GitHub Actions 是一个非常有用的自动化工具，允许开发者直接在 GitHub 上自动化软件开发生命周期中的任务。

学习 GitHub Actions 的最佳方式之一是通过 Microsoft Learn 提供的课程。该课程结构良好，提供了简洁易懂的实用示例。

◇这些是什么？

GitHub Actions 是 GitHub 提供的一个强大的自动化和持续集成/持续部署（CI/CD）平台。它允许开发者创建自定义工作流，直接从他们的 GitHub 仓库自动构建、测试和部署代码。这些工作流由特定事件触发，例如推送请求、拉取请求或计划任务。GitHub Actions 使团队能够通过自动化重复任务并在开发管道中无缝集成各种工具和服务，从而简化开发流程、提高代码质量并加速软件交付。

◇使用案例

GitHub Actions 为您的开发工作流提供了广泛的自动化可能性。以下是一些常见的使用案例：

  1. 持续集成（CI）：在每次推送或拉取请求时自动构建和测试代码。
  2. 持续部署（CD）：在成功构建后自动将应用程序部署到各种环境。
  3. 代码质量检查：自动运行代码格式化工具、静态分析工具等。
  4. 依赖更新：为过时的依赖项自动创建拉取请求。
  5. 问题和 PR 管理：根据特定条件自动标记、分配或关闭问题和拉取请求。
  6. 计划任务：运行定期维护任务、备份或数据处理作业。
  7. 安全扫描：对代码库和依赖项执行自动安全检查。
  8. 文档生成：自动生成并发布项目文档。
  9. 跨平台测试：同时在多个操作系统和环境中测试代码。
  10. 发布管理：自动化创建发布说明和新版本的上传。

◇YAML 语法

YAML（YAML Ain’t Markup Language）是一种人类可读的数据序列化标准，适用于所有编程语言。它设计为易于人类阅读，同时也能被机器解析。YAML 的主要特点包括：

  1. 简单性：YAML 使用极简的语法，依赖缩进和空白符。
  2. 多功能性：它可以表示各种数据类型，包括标量、列表和关联数组。
  3. 可读性：其清晰简洁的格式使其易于人类和机器理解。
  4. 语言无关性：YAML 可以与任何具有 YAML 解析器的编程语言一起使用。

YAML 通常用于：

  • 配置文件：许多应用程序和工具使用 YAML 作为其配置设置。
  • 数据交换：它是 XML 或 JSON 的轻量级替代方案，用于系统之间的数据传输。
  • 数据存储：YAML 可以用于以人类可读的格式存储结构化数据。
  • DevOps 和 CI/CD：它广泛用于 Docker、Kubernetes 和各种 CI/CD 平台中，用于定义工作流和配置。

理解 YAML 语法对于使用现代开发工具至关重要，尤其是在 DevOps、云计算和容器化领域。

◇工作流触发器

工作流触发器是启动 GitHub Actions 工作流的事件。它们可以是计划的、由代码更改触发的或手动启动的。这允许根据特定条件自动化任务。

◇计划工作流

GitHub Actions 允许您安排工作流在特定时间或间隔运行。您可以设置工作流在预定时间自动运行，例如每天或每周。

◇工作流运行器

工作流运行器是执行 GitHub Actions 工作流的环境。它们托管在 GitHub 托管的虚拟机（GHVM）或自托管运行器上。每个运行器都有特定的配置和功能，具体取决于其类型。

◇工作流上下文

GitHub Actions 中的工作流上下文指的是工作流可用的环境和变量。它包括有关工作流执行的信息，例如触发它的事件、仓库和工作流本身。

◇密钥和环境变量

GitHub 提供了安全存储和管理敏感数据的功能，例如密钥和环境变量。

◇缓存依赖项

GitHub Actions 提供了缓存功能，允许您在工作流之间存储和重用依赖项，从而减少运行操作所需的时间。通过缓存依赖项，您可以：

  • 重用编译后的代码
  • 存储数据库连接
  • 减少网络流量

强烈建议不要在缓存中存储任何敏感信息。例如，敏感信息可以包括存储在缓存路径文件中的访问令牌或登录凭据。

◇存储构建产物

GitHub 提供了存储构建产物的功能，允许您将构建输出或其他文件作为工作流的一部分上传。

  • 构建产物：这些是由作业生成的文件，例如编译后的二进制文件、测试报告或日志。它们可用于验证构建或部署的结果。

  • 可引用存储：构建产物以可引用的方式存储，便于在未来的构建中访问和使用。

  • 官方 存储和共享工作流中的数据

◇工作流状态

GitHub Actions 中的工作流状态指的是工作流运行的当前状态。它可以是以下之一：

◇市场 Actions

GitHub 市场提供了广泛的预构建 Actions，可用于自动化仓库中的任务和工作流。

  • 自动化任务：使用市场 Actions 自动化测试、部署或安全等任务。
  • 自定义工作流：使用市场 Actions 创建自定义工作流，以根据特定需求定制构建过程。
  • 简化开发：通过自动化重复任务，开发者可以专注于代码质量和协作。

这些 Actions 由 GitHub 社区创建，可以轻松添加到您的工作流中，以提高生产力和效率。

23. 高级 Git 主题

◇Git Reflog

Git reflog 是 Git 中的一个强大工具，它记录了仓库中分支和提交的所有更改，包括那些不属于常规提交历史的操作，例如重置分支或检出提交。它特别适用于恢复丢失的提交或理解仓库中的更改历史，即使这些更改未反映在正常的提交历史中。Reflog 代表“引用日志”，它记录了仓库中分支或其他引用（如 HEAD）的尖端何时被更新。

◇Git Bisect

Git Bisect 是一个交互式工具，用于识别项目历史中哪个提交引入了错误或回归。你首先需要确定两个提交：一个是没有问题的提交（“好”提交），另一个是有问题的提交（“坏”提交）。然后运行 git bisect start，接着使用 git bisect good 标记好提交，使用 git bisect bad 标记坏提交。Git Bisect 将引导你进行二分查找过程，要求你测试当前范围的中间点，直到找到引入错误或回归的确切提交。

◇Git Worktree

Git worktree 允许你为单个仓库创建多个工作目录，每个工作目录都有自己的检出和索引。与常规检出不同，常规检出会为特定分支创建一个新的工作目录并更新 IDE 的配置设置，而 Git worktree 不需要你使用 git checkout 在分支之间切换。这意味着你可以同时检出多个分支，而不会相互影响或需要更改 IDE 配置。通过为每个分支创建单独的工作树，你可以独立暂存更改，并维护不同的工作目录，而不会影响主仓库或其工作目录。

◇Git Attributes

Git 属性是存储在 .gitattributes 文件中的设置，控制 Git 如何处理仓库中的文件。它们可以影响过滤（例如忽略特定文件）、转换（在 Git 操作期间格式化或转换文件）和格式化（应用一致的样式）。这些设置可以应用于特定文件类型（如 *.txt）或基于内容模式过滤文件。属性还定义了 smudge 模式（突出显示差异）和忽略模式，帮助通过自动为某些文件类型应用预期设置来维护干净的仓库。

◇Git LFS

Git 大文件存储（LFS）是一个扩展，通过跟踪元数据而不是存储整个文件来帮助管理大文件。它允许将图像、视频、音频文件等二进制资源与常规 Git 仓库分开存储和跟踪。通过仅在 Git 仓库中存储元数据，你可以提高克隆和推送速度，减少存储使用。这种方法特别适用于媒体仓库、大型数据集存储和游戏开发中的二进制资源管理。请注意，Git LFS 需要一个单独的服务器或存储系统来存储实际文件内容。

24. Webhooks

GitHub Webhooks 允许开发者实时接收其仓库中发生的事件通知，例如提交、拉取请求和问题。这些 webhook 使用户能够自动化任务、与其他服务集成并构建自定义工作流。

25. GitHub API

GitHub API 是一个强大的工具，允许开发者以编程方式与 GitHub 平台交互。它通过 REST 和 GraphQL 接口提供对 GitHub 各种功能的访问，例如用户数据、仓库信息和提交历史。API 支持身份验证、实施速率限制并提供用于实时通知的 webhook，使开发者能够自动化任务、创建自定义集成并构建利用 GitHub 功能的应用程序。

◇REST API

GitHub REST API 是一组 API，提供对 GitHub 各种功能的访问，例如用户数据、仓库信息和提交历史。它允许开发者以编程方式与 GitHub 平台交互。

◇GraphQL API

GitHub GraphQL API 是一组 API，提供对 GitHub 各种功能的访问，例如用户数据、仓库信息和提交历史。它允许开发者使用 GraphQL 查询以编程方式与 GitHub 平台交互。

26. 创建应用

GitHub 应用是一种以编程方式与 GitHub 平台集成的方式，使用 REST API 或 GraphQL API。它们允许开发者创建可以自动化任务、提供实时通知并构建自定义工作流的自定义集成。

◇GitHub Apps

GitHub 应用是一种以编程方式与 GitHub 平台集成的方式，使用 REST API 或 GraphQL API。它允许开发者创建可以自动化任务、提供实时通知并构建自定义工作流的自定义集成。

◇OAuth Apps

GitHub OAuth 应用允许开发者使用 OAuth 2.0 身份验证与 GitHub 集成。它们支持基于令牌的安全访问特定 GitHub 资源，如仓库、问题和拉取请求。OAuth 应用可以自动化任务、个性化交互并通过 webhook 提供实时通知，同时允许用户仅批准必要的权限而无需共享其凭据。

27. GitHub Pages

GitHub Pages 是一项功能，允许用户直接从其 GitHub 仓库托管和发布网页内容。它提供了一种简单的方法来创建和部署网站、博客或项目，而无需手动配置或维护。用户可以上传自定义主题、添加插件并使用各种工具自定义其页面。

◇部署静态网站

在 GitHub Pages 上部署静态网站涉及上传和服务预先生成的网站内容，而无需动态功能。这种方法允许快速部署、低维护和提高安全性。

◇自定义域名

在 GitHub Pages 上，用户可以通过将自定义域名连接到其仓库来自定义其站点的 URL。此功能允许用户使用自己的域名而不是默认的 GitHub.io 子域名，使其站点看起来更专业和个性化。

◇静态站点生成器

GitHub 提供了一组静态站点生成器（SSG），允许用户直接从其 GitHub 仓库创建和部署网站。这些 SSG 包括 Jekyll、Hugo 和 Middleman 等。它们提供了一种简单的方法来构建网站，而无需手动配置或维护。

28. GitHub Gists

GitHub Gist 是一个可以与他人共享的小代码或文本片段。它是一种无需创建完整仓库即可共享代码、配置文件或其他文本片段的简单方法。Gist 适用于共享示例、演示或教程，也可以作为更大项目的起点。每个 gist 都有一个唯一的 URL，可以与他人共享，允许他们查看和编辑内容。Gist 支持各种文件类型，包括代码文件、文本文件甚至图像。它们还提供语法高亮、行号和提交历史等功能。

29. GitHub Packages

GitHub Packages 是一个包仓库服务，允许开发者存储和共享包、容器和其他软件工件。它提供了一个中心位置，用于与团队、组织或更广泛的开发者社区共享包。GitHub Packages 支持流行的包管理器，如 npm、Maven 和 Gradle，以及容器注册表，如 Docker Hub。此功能使包能够无缝集成到开发工作流中，从而更容易在项目内部和跨项目共享依赖项、库和框架。通过使用 GitHub Packages，开发者可以简化依赖管理、减少错误并提高整体协作。

30. GitHub Codespaces

GitHub Codespaces 是一个基于云的开发环境，允许开发者创建、访问和使用预配置的、随时可用的编码环境。它提供了一种无缝的方式来开发、测试和调试应用程序，无需本地设置和配置。使用 GitHub Codespaces，用户只需点击几下即可启动一个具有所需配置、工具和依赖项的新环境。此功能通过为每个项目提供即时访问定制的编码环境，简化了开发工作流，减少了摩擦并提高了生产力。

31. GitHub 安全

GitHub 安全是一套功能和工具，帮助开发者识别、修复和预防代码中的安全漏洞。它通过与开发者工作流程的集成，提供了一种全面的安全编码实践方法。GitHub 安全的主要组件包括：代码扫描，使用 AI 驱动的分析来检测潜在漏洞；Dependabot，自动化依赖更新以防止通过易受攻击的依赖项进行攻击；秘密扫描，检测并标记如 API 密钥或凭证等秘密；以及 GitHub 高级安全，为大型团队提供更高级的安全功能。通过使用这些工具，开发者可以确保代码的安全性，并在潜在问题变得严重之前识别它们。

32. GitHub 赞助者

GitHub 赞助者是一种支持和资助 GitHub 上开源项目的方式。它允许公共仓库的维护者从重视他们工作的用户那里获得财务支持。赞助者可以贡献资金以帮助支付费用、开发时间或其他与项目相关的成本。作为回报，赞助者会在仓库的 README 文件和项目网站上被认可为支持者。此功能促进了开源社区内的透明度、责任感和赞赏，使维护者更容易专注于他们的项目。

33. GitHub Copilot

GitHub Copilot 是一个 AI 驱动的代码补全工具，帮助开发者更快地编写代码并减少错误。它结合了机器学习算法和对 GitHub 庞大开源代码库的访问，为编码任务提供上下文感知的建议。Copilot 可以根据正在编写的代码的上下文生成整个函数、方法甚至整个类。此功能旨在通过提供即时且相关的建议来减少编码时间，使开发者能够更多地关注高级设计和问题解决。

34. GitHub 模型

GitHub 模型是一个允许开发者搜索、探索和使用来自各种来源的预训练 AI 模型的功能。该平台提供了一种发现和实验这些模型的方式，使得将 AI 功能集成到软件项目中变得更加容易。通过使用 GitHub 模型，开发者可以快速找到并尝试不同的模型，而无需从头开始训练它们。

35. GitHub 市场

GitHub 市场是一个平台，允许开发者在其 GitHub 环境中直接发现、安装和管理第三方工具和服务。这些工具可以提供一系列功能，如代码分析、项目管理或协作，使开发者能够更高效地工作。通过使用 GitHub 市场，开发者可以简化工作流程，减少摩擦，并专注于编写代码。

36. GitHub 教育计划

GitHub 教育计划是一项为学生、教师和研究人员提供免费或折扣访问 GitHub 开发者工具、服务和资源的计划。该计划旨在支持软件开发和研究的教学，通过让学生和教育者更容易在 GitHub 上学习、协作和构建项目。通过使用 GitHub 教育计划，学生可以获得实际编码挑战的实践经验，而教育者则可以创建一个更具吸引力和互动性的学习环境。

◇学生开发者包

GitHub 学生开发者包是通过 GitHub 教育计划向学生免费或以折扣价提供的开发者工具和资源集合。该包包括对 GitHub、GitHub Desktop、GitHub Classroom、GitHub 学生开发者工具包等的访问权限。通过使用学生开发者包，学生可以获得专业开发者工具的实践经验，同时还能访问广泛的教育资源。

◇GitHub Classroom

GitHub Classroom 是 GitHub 中的一个集成功能，允许教育者直接向学生创建和分配作业、项目或测验。该功能通过让教师在一个地方轻松分享代码、提供反馈和跟踪学生进度，简化了教学过程。通过使用 GitHub Classroom，教师可以专注于高层次的指导和学生的参与，同时促进协作和实践学习体验。

◇校园计划

GitHub 校园计划为希望充分利用 GitHub 的学校免费提供 GitHub Enterprise Cloud 和 GitHub Enterprise Server。该计划提供了一套全面的开发者工具，以及帮助学生和教育者构建项目、协作和培养软件开发技能的资源和支持。