Git面试题(1)

在开始使用 Git 之前，你需要先在你的系统上安装 Git。不同操作系统的安装指南可在 Git 官网找到：

• 对于 Linux：
  通常可以通过包管理器安装，例如在 Ubuntu 上可以使用以下命令：

sudo apt-get update
sudo apt-get install git

• 对于 macOS：
  可以通过 Homebrew（如果安装了的话）进行安装：

brew install git

或者可以从官方网站下载安装程序。

• 对于 Windows：
  可以从 Git 官方网站下载 Git for Windows（也称为 Git Bash）安装程序。

2. 配置用户信息

安装 Git 后，第一件事通常是设置你的用户姓名和电子邮件地址。这是因为 Git 会在每次提交时使用这些信息：

git config --global user.name "Your Name"
git config --global user.email "youremail@domain.com"

3. 选择编辑器

设置 Git 默认的文本编辑器，该编辑器用于打开提交信息编辑界面等：

git config --global core.editor nano

或者，你也可以设置为 vim、emacs 或任何你喜欢的编辑器。

4. 检查配置

你可以通过以下命令查看所有配置信息，包括你之前设置的用户名称和电子邮件：

git config --list

5. 设置 SSH 公钥/私钥对

用于Git服务（如GitHub、Bitbucket、GitLab等）的SSH认证：

• 使用 ssh-keygen 命令生成一个新的SSH密钥对。
• 将公钥（如 ~/.ssh/id_rsa.pub）添加到 Git 服务器的 SSH 密钥列表中。
• 确保你的本地 Git 客户端正在使用正确的私钥进行连接。

6. 配置命令别名

为了简化命令输入，你可以为常用的 Git 命令设置别名：

git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.st status

7. 忽略文件配置

创建一个全局的 .gitignore 文件，以避免将临时文件、系统文件或敏感信息加入版本控制：

• 创建 .gitignore 文件并指定要忽略的文件模式。
• 设置Git读取全局.gitignore配置：

git config --global core.excludesfile ~/.gitignore_global

8. 配置行结束符

特别在混合环境（Windows 和 Linux/macOS）开发时，需要配置行末尾字符的行为：

• 对于 Windows：

git config --global core.autocrlf true

• 对于Linux和macOS：

git config --global core.autocrlf input

这个配置有助于保持在仓库中行结束符的一致性并避免在不同操作系统间提交不必要的更改。

配置好 Git 环境之后，你就可以开始使用 Git 进行版本控制了。这些配置将会帮助你减少操作中的麻烦并提高工作效率。

2.2 描述 Git 初始化和克隆仓库的过程

Git 是一个流行的分布式版本控制系统，用于跟踪代码变更和协作。初始化和克隆仓库是开始使用 Git 的基本步骤。

Git 初始化

初始化一个新的 Git 仓库是创建新项目时的第一步。它将在你的项目目录中创建一个新的 .git 子目录，该子目录包含所有的仓库元数据。

1. 在本地创建一个新目录:
   首先，创建一个新目录作为项目的根目录。

mkdir new-project
cd new-project

2. 运行 git init:
   然后，在这个目录中使用 git init 命令来初始化一个新的 Git 仓库。

git init

这会在当前目录创建一个名为 .git 的隐藏目录，包含初始化的 Git 仓库的所有信息。
3. 添加文件并进行首次提交:
你可以开始在项目目录中添加文件，并使用 git add 和 git commit 来进行首次提交。

git add .
git commit -m "Initial commit"

Git 克隆仓库

克隆仓库是指从另一个 Git 仓库中复制项目的过程。这通常用于获取远程 Git 服务器（例如 GitHub、GitLab、Bitbucket 等）上的一个已存在的仓库副本。

1. 运行 git clone:
   使用 git clone 命令克隆一个远程仓库。

git clone <repository-url>

这里的 <repository-url> 是远程 Git 仓库的 URL。这个命令会在本地创建一个与远程仓库同名的目录，并初始化 .git 子目录，复制仓库数据，检出一个工作副本。
2. 克隆到指定的新目录:
你也可以指定一个新的目录名称作为克隆的目标。

git clone <repository-url> new-directory

上述命令会克隆仓库到 new-directory 文件夹中。

初始化和克隆是 Git 工作流的基本操作。初始化用于开始新的项目，而克隆用于参与已有的项目，在本地创建项目的工作副本，使得可以进行后续改动和贡献。无论是创建新项目还是加入已有项目，掌握这些操作对使用 Git 协作至关重要。

2.3 解释 Git 本地操作：添加、提交、拉取、推送

Git 是一个强大的分布式版本控制系统，它支持快速和高效的本地和远程操作。以下是 Git 中一些常用的本地操作和命令：

添加（Add）

“添加”操作是指将工作目录中的更改添加到暂存区（staging area）。这意味着你正在将文件的当前更改标记为准备好的，这些更改将在下一次提交时被记录。

git add <file>  # 添加指定文件到暂存区
git add .       # 添加当前目录的所有更改到暂存区
git add -A      # 添加所有更改到暂存区，包括新文件和删除的文件

提交（Commit）

“提交”是将暂存区的更改记录到本地仓库的历史记录中。提交会生成一个新的版本快照，并允许你为更改编写说明性的信息。

git commit -m "commit message"  # 提交暂存区的更改到本地仓库，并附加提交信息

拉取（Pull）

“拉取”操作是指从远程仓库获取最新版本并合并到本地仓库。如果自上次同步以来远程仓库有新的提交，这个操作将应用这些更改。

git pull [remote] [branch]  # 从指定远程仓库的指定分支拉取更改并合并到当前分支

推送（Push）

“推送”是指将本地仓库的提交发送到远程仓库。如果你有权限，此操作会更新远程仓库的状态。

git push [remote] [branch]  # 推送本地分支的更改到指定远程仓库的指定分支

注意事项

• 先拉取再推送：在推送本地更改到远程之前，习惯上先执行 git pull 来确保没有合并冲突。
• 避免“强制推送”：git push --force 可能会覆盖远程仓库的历史记录。应仅在完全理解其后果时才使用。
• 频繁提交小变更：频繁提交小的更改可以帮助追踪进度并简化合并的工作。
• 清晰的提交信息：为每个提交写上清晰的信息可以帮助团队理解更改历史。

Git 的本地操作是围绕工作流的核心，熟练使用这些命令有助于提高开发效率和协作能力。确保频繁地与远程仓库同步，使历史记录保持一致和准确。

3 Git 分支管理

3.1 讲述如何创建、合并和删除分支

在 Git 中，分支是独立进行特定工作的线索，类似于项目的副本，可以自由切换和修改代码，而不影响其他分支。下面是如何在 Git 中创建、合并和删除分支的详细步骤：

创建分支

使用 git branch 命令创建新的分支：

git branch <branch-name>

例如，要创建一个名为 feature_x 的新分支，可以执行：

git branch feature_x

切换分支

使用 git checkout 命令切换到新创建的分支：

git checkout <branch-name>

若要切换到 feature_x 分支，执行：

git checkout feature_x

也可以一步创建并切换分支：

git checkout -b <branch-name>

合并分支

将分支的更改合并回主分支（例如 main 或 master），需要先切换到主分支，然后使用 git merge 命令：

git checkout main
git merge <branch-name>

例如，将 feature_x 分支合并进 main 分支，执行：

git checkout main
git merge feature_x

在合并过程中可能出现代码冲突，这时需要手动解决这些冲突，然后提交解决后的更改。

删除分支

当一个分支的工作完成并且已经合并（或不再需要它），可以使用 git branch -d 命令删除分支：

git branch -d <branch-name>

若要强制删除一个未合并的分支，可以使用 -D 选项：

git branch -D <branch-name>

例如，要删除 feature_x 分支，执行：

git branch -d feature_x

总结

在实际工作中，合理使用分支对于管理复杂的代码变更是非常重要的。在长期项目中，通常会有多个活动分支，例如为新功能、错误修复或实验品。创建、合并和删除分支是 Git 日常使用中的基础操作，了解它们对于高效工作和代码协作至关重要。此外，在删除分支之前，确保该分支的所有有价值的工作都已经合并或者确实不需要了，以避免丢失工作内容。

3.2 描述 Git 分支合并的策略和处理冲突的方法

Git 分支合并是将一个分支的修改合并进另一个分支的过程。合并是代码协作中常见的操作，尤其是在工作于特性分支时。针对合并操作的不同情况，Git 提供了不同的合并策略。同时，处理合并中出现的冲突也是一个重要的技能。

合并策略（Merge Strategies）

• Fast-Forward Merge：
  如果目标分支（通常是 main 或 master）自从创立来源分支（比如，特性分支）之后没有发生变化，Git 可以执行快进合并。快进合并只是简单地将目标分支的头指针移到来源分支的最新提交。
• 三方合并（Three-way Merge）:
  当两个分支都有新的提交时，Git 会进行三方合并。Git 会用两个分支的末端提交和它们的共同祖先提交来创建一个新的合并提交。

处理合并冲突（Merge Conflicts）

1. 冲突发生时:

   • Git 会在合并时通知你哪些文件存在冲突。
   • 无法自动解决的修改会被标记，并且 Git 会暂停合并过程让你手动解决冲突。

2. 冲突标识:

   • 在存在冲突的文件中，Git 用特定的标签标记了冲突部分，如 <<<<<<<、=======、>>>>>>>。
   • 这些标签分隔了不同分支上的相应代码块。

3. 解决冲突:

   • 手动编辑文件，解决所有的冲突部分。这可能涉及决定保留哪部分代码或如何整合两段代码。
   • 在编合两个分支的代码时，确保保留意图而不仅仅是代码本身。
   • 使用 Git 合并工具 （如 git mergetool）可以更方便地处理复杂的冲突。

4. 完成合并:

   • 解决完冲突后，使用 git add 命令将这些文件标记为冲突解决。
   • 运行 git commit 命令完成合并。这一动作通常会打开一个文本编辑器，允许你编辑合并提交的信息。
   • Git 通常会自动将合并冲突的信息加入到提交信息中。

5. 测试合并结果:

   • 在确定提交前，对变动的代码进行编译和测试，确保合并没有引入任何错误。

6. 推送合并结果:

   • 当本地合并完成并通过所有测试后，就可以将改变推送到远程仓库。

合理使用 Git 分支和合并策略可以提高团队的开发效率并减少合并冲突。无论何时，当处理冲突时都要确保与其他涉及的团队成员进行沟通，以保持代码的一致性和功能的完整性。

3.3 解释分支与标签的区别

在 Git 版本控制系统中，分支（Branch）和标签（Tag）都是指向提交（Commit）对象的引用，但它们的用途和特性有所不同。

分支（Branch）

分支是一个动态的引用，它指向一系列提交的最新一次提交。它允许开发者在隔离的环境中并行地开发功能、修复错误或尝试新想法，而不影响其他分支上的工作。分支通常用于开发特性、处理bug、准备发布等。创建新的分支不会复制代码，而是创建一个轻量级的可移动的指针。

特点：

• 动态变化：分支的指向随着新的提交而变化。
• 并行开发：允许并行开发不同的特性或功能。

标签（Tag）

标签是一个静态的引用，用来标记项目中的特定点，通常用于版本发布（如 v1.0.0、v1.1.0 等）。一旦创建，标签指向某个特定的提交且永远不会改变。标签可以是轻量级的，也可以是带有额外信息的注解标签（annotated tag），其中可能包括作者、日期、消息和可选的 GPG 签名。

特点：

• 静态不变：标签指向的提交对象是固定的。
• 里程碑记录：通常用于版本的重要状态，如发布和里程碑。

分支 vs 标签

分支（Branch）	标签（Tag）
动态更新引用的提交。	固定引用特定提交。
可用于活跃开发和合并。	标记发布或重要状态。
长期存在于开发周期中。	通常不在开发中变化。
可以创建、移动和删除。	创建后一般是不变的。
例如：feature/login	例如：v1.0.0

使用场景

• 分支：当你想要开发一个新功能、修复Bug或者为新版本准备的时候，你就会创建一个新分支。在新分支上的提交不会影响 main 或其他分支。
• 标签：当你完成一段时间的开发，并且准备发布新版本的时候，你会在最新的提交上创建一个标签，表示这一版本已经就绪。

在实践中，分支用于在代码演进中提供灵活性，而标签用于创建永久性的历史快照。遵循聪明的分支策略和合理地使用标签能够帮助团队追踪项目的历史，管理部署和维护一个清晰的开发历程。

4 Git 高级话题

4.1 讨论 Git 的存储模型和对象类型

Git 的存储模型基于一套简单的核心概念和对象类型，这些设计使得 Git 成为一个非常强大和灵活的分布式版本控制系统。以下是 Git 存储模型的核心组成部分：

Git对象

Git 使用内容寻址文件系统来存储仓库的所有内容。这意味着文件被其内容的哈希值引用，而不是文件名。Git 的对象存储包括以下几种基本对象类型：

1. Blob（二进制大对象）

   • 用于存储文件数据。每个 blob 对象对应文件仓库中的一个文件。
   • blob 只包含文件的内容，不包含文件名或路径信息。

2. Tree（树对象）

   • 用于代表目录结构。一个 tree 对象由多个 tree 对象和 blob 对象组成。
   • 每个 tree 对象可以包含对其他 tree 对象的引用（子目录）以及 blob 对象（文件）。

3. Commit（提交对象）

   • 用来记录仓库的变更。它包含了指向树对象的引用、上一（或多个）提交的引用、作者、提交者、提交信息等元数据。
   • 每个 commit 对象代表仓库历史中的一个点。

4. Tag（标签对象）

   • 用于标记特定的提交历史。标签可以是轻量级的（仅仅是提交的引用）或者附注型的（含有标签的信息，如标签的创建者、日期、消息等）。
   • 常用于发布版本或者标记重要的里程碑。

引用和 HEAD

• 引用（Refs）

  • 弔用是指向 Git 对象的指针。它们包括分支（heads）、远程跟踪分支（refs/remotes）和标签（refs/tags）等。
  • 引用通常位于 .git/refs 目录下，并且包含了一个对象的 SHA-1 哈希值。

• HEAD

  • 是一个特殊的引用，指向当前分支的最新提交，它决定了工作目录和暂存区域的状态。
  • .git/HEAD 文件包含指向当前检出分支的引用。

暂存区和索引

• 暂存区域（Staging Area）

  • 暂存区域，通常称为“索引（index）”，是一个存放即将被提交至下一个 commit 的文件变更的区域。
  • 当执行 git add 命令时，变更被添加到暂存区。

• 索引（Index）

  • .git/index 文件维护了一个有关暂存区对象的结构化文件列表，这个文件会在提交时用于构建 commit 对象。

Git 存储的性质

• 完整性：

  • Git 的内容寻址存储机制确保数据的完整性。文件的内容被 SHA-1 散列值唯一标识，任何更改都会改变其哈希值。

• 追踪历史：

  • Commit 对象和 Tree 对象的链式引用形成了项目的历史记录。

• 优化存储：

  • Git 使用增量存储和数据压缩来优化性能，例如仅存储文件的增量变更（称为 delta 压缩）。

Git 的设计哲学是在其存储模型的基础上提供最大限度的灵活性。虽然这个模型背后的概念很简单，但能够支持复杂的版本控制需求，包括分支、合并、重写历史以及远程协作等。

4.2 解释 GitHooks（钩子）的概念和用法

Git 钩子（Git Hooks）是在 Git 仓库中发生特定事件时触发的脚本，它们位于仓库的 .git/hooks 目录下。这些钩子脚本可以用于自动化和定制 Git 工作流程，比如提交前检查、提交信息验证、自动化测试、以及其他连续集成任务。

Git 钩子可以分为两类：客户端钩子和服务器端钩子。

客户端钩子

这些钩子在本地操作时触发，比如提交和合并。一些常见的客户端钩子包括：

• pre-commit：在提交信息输入前触发，通常用于代码检查、测试、linting。
• commit-msg：在提交信息编辑器显示后、提交之前触发，用于检查提交信息格式。
• post-commit：在提交完成后触发，可以用于通知或其他后续操作。
• pre-push：在 git push 命令执行前触发，通常用于运行测试或检查。

服务器端钩子

这些钩子在推送到远程仓库时触发，比如在进行网络操作时。常见的服务器端钩子有：

• pre-receive：在服务器接收推送变更前触发，可以用来强制执行项目政策。
• update：在服务器上每一个分支更新后触发，它可以对即将进入仓库的提交进行更细粒度的控制。
• post-receive：在推送到仓库后触发，常用于通知构建服务器、部署应用或发出通知。

使用 Git 钩子

默认情况下，.git/hooks 目录包含一些示例脚本文件，它们的扩展名通常是 .sample。要启用某个钩子，你需要：

1. 将相应的示例文件重命名，去除 .sample 扩展名。
2. 确保脚本文件有执行权限。
3. 编辑脚本文件，加入你想要执行的操作。

例如，要激活一个 pre-commit 钩子：

cd .git/hooks
mv pre-commit.sample pre-commit
chmod +x pre-commit

编辑 pre-commit 文件，加入你需要执行的 Shell 命令，比如代码静态分析工具：

# 伪代码
if ! run_code_analysis_tool; then
  echo "Code analysis failed"
  exit 1
fi

自定义钩子

尽管 Git 钩子功能强大，但一个常见的问题是 Git 钩子不会随着仓库一同被版本控制。因此，你可能需要一种方法来分发和同步钩子（例如，使用符号链接、提交到一个单独的仓库或通过一个初始化脚本）。

Git 钩子提供了一种有力的方式来加强代码质量保证，增加开发工作流程中的自动化步骤，并确保团队遵守既定的开发规范和过程。

4.3 描述 Git Rebase 的原理及其与 Merge 的差异

Git Rebase 是一种 Git 历史整理的方法，它的目的是修改一系列提交的基点（起点），使其看上去如同从不同的分支起点开始。通过 Rebase，你可以将本地未推送的更改应用（重新播放）在另一个分支的最新更改之上。

Rebase 的原理

通常，rebase 用于将主分支上的更新集成到特性分支上。它的工作原理如下：

1. 找到共同祖先：定位两个分支（比如 feature 和 master）的共同祖先提交。
2. 暂存更改：从特性分支中提取在共同基点之后的提交，并暂时存储这些变更（如补丁或变更集合）。
3. 移动基点：特性分支的基点移动到目标分支（通常是 master）的最新提交上。
4. 应用更改：在新基点上依次重新应用暂存的提交。

这个过程同样会产生一个线性的提交历史，看起来就像是所有更改都是按顺序在目标分支上进行的，这可以避免分叉的合并提交。

Git Rebase 的用法示例

git checkout feature-branch
git rebase master

上面的命令会将 feature-branch 分支上的更改重新应用到 master 分支的当前提交上。

Rebase 与 Merge 的差异

Merge:

• 将一个分支的变更集成到另一个分支时保留所有的、完整的分支历史。
• 会创建一个合并提交 (merge commit)，这个提交有两个父节点，代表两个合并分支的头。
• 保持了实际的开发历史，但历史记录可能会变得复杂并且难以理解。

Rebase:

• 在引入更改之前，重写分支历史，使其像是从最新的基点开始进行的。
• 在历史中不会看到合并提交，提供了一个更干净、线性的项目历史。
• 可能会更改提交 ID（因为 Git 的提交是基于其内容和父提交的哈希），这意味着你正在改变历史。
• 在多人协作的公共分支进行 rebase 通常被认为是不好的实践，因为它可能会导致混乱和分支冲突。

在决定是否使用 Rebase 或 Merge 时，你需要考虑项目的协作模式和团队偏好。推荐在个人分支或在确保沟通明确的情况下使用 Rebase，以便团队成员可以同步他们的工作。对于共享分支（例如 main 或 master），通常使用 Merge 是一个更安全的选择，以避免潜在的冲突和不必要的麻烦。

5 Git 远程仓库

5.1 描述如何使用远端（Remote）和追踪分支（Tracking Branch）

远端（Remote）和追踪分支（Tracking Branch）是 Git 分布式版本控制系统中协作和代码共享的基础构建块。

远端（Remote）

远端是指你本地仓库所对应的服务器上的版本。远端让你可以与团队成员共享分支，并推送或拉取数据。

1. 添加远端：
   使用 git remote add 命令添加一个新的远端仓库引用：

git remote add <remote-name> <remote-url>

例如，要添加名为 origin 的远端：

git remote add origin https://github.com/user/repo.git

2. 查看远端：
   使用 git remote -v 显示当前配置的远端仓库列表及其 URLs。
3. 从远端拉取：
   使用 git pull 下载并合并远端的更改到你的本地仓库：

git pull <remote-name> <branch-name>

4. 推送到远端：
   使用 git push 将你的本地更改推送到远端仓库：

git push <remote-name> <branch-name>

追踪分支（Tracking Branch）

追踪分支是本地分支与远端分支之间的直接联系，使得推送和拉取命令更加简洁。

1. 创建追踪分支：
   当你从远端签出分支时，默认创建一个追踪分支。例如，签出 origin 远端的 main 分支：

git checkout -b main origin/main

现在的 main 分支将自动追踪 origin/main。
2. 设置已存在分支的上游：
如果你已经有一个本地分支，可以使用 git branch -u 或 --set-upstream-to 来设置追踪关系：

git branch -u <remote-name>/<branch-name>

3. 简化推送和拉取：
   设置追踪关系后，你可以无需指定远端名和分支名直接使用 git push 和 git pull 命令。
4. 查看追踪关系：
   使用 git branch -vv 可查看本地分支与其追踪远端分支的关系。

总结

远端和追踪分支机制为分布式开发和团队协作提供了大量的便利，它使得同步代码和管理项目成为一个更加直观和自动的过程。在日常的 Git 工作流中，合理设置和使用远端与追踪分支对于提升效率和减少潜在的错误至关重要。

5.2 讲述如何管理和协调多个远程仓库

在 Git 中，你可以配置和管理多个远程仓库，这在协同作业和维护项目的多个镜像或远程版本时特别有用。以下是如何协调多个远程仓库的方法：

添加远程仓库

你可以使用 git remote add 命令来添加一个新的远程仓库：

git remote add <remote-name> <remote-repo-url>

• <remote-name> 是你自定义的远程仓库名称。
• <remote-repo-url> 是远程仓库的 URL。

查看远程仓库

要检查当前配置的远程仓库，可以使用：

git remote -v

这将列出所有配置的远程仓库以及它们的 URLs。

拉取远程变更

你可以从特定的远程仓库拉取新变更：

git pull <remote-name> <branch>

• <remote-name> 是远程仓库的名称。
• <branch> 是你要拉取的远程分支名称。

推送变更至远程仓库

要推送本地分支到特定的远程仓库，使用：

git push <remote-name> <branch>

你可能需要先将本地分支与远程分支设置为跟踪关系，使用 --set-upstream 或 -u 参数。

抓取远程变更

与 pull 类似，fetch 会从远程仓库下载新变更，但不会自动合并或更新你的当前工作。

git fetch <remote-name>

删除远程仓库

如果需要删除一个不再使用的远程仓库，可以使用：

git remote remove <remote-name>

协调多个远程仓库

• 避免冲突：在推送或拉取时注意避免冲突，尤其是在多个协作者都对远程仓库进行变更的时候。
• 保持同步：定期抓取和拉取所有远程仓库来保持本地仓库同步。
• 清晰的命名：给远程仓库一个清晰和明确的名字，例如 origin, upstream, mirror 等，以清楚地区分它们。
• 合并前测试：在合并变更前，确保运行测试来预防将错误引入项目。

管理多个远程仓库要求开发者对 Git 有较深的了解，同时也要有一定的组织和协调能力。使用清晰的远程策略和适当的命名约定，可以使管理变得更加简洁。

5.3 解释如何处理反向合并（upstream）和贡献（forks）

在开源开发中，处理上游仓库（即原始仓库）的变更和管理从你的分叉仓库（即 fork）所做的贡献是一个非常重要的过程。以下是如何处理这些工作的基本指南：

反向合并（Merging Upstream）

当你在自己的分叉仓库中工作时，你的本地代码可能会落后于上游仓库的最新更改。定期从上游合并变更对于保持你的分叉与原始仓库同步非常重要。

1. 添加上游仓库为远程：
   如果还没有添加，你需要将原始仓库添加为你的本地仓库的一个远程（通常称为 upstream）。

git remote add upstream https://github.com/original_owner/original_repository.git

2. 获取上游仓库的变更：
   定期获取上游仓库的变更，但尚不合并：

git fetch upstream

3. 合并变更到你的本地分支：
   将变更合并到你的当前工作分支。这通常是你的 main 分支或其他需要更新的开发分支。

git checkout main
git merge upstream/main

4. 解决冲突：
   如果有必要，解决合并期间出现的任何冲突。然后，提交这些更改到你的分支。
5. 推送到你的远程分叉：
   将更新后的分支推送到你的远程分叉，以便它反映了上游仓库的最新状态。

git push origin main

贡献到上游（Contributing Forks）

当你要将改动贡献给原始仓库时，你可以创建一个拉取请求（Pull Request），通过比较上游仓库和你的分叉仓库的指定分支。

1. 创建特性分支：
   为每个新特性或修复创建一个新的分支，而不是直接在 main 分支上工作。

git checkout -b feature-branch

2. 进行更改和提交：
   在你的特性分支上进行更改，并提交：

git commit -m "Add feature or fix"

3. 保持分支最新：
   如果在你开始工作后上游仓库有了新的变更，请反向合并这些变更到你的特性分支，并解决可能出现的冲突。
4. 推送特性分支到你的远程分叉：
   当你准备好将更改贡献给原始仓库时，推送你的特性分支到你的远程分叉。

git push -u origin feature-branch

5. 创建拉取请求：
   在 GitHub、GitLab 或其他托管服务上创建一个拉取请求，请求将你的特性分支的更改合并到上游仓库。
6. 等待代码审查：
   仓库的维护者将审查你的更改，并可能请求修订或直接合并它们。
7. 更新拉取请求：
   如果维护者请求更改，更新你的分支并推送修订，拉取请求将自动更新。
8. 清理分支：
   一旦你的拉取请求被合并或关闭，无论是否成功，考虑删除你的特性分支来保持仓库整洁。

按照这些步骤能够确保你的分叉仓库与上游保持同步，并允许你以一种组织良好的方式贡献代码。记住，开源项目的每个贡献都是由维护者来管理和策略制定的，因此确保你遵循了项目的贡献指南。

6 Git 工具和辅助命令

6.1 讨论 Git Stash 的使用场景和限制

Git Stash 是 Git 的一个有用特性，它允许你临时保存当前工作目录和暂存区的改动，这样你就可以在没有提交的情况下，把工作目录恢复到干净（未修改）的状态。这使得你能在多个任务间切换，而不会丢失或混淆正在进行中的工作。

使用场景

1. 中断当前工作：
   当你正处于一个工作中途，比如正在编写代码实现新功能，而突然需要切换到另一个分支来修复一个紧急的 bug。使用 git stash 可以保存当前进度，然后你可以在一个干净的基础上切换分支。
2. 合并更新：
   如果远程仓库有了更新，而你又不想提交当前的工作，你可以使用 stash 来暂时保存你的改动，然后拉取（pull）或合并（merge）远程更新。
3. 清理工作目录：
   在某些时候，你可能需要执行一个需要干净工作目录的操作，例如，切换到之前的提交点。

基本命令

• 保存改动：

git stash
# 或者具有更描述性的信息
git stash save "my work in progress"

• 查看已保存的 Stash：

git stash list

• 应用最近一个 Stash：

git stash apply
# 或者指定一个特定的 Stash 来应用
git stash apply stash@{<stash_number>}

• 弹出 Stash：
  弹出最近的 Stash，并从 Stash 列表中移除它：

git stash pop

• 删除 Stash：
  如果不再需要 Stash，可以从 Stash 列表中删除它：

git stash drop stash@{<stash_number>}

限制

1. 不包含未追踪文件：
   默认情况下，git stash 只保存已追踪（tracked）的文件和暂存的改动。未追踪的文件（如新添加的文件）需要使用 -u 或 --include-untracked 选项来包含。
2. Stash 冲突：
   应用一个 Stash 到一个已经改变的工作目录可能会产生冲突。如果发生了冲突，需要手动解决这些冲突。
3. 丢失的 Stash：
   使用 git stash pop 时，在解决冲突之前出现的中断可能会导致将 Stash 移除。为此，建议先用 apply 确定能够无冲突地应用 Stash，再使用 drop 手动删除。
4. 难以管理：
   在快速迭代的开发过程中，Stash 列表可能会快速增长并变得难以管理，因为 Stash 项只能通过编号来识别，而且列表可能包括多次中断的工作。

Git Stash 是一种强大的工具，能够在你需要暂停或保存当前工作状态时提供帮助。不过，如不求助于编写描述性信息，过度依赖 stash 会让维护 Stash 列表变得困难。将其用作临时保存变更的工具，并周期性地清理列表，可以最大限度地发挥其效用。

6.2 描述 Git 日志和历史查看命令

Git 提供了许多命令来查看和浏览仓库的历史记录和日志。以下是一些常见的 Git 日志查看命令：

git log

git log 命令用于展示提交历史记录。它提供了多个选项来自定义日志输出，包括日期、作者和更改内容等。

git log

可以按照各种格式展示日志：

• 普通日志输出（默认）。
• --oneline：简洁的一行表示法。
• --stat：显示每个提交中改变的文件列表及其变更统计信息。
• --graph：以图形化的方式显示分支和合并历史。
• --pretty=format:"%h - %an, %ar : %s"：自定义输出日志的格式。

git show

使用 git show 显示特定提交或对象的各种类型的信息。

git show commit_hash

这将显示给定提交的元数据和内容更改。

git diff

git diff 用来比较提交、分支、文件等之间的差异。

git diff
git diff commit_hash_1 commit_hash_2
git diff branch_name1..branch_name2

• 不加参数默认比较工作目录和暂存区的差异。
• 比较两个提交之间的差异。

git reflog

git reflog 显示 Git 操作的记录，例如提交、重置、分支等操作，这对于定位丢失的工作和恢复历史记录非常有用。

git reflog

时间限制和搜索

可以对 git log 使用时间限制和搜索功能，找到特定日期或作者的提交：

git log --since="1 week ago"
git log --until="2020-01-01"
git log --author="Author Name"
git log --grep="Bug fix"

查看某个文件或路径的变更历史

若要限定 git log 输出到特定文件或路径，可以在命令后指定文件路径：

git log -- path/to/file

结合使用

git log 的多个选项可以结合使用，以构建精确的查询。例如，查找特定作者在过去一个月里对某个子目录的贡献：

git log --author="Author Name" --since="1 month ago" -- path/to/directory/

通过上述命令，你可以有效地在 Git 仓库历史中导航，了解代码变更的历史，定位特定的变化，并进行代码审查。掌握这些命令对于每个使用 Git 的开发者来说是非常重要的。

6.3 解释 Git 标签的用法及其版本控制的角色

Git 标签（Tag）是指向特定提交的引用，通常用于标记发行版（release）的重要点，比如版本的发布。与分支不同，标签是静态的，一旦创建，它指向的提交不会改变。

标签的用法

Git 提供了两种类型的标签：

1. 轻量标签（Lightweight）：类似于一个不会变动的分支，它直接指向某个提交。

git tag v1.0

2. 注解标签（Annotated）：包含额外信息的标签，如作者名、邮箱、日期、标签消息，以及一个可选的 GPG 签名。注解标签被存储为完整的对象在 Git 数据库中。

git tag -a v1.0 -m "Version 1.0 release"

标签可以在任何时候被添加，通常在完成一个重大功能、修复重要 bug 或准备发布新版本后创建。

查看和共享标签

列出所有标签：

git tag

获取关于特定标签的信息：

git show v1.0

将标签推送到远程仓库：

git push origin v1.0             # 推送单个标签到远程仓库
git push origin --tags            # 推送所有标签到远程仓库

标签在版本控制中的角色

1. 版本跟踪：标签提供了一种方便的方式来跟踪软件版本的历史，它允许开发者快速切换到特定的发行版。
2. 发布管理：在软件发布过程中使用标签来标记正式发行的版本，使其他人可以轻松地找到和下载特定版本的代码。
3. 回溯支持：如果需要修复或查找旧版本中的代码，标签可以帮助轻松回溯到对应的状态。
4. CI/CD 集成：在持续集成/持续部署工作流程中，可以使用标签来触发构建和部署进程，例如自动化生产环境的部署或为特定版本创建软件包。
5. 文档记录：标签可用于在项目历史中清晰记录特定的里程碑，提供一种文档化项目进展的方法。

最佳实践

• 使用语义化版本控制（Semantic Versioning），比如格式为 vMAJOR.MINOR.PATCH，其中主版本号、次版本号和修订号代表不同级别的修改。
• 使用带注解的标签并提供有意义的消息，尤其是对于重要的发行版。
• 在一个固定的分支（例如 main 或 master）上标记发布，以确保版本的稳定性和一致性。
• 使用 GPG 签名的标签来提高安全性。通过添加 -s 参数进行签名：

git tag -a v1.0 -m "Version 1.0 release" -s

Git 标签是版本控制中的一个重要组成部分，合理地使用标签有助于提升项目的可维护性和可追溯性。

7 Git 故障诊断和恢复

7.1 讲述 Git 中撤销更改和恢复历史版本的方法

Git 提供了多种方式来撤销更改和恢复历史版本，这些功能提高了源代码的管理灵活性，并为开发者提供了错误纠正的方法。以下是在 Git 中进行撤销和恢复操作的几种常见方法：

撤销更改

1. 撤销工作目录中的更改：
   git checkout 或 git restore 命令可以撤销工作目录中对文件的更改。

使用 git checkout 撤销更改：

git checkout -- <file>

使用 git restore 撤销更改（从 Git 2.23 版本开始推荐）：

git restore <file>

2. 撤销暂存区中的更改：
   git reset 命令可以将暂存区中的更改撤销，并将文件恢复到工作目录。

git reset HEAD <file>

3. 撤销某次提交的更改：
   git revert 命令可以创建一个新的提交，将指定的提交所做的更改逆转。

git revert <commit>

恢复历史版本

1. 检出旧版本的文件：
   用 git checkout 可以将文件恢复到历史上某个特定提交的状态。

git checkout <commit> <file>

2. 重设当前分支的头：
   git reset 命令可以用来切换当前分支的头到不同的提交，它有三个主要的模式 --hard、--soft 和 --mixed。

   • 使用 --hard 将工作目录、暂存区和分支全部重置到特定提交：

   git reset --hard <commit>
   
   

   • 使用 --soft 仅将当前分支头指针移动到特定提交，而暂存区和工作目录不变：

   git reset --soft <commit>
   
   

   • 使用 --mixed（默认选项）将分支头指针和暂存区重置，但保留工作目录不变：

   git reset <commit>
   
   

3. 使用 git reflog 恢复丢弃的提交：
   如果不小心使用 --hard 模式重置并清除了一些更改，可以利用 git reflog 查找丢失的提交，并将 HEAD 重置到该状态。

git reflog
git reset --hard <reflog-entry>

以上方法可以在多种不同的场景下进行源代码的撤销和恢复，正确运用这些命令可以大大增加版本控制的灵活性，降低意外更改带来的风险。在执行涉及数据丢失的操作时，如 git reset --hard 或 git rebase 等，应该特别谨慎，最好先确认没有未提交的关键更改或者有适当的备份。

7.2 描述如何在 Git 中定位和恢复丢失的提交

在 Git 中，有时候你可能需要定位并恢复一个被意外删除或丢失的提交。这可能是由于错误的分支删除、合并冲突处理不当或其它操作错误引起的。即使在这些情况下，由于 Git 保存了所有历史变更，通常仍然有方法找回丢失的提交。以下是在 Git 中定位和恢复丢失提交的一些方法：

使用 git reflog

• reflog 是一个记录了你本地仓库 HEAD 和分支头部变更的日志。
• 要看到最近的 HEAD 更新记录，你可以使用：

git reflog

• reflog 中列出了所有之前 HEAD 的状态，包括已删除的提交。
• 找到丢失提交的哈希值后，你可以使用以下命令检出到新的分支：

git checkout -b <new-branch-name> <commit-hash>

查看孤立节点（Dangling Commits）

• 孤立节点 是不再有任何分支或标签所引用的提交。
• 要查找它们，可以使用以下命令：

git fsck --lost-found

• 这个命令会检查 Git 数据库的完整性，并列出孤立的节点。
• 然后你可以使用 git show <commit-hash> 来查看每个孤立提交的详细信息。

检出丢失的提交

• 一旦你找到了丢失的提交哈希值，可以创建一个新分支来恢复该提交：

git checkout -b <new-branch-name> <commit-hash>

这将会在新分支上恢复该提交，从而你可以继续工作或将更改合并到其它分支。

应用丢失的更改

• 如果你不想直接恢复整个丢失的提交，也可以创建一个补丁文件并将丢失的更改应用到当前分支：

git format-patch -1 <commit-hash> --stdout > commit.patch
git apply commit.patch

-1 选项表示只输出单个提交的变更。

使用 git cherry-pick

• 如果丢失的提交在另一个分支上存在，但没有合并到当前分支，可以使用 git cherry-pick 将单个提交应用到当前分支：

git cherry-pick <commit-hash>

这通常用于应用未合并的特性分支提交。

防止丢失提交

• 为了避免丢失提交，可以定期地推送你的工作到远程仓库中。即使本地丢失了数据，也可以从远程仓库中找回。
• 在删除分支或执行可能导致数据丢失的操作前，创建一个备份分支或标签。

通过利用这些 Git 工具和方法，当意外删除提交或分支后，你往往可以恢复几乎所有类型的丢失数据。但最有效的丢失数据防范应始终是良好的协作习惯和定期备份。

7.3 解释 Git 修补（patching）和 Cherry-picking 的用途

在 Git 中，修补（patching）和樱桃采摘（cherry-picking）是两种用于代码变更的技术。这些技术可以在不同分支间移动提交，但它们的应用场景略有不同。

修补（Patching）

修补是创建更改集（patch）的过程，这些更改集可以应用于代码库的其他部分。在 Git 中，你可以使用 git diff 创建一个 patch 文件，它记录了两个提交或分支之间的差异。然后，你可以使用 git apply 或 git am 命令将这个 patch 应用于当前分支。

常见用途：

• 共享代码：在没有直接进行代码合并时，将代码变更分享给其他开发者，特别是通过邮件列表时。
• 代码备份：创建对代码的更改集的快速备份，无需创建一个完整的提交历史。

示例命令：

# 创建 patch 文件
git diff commitA commitB > changes.patch

# 应用 patch 文件
git apply changes.patch

樱桃采摘（Cherry-picking）

樱桃采摘是将指定提交从一个分支引入到当前分支的过程。在执行 git cherry-pick 命令时，Git 会取出单个提交所引入的更改，并尝试在你所在的分支上重新应用这些更改。

常见用途：

• 选择性包含提交：将一个分支上特定的提交应用到当前分支，而不合并这个分支的全部内容。
• 修复问题：在发现一个分支上的特定提交修复了一个问题时，可以将其樱桃采摘到当前分支。

示例命令：

# Cherry-pick 某个特定的提交到当前分支
git cherry-pick <commit-hash>

两者的差异

• 粒度：樱桃采摘适用于从分支拾取单个提交。修补则是基于文件的差异，可以跨越多个提交。
• 记录性：樱桃采摘会在原始提交的基础上创建一个新的提交记录。修补则是将修改应用到工作目录，你需要手动创建提交。
• 冲突处理：如果在樱桃采摘时遇到冲突，Git 会暂停操作并让你解决冲突，然后可以继续樱桃采摘。修补冲突需要在应用之前手动解决。
• 场景：樱桃采摘通常用于版本控制环境内，而修补则适用于分发和应用更改集的情况，例如开源项目的贡献。

修补和樱桃采摘都是很有用的 Git 技术，它们为不同分支间的代码变更提供了灵活的处理方式。正确应用这两种技术可以在保持代码库整洁的同时，高效地管理代码更改。在使用这些方法时，应当小心使用，特别是在团队项目中，确保不会破坏其他人的工作或引入不一致的历史。

8 Git 与 CI/CD 集成

8.1 讨论 Git 在持续集成/持续部署的角色

在持续集成（CI）和持续部署（CD）流程中，Git 扮演着至关重要的角色。它不仅是源代码管理（Version Control System, VCS）的一个工具，还是自动化构建和部署的触发器。下面具体讨论 Git 在 CI/CD 中的角色和作用：

源代码管理

Git 作为分布式版本控制系统，它允许开发团队合作开发代码、管理多个分支和追踪每次提交的历史记录。这是实现 CI/CD 的基础。

触发持续集成

在 CI 中使用 Git 可以自动触发构建和测试流程。当代码被推送到远程仓库后，CI 工具（如 Jenkins、Travis CI、CircleCI、GitLab CI等）会侦听到这些变更并启动自动化的构建和测试过程。

分支策略

持续集成常常依赖于 Git 的分支模型来管理代码变更。例如，Git-flow 和 GitHub Flow 是两种常见的分支策略，可支持 CI 流程。在这些策略下，main/master 分支通常是用来反映生产环境状态的，而特性分支则用来开发新功能。

Merge Request (MR) / Pull Request (PR)

MR/PR 是代码审阅和合并的工具，也是自动运行测试套件和其他质量检查的地方。当 MR/PR 被创建时，CI 系统会运行一系列检查以确保代码变更达到项目标准，并且不会破坏已有功能。

自动化部署

CD 流程利用 Git 变更来触发从测试环境向生产环境的自动化部署。在某些自动化策略中，一旦主分支或者指定的发布分支更新，将自动启动部署流程。

标签和发布

Git 可以对特定的提交打上标签，以标记项目的版本。这些标签可以用作制品版本的标识，方便追踪和部署。Git 标签通常与软件发布对齐，也可以触发自动化部署流程。

版本控制与回滚

Git 提供了机制来回滚错误的部署。通过检出早先的提交或标签，你可以在一个已知的稳定状态下重建项目代码。

协作与通知

Git 作为团队协作的平台，可以整合到更大的 DevOps 工具链中，以实现团队成员间的更好协作和及时通知，如构建失败、测试未通过或成功的部署等。

通过以上的方式，Git 成为了 CI/CD 管道中不可或缺的一部分，为自动化和协作提供支持。合理用好 Git 的特性和功能，可帮助实现高效的软件开发和交付流程。在 DevOps 文化中，Git 和 CI/CD 的结合不断推动着软件开发实践的革新。

8.2 描述如何使用 Git 标签和分支支持 CI/CD 自动化

在持续集成/持续部署（CI/CD）自动化流程中使用 Git 标签和分支可以帮助管理代码版本、触发构建和部署流水线，并跟踪生产环境的版本。以下是 Git 标签和分支在 CI/CD 中的应用描述：

Git 分支在 CI/CD 自动化中的应用

1. 功能分支（Feature Branch）：

   • 功能分支用于新功能开发或修复工作。当合并到主分支（如 master 或 main）时，可以触发 CI 流程自动运行构建和测试。

2. 开发分支（Develop Branch）：

   • 一些工作流（如 Git-flow）维护一个专门的开发分支。当开发分支达到稳定状态并准备好合并到主分支时，可能会触发预发布的 CI 构建和测试。

3. 主分支（Master/Main Branch）：

   • 主分支应始终保持可部署状态。一旦代码被合并到主分支，CI 流程会运行一系列的测试，若通过，则可以触发 CD 流程来执行部署。

4. 发布分支（Release Branch）：

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

持续集成常常依赖于 Git 的分支模型来管理代码变更。例如，Git-flow 和 GitHub Flow 是两种常见的分支策略，可支持 CI 流程。在这些策略下，main/master 分支通常是用来反映生产环境状态的，而特性分支则用来开发新功能。

Merge Request (MR) / Pull Request (PR)

MR/PR 是代码审阅和合并的工具，也是自动运行测试套件和其他质量检查的地方。当 MR/PR 被创建时，CI 系统会运行一系列检查以确保代码变更达到项目标准，并且不会破坏已有功能。

自动化部署

CD 流程利用 Git 变更来触发从测试环境向生产环境的自动化部署。在某些自动化策略中，一旦主分支或者指定的发布分支更新，将自动启动部署流程。

标签和发布

Git 可以对特定的提交打上标签，以标记项目的版本。这些标签可以用作制品版本的标识，方便追踪和部署。Git 标签通常与软件发布对齐，也可以触发自动化部署流程。

版本控制与回滚

Git 提供了机制来回滚错误的部署。通过检出早先的提交或标签，你可以在一个已知的稳定状态下重建项目代码。

协作与通知

Git 作为团队协作的平台，可以整合到更大的 DevOps 工具链中，以实现团队成员间的更好协作和及时通知，如构建失败、测试未通过或成功的部署等。

通过以上的方式，Git 成为了 CI/CD 管道中不可或缺的一部分，为自动化和协作提供支持。合理用好 Git 的特性和功能，可帮助实现高效的软件开发和交付流程。在 DevOps 文化中，Git 和 CI/CD 的结合不断推动着软件开发实践的革新。

8.2 描述如何使用 Git 标签和分支支持 CI/CD 自动化

在持续集成/持续部署（CI/CD）自动化流程中使用 Git 标签和分支可以帮助管理代码版本、触发构建和部署流水线，并跟踪生产环境的版本。以下是 Git 标签和分支在 CI/CD 中的应用描述：

Git 分支在 CI/CD 自动化中的应用

1. 功能分支（Feature Branch）：

   • 功能分支用于新功能开发或修复工作。当合并到主分支（如 master 或 main）时，可以触发 CI 流程自动运行构建和测试。

2. 开发分支（Develop Branch）：

   • 一些工作流（如 Git-flow）维护一个专门的开发分支。当开发分支达到稳定状态并准备好合并到主分支时，可能会触发预发布的 CI 构建和测试。

3. 主分支（Master/Main Branch）：

   • 主分支应始终保持可部署状态。一旦代码被合并到主分支，CI 流程会运行一系列的测试，若通过，则可以触发 CD 流程来执行部署。

4. 发布分支（Release Branch）：

[外链图片转存中…(img-Nyv5exd9-1714231473488)]
[外链图片转存中…(img-ruejxJ8c-1714231473489)]
[外链图片转存中…(img-sbKEwgye-1714231473489)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取