前端

服务端

计算机基础

### 什么是 Git Hook？

Git Hook 是 Git 提供的一种强大的功能，允许用户在特定的重要动作发生时，触发自定义脚本的执行。例如，可以在代码提交（commit）前后、代码推送（push）前后等关键时刻执行脚本。这些钩子可以用于执行代码风格检查、自动运行测试、自动化部署等任务，有助于保证代码质量和流程的自动化。

Git Hook 分为客户端钩子和服务器端钩子。客户端钩子包括 pre-commit、post-commit、pre-push 等，主要在本地执行。服务器端钩子如 pre-receive、post-receive 等，在服务器上执行，常用于处理通过 push 接收的数据。

### 如何使用 Git Hook？

使用 Git Hook 的步骤大致如下：

1. **选择合适的钩子类型**：
   首先，需要确定在哪个阶段需要触发脚本，比如是提交前（pre-commit）、推送前（pre-push）还是其他。

2. **创建钩子脚本**：
   在 Git 仓库的 `.git/hooks` 目录中，你会找到一系列示例钩子脚本，这些文件以 `.sample` 结尾。你可以选择一个相关的钩子模板，复制并重命名（去掉 `.sample` 后缀），然后根据需要编辑它。

3. **编写脚本逻辑**：
   在钩子脚本中编写需要执行的逻辑。脚本可以用 shell、Python、Ruby 等任何可执行语言编写。例如，一个简单的 pre-commit 钩子脚本可能会执行代码风格检查。

   ```bash
   #!/bin/sh
   # pre-commit hook to check code style
   result=$(python style_check.py)
   if [ "$result" != "ok" ]
   then
     echo "Code style check failed"
     exit 1
   fi
   ```

4. **使脚本可执行**：
   为了让 Git 能够执行这个钩子脚本，你需要确保它具有执行权限：

   ```bash
   chmod +x .git/hooks/pre-commit
   ```

5. **测试钩子**：
   提交或推送代码之前，可以先做一些测试，确保钩子按预期工作。如果钩子脚本返回非零退出状态，它会阻止 Git 操作（如提交或推送）的完成。

通过这些步骤，你可以利用 Git Hook 来增强你的开发流程，自动化重复性任务，保证代码质量，或进行持续集成/持续部署（CI/CD）的操作。

什么是 git hook？以及如何使用 git hook？

### 什么是 Git Hooks？

Git hooks 是 Git 中的一种脚本功能，它允许在执行某些 Git 命令（如提交和推送）时自动触发和执行自定义脚本。这些钩子可以在不同的操作阶段被调用，如代码提交前、提交后、代码推送前后等，从而帮助自动化各种版本控制过程。

Git hooks 分为客户端钩子和服务器端钩子。客户端钩子包括 `pre-commit`、`post-commit`、`pre-push` 等，而服务器端钩子包括 `pre-receive`、`post-receive` 等。这些钩子可以用来检查代码风格、运行测试、自动部署应用等。

### 如何为项目定制 Git Hooks？

为项目定制 Git hooks 主要有以下几个步骤：

1. **定位到 Hooks 目录**：
   每个 Git 仓库在其 `.git/hooks` 目录中都含有默认的钩子样本。这些样本以 `.sample` 结尾，并且默认是不启用的。例如，`pre-commit.sample`。

2. **创建或修改钩子脚本**：
   根据需要选择相应的钩子，复制相应的样本文件并去掉 `.sample` 扩展名。例如，将 `pre-commit.sample` 复制为 `pre-commit`。

3. **编写钩子脚本**：
   打开钩子脚本文件，根据需要编写或修改脚本。钩子脚本可以用任何可执行脚本编写，如 Bash、Python 等。例如，下面是一个简单的 Bash 脚本，用于 `pre-commit` 钩子，该脚本检查是否有 `TODO` 标记但未处理的代码：

   ```bash
   #!/bin/sh
   # 检查代码中是否包含 "TODO" 标记
   if git diff --cached | grep 'TODO'; then
       echo "提交被阻止：代码中仍有待处理的 'TODO'。"
       exit 1
   fi
   ```

4. **使脚本可执行**：
   为了让钩子脚本生效，必须确保其为可执行文件。这可以通过运行如下命令来实现：

   ```bash
   chmod +x .git/hooks/pre-commit
   ```

5. **测试钩子**：
   在完成钩子脚本的编写和设置后，应该通过实际操作（如尝试提交）来测试钩子是否按预期工作。

通过这样的步骤，可以针对具体的项目需求定制 Git hooks，实现自动化管理和控制流程，提升开发效率和代码质量。

什么是 Git hooks？如何为项目定制 git hooks？

### 什么是“git merge”？

`git merge` 是一个 Git 命令，用于将两个或多个开发历史合并成一个。通常，这用于将一个分支的更改合并到另一个分支中。例如，当一个功能开发完毕时，你可能会想把这些更改从功能分支合并回主分支。

### 如何使用它？

使用 `git merge` 的基本步骤如下：

1. **切换到接收更改的分支**：首先，你需要切换到你想要将更改合并进去的分支。假设我们想要将 `feature` 分支的更改合并到 `main` 分支，你首先需要切换到 `main` 分支：

    ```bash
    git checkout main
    ```

2. **执行合并操作**：接下来，使用 `git merge` 命令来合并 `feature` 分支：

    ```bash
    git merge feature
    ```

    这条命令告诉 Git 把 `feature` 分支的更改合并到当前分支（此例中为 `main` 分支）。

3. **解决可能出现的冲突**：有时候，合并操作可能会遇到冲突，尤其是当两个分支对同一个文件的同一部分都进行了更改时。如果发生冲突，Git 会停止合并并要求你手动解决这些冲突。解决冲突后，你需要使用 `git add` 命令标记冲突已解决：

    ```bash
    git add [文件名]
    ```

4. **完成合并**：一旦冲突解决并且所有文件都已添加，你可以通过 `git commit` 命令完成合并操作。通常，Git 会提供一个默认的合并提交消息，你可以直接使用或修改它：

    ```bash
    git commit
    ```

5. **检查合并结果**：合并完成后，你可以使用如 `git log` 或 `git status` 等命令来检查合并的状态和历史记录，确保一切都如预期那样。

### 实例

假设我正在开发一个新功能，在独立的 `feature` 分支上工作。开发完成后，我需要将这些更改合并回 `main` 分支。这时，我会执行以下命令：

```bash
git checkout main
git merge feature
```

如果合并顺利，没有冲突，我就成功地将功能更新合并到了主分支。如果遇到冲突，则需要按照提示解决这些冲突，然后继续提交过程。

什么是“git merge”？如何使用它？

### 对比 `git push --force-with-lease` 和 `git push --force`

当我们使用git进行版本控制时，有时候可能需要用到强制推送（`force push`）来覆盖远程仓库的历史。这通常发生在我们需要修改已经推送到远程仓库的提交时。这里有两个常用的强制推送选项：`git push --force` 和 `git push --force-with-lease`。下面我将详细对比这两种命令。

#### 安全性
- **`git push --force`** 是一种较为“暴力”的方式，它会无条件地将远程分支的历史替换为本地分支的历史。这意味着如果其他开发者已经推送了他们的提交到远程仓库，使用 `git push --force` 会导致这些提交丢失。
  
- **`git push --force-with-lease`** 相对来说更为安全。它在执行强制推送之前会检查远程分支的当前状态，确保自上次拉取以来没有其他开发者推送过新的提交。如果检测到远程分支有更新，推送会被拒绝，从而避免潜在的数据丢失。

#### 使用场景
- **`git push --force`** 的使用场景通常是在非常确定没有其他人正在操作该分支的情况下，或者在一个小团队中，团队成员之间有很好的沟通和协调。

- **`git push --force-with-lease`** 更常用于开放的或者较大的团队中，特别是在开发者需要频繁地与远程仓库同步其更改时。它提供了一层额外的安全保障，确保不会无意中覆盖同事的工作。

#### 示例
假设你在本地进行了一次提交改正，修改了之前的一个错误，然后准备推送到远程仓库。如果使用 `git push --force`，不管远程分支状态如何，你的更改都会覆盖远程分支：
```bash
git push origin main --force
```

而如果选择使用 `git push --force-with-lease`，Git会先检查远程分支的状态：
```bash
git push origin main --force-with-lease
```
如果在你拉取之后，远程分支有其他人的提交，这个命令将不执行推送并给出提示，从而保护了团队的工作。

#### 总结
总体来说，`git push --force-with-lease` 提供了比 `git push --force` 更高的安全性，防止了可能的数据丢失。在团队协作的环境中，优先考虑使用 `git push --force-with-lease` 是一个更加谨慎的选择。

`git push --force-with-lease` 与 `git push --force` 的对比

### 查找和恢复已删除文件的方法

在使用Git进行版本控制时，找回已删除的文件是一项常见的需求。要在Git历史中查找和恢复已删除的文件，可以遵循以下步骤：

#### 1. 确定文件被删除的提交

首先，需要找出是在哪个具体的提交中删除了该文件。可以使用`git log`命令配合`--`路径选项来查看与特定文件相关的提交记录。

```bash
git log -- <file_path>
```

如果你记不清文件的确切路径，可以使用以下命令搜索包含删除操作的提交：

```bash
git log --all --full-history -- **/filename_to_search*
```

#### 2. 检查删除的文件内容

找到了可能包含文件删除的提交后，可以使用`git show`命令查看该提交的详情，确认是否确实删除了需要恢复的文件。

```bash
git show <commit_hash>
```

#### 3. 恢复文件

确认文件已被删除后，可以使用`git checkout`命令从历史提交中恢复该文件到当前工作目录。

```bash
git checkout <commit_hash>^ -- <file_path>
```

这里`<commit_hash>^`表示删除文件的那次提交的前一个提交（即删除操作发生之前的状态），`<file_path>`是被删除文件的完整路径。

#### 示例

假设我在过去的某个项目中不小心删除了一个名为`example.txt`的文件。以下是我找回该文件的步骤：

1. **查找提交**：使用命令找到涉及该文件的提交记录：
   
   ```bash
   git log --all -- example.txt
   ```

2. **确认删除**：通过以下命令检查对应的提交内容，确认文件被删除：

   ```bash
   git show <commit_hash>
   ```

3. **恢复文件**：确定了文件被删除的具体提交后，我使用以下命令将文件恢复到当前工作目录：

   ```bash
   git checkout <commit_hash>^ -- example.txt
   ```

通过这些步骤，我可以有效地从Git历史中查找并恢复已删除的文件，确保项目的完整性和数据的安全。

如何在Git历史中查找和恢复已删除的文件？

Git 垃圾回收是 Git 的一个内置机制，用于优化仓库的性能。Git 通过清理不再需要的对象（如废弃的提交、孤立的节点等）和压缩文件来达到这个目的。对于不熟悉的术语，比如提交（commit），这是指在 Git 中保存的项目历史快照；而节点（node）通常指代 Git 树中的一个元素，如文件、目录等。

### 垃圾回收的工作原理：

1. **删除不可达对象：** 这些通常是那些从任何分支或标签的头部都无法到达的提交。这些提交可能是由于某次错误操作产生的，或者是在某次重写项目历史（如使用 `rebase`）后遗留下来的。

2. **优化仓库结构：** Git 通过重新打包和优化存储库结构来提高性能，比如将多个较小的打包文件合并为一个大的打包文件。

3. **压缩文件：** Git 使用了一种叫做“打包”（packing）的技术，将多个对象存储在一个文件中，并通过 zlib 压缩减少空间占用。

### 调用时机：

Git 的垃圾回收通常在以下几种情况下被调用：

1. **手动调用：** 用户可以通过 `git gc` 命令手动触发垃圾回收。

2. **自动触发：** Git 在执行某些操作如 `git merge`、`git rebase`、`git commit` 等时，会自动检查是否需要执行垃圾回收来优化性能。Git 有内置的启发式算法，根据仓库的状态（例如对象数量和碎片程度）决定是否执行垃圾回收。

3. **仓库维护：** 在定期的仓库维护期间，也可能包括垃圾回收操作，以确保仓库数据的整洁和高效。

### 例子：

假设我在开发一个项目时，使用了 `git rebase` 来修改历史中的几个 commits。这个操作可能会产生一些废弃的 commits，因为原本的 commits 被新生成的 commits 替换。这些废弃的 commits 就变成了不可达对象，占用了额外的存储空间。通过运行 `git gc`，Git 会清理这些不需要的对象，从而优化仓库的性能和减少磁盘空间的占用。

总结来说，Git 垃圾回收是一种重要的机制，用于保持 Git 仓库的健康、高效和清洁。通过定期的垃圾回收，可以确保仓库在长期使用中保持良好的性能。

Git 垃圾回收是什么？它什么时候被调用？

在Git中，发现bug是在哪个提交中引入的，通常我们会使用`git bisect`这个工具。`git bisect`是一个二分查找的工具，它可以帮助我们快速定位引入bug的提交。以下是详细的步骤和示例：

1. **启动`git bisect`**:
    首先，你需要启动`git bisect`的二分查找模式。这可以通过命令`git bisect start`来实现。

2. **标记坏的提交**:
    然后，你需要标记一个当前已知包含bug的提交，通常是最新的提交。这可以通过`git bisect bad`来完成。你可以指定一个具体的提交，如果不指定，默认使用当前HEAD。

3. **标记好的提交**:
    接下来，你需要找到一个较早的提交，这个提交是没有包含bug的。标记这个提交作为一个好的提交，使用`git bisect good [commit-id]`命令。

4. **二分查找**:
    一旦标记了好和坏的提交，Git会自动将代码库切换到中间的提交。你需要测试这个中间的提交是否包含bug。如果包含bug，就用`git bisect bad`标记；如果不包含bug，就用`git bisect good`标记。Git 会继续选择中间的提交进行测试。

5. **重复测试**:
    重复第4步，每次测试后Git会自动帮你缩小可能引入bug的提交的范围，直到找到那个引入bug的具体提交。

6. **结束查找**:
    一旦找到那个引入bug的提交，可以使用命令`git bisect reset`来结束`git bisect`查找过程，这样你的代码库就会回到开始查找前的状态。

**示例**:
假设我们有一个项目，突然发现最新的提交有一个功能不工作了。我们知道一个月前的版本是好的。我们可以如下操作：

```bash
git bisect start
git bisect bad                 # 假设当前HEAD包含bug
git bisect good commit-id-of-one-month-ago   # 标记一个月前的提交为good

# Git 自动切换到中间的提交
# 运行测试，如果测试失败执行 `git bisect bad`, 如果测试通过执行 `git bisect good`
# 重复这一步骤直到找到bug的提交

git bisect reset               # 结束bisect，并回到初始状态
```

通过这个方法，我们可以有效并且系统地确定是哪个具体的提交引入了bug。这对于维护大型项目非常有帮助。

Git 如何发现bug是在哪个提交中引入的？

在Git中，将更改推送到远程存储库的流程涉及几个关键步骤。我将通过一个具体的例子来说明这个过程。

### 步骤 1: 确保本地有最新的远程存储库信息
在推送更改之前，你需要确保你的本地存储库有远程存储库的最新信息。这通常通过执行以下命令来完成：
```bash
git fetch origin
```
这个命令会从远程存储库（默认为origin）获取最新信息，但不会自动合并到你的工作目录中。

### 步骤 2: 提交你的更改
在推送更改之前，需要确保所有的更改都已经提交。如果你有新的更改需要提交，你可以使用以下命令：
```bash
git add .
git commit -m "描述你的更改"
```
这里，`git add .` 命令会添加所有已修改的文件到暂存区，`git commit -m "描述你的更改"` 则会创建一个新的提交，并附加一个描述性的消息。

### 步骤 3: 合并更改
在推送之前，你可能还需要将远程存储库的更改合并到你的本地分支。这可以通过下面的命令完成：
```bash
git pull origin your-branch-name
```
这个命令会从远程分支拉取最新的更改并与你的本地分支合并。

### 步骤 4: 推送更改到远程存储库
一旦本地分支准备好了，你就可以将更改推送到远程存储库。这通常通过执行以下命令来完成：
```bash
git push origin your-branch-name
```
这里，`origin` 是远程存储库的默认名称，`your-branch-name` 是你想要推送更改的分支名。

### 示例
假设我在本地分支`feature-x`上开发了一些新功能，并想要将这些更改推送到远程存储库。以下是我会执行的命令序列：
```bash
git fetch origin
git add .
git commit -m "添加新功能"
git pull origin feature-x
git push origin feature-x
```

### 总结
通过这些步骤，我可以确保我的更改不仅被适当记录，而且与远程存储库保持同步。这也有助于减少冲突的可能性，确保团队协作的顺畅。在工作中，我经常使用这些命令来保持我的代码库更新和同步。

Git 如何将更改推送到远程存储库？

在Git中，标签通常用来标记特定的版本节点，这方便我们在需要时快速定位到这些版本。列出所有的标签可以用以下命令：

```bash
git tag
```

这个命令会列出仓库中所有的标签。如果你想要查看标签的详细信息，例如标签的创建者、日期和附带的注释，可以使用：

```bash
git show <tagname>
```

这里的 `<tagname>` 是你指定的标签名称，这条命令会显示与该标签相关的详细信息，包括相关的commit信息。

举个例子，假设我们正在处理一个软件项目，并且在每次发布新版本时，我们都会添加一个标签。如果我们发布了版本1.0，我们可能会使用如下命令来创建一个标签：

```bash
git tag -a v1.0 -m "Release version 1.0"
```

之后，如果我们想要查看项目中所有的发布版本，我们就可以简单地运行 `git tag` 命令来列出所有标签。这会给我们一个清晰的版本历史视图，非常有助于版本控制和回退。

如果需要更多的排序或格式化选项，比如按字典顺序列出标签，可以使用：

```bash
git tag --sort=v:refname
```

这些功能使得Git在版本控制方面非常强大且灵活。

如何列出Git中的所有标签？

在Git中，比较两次提交记录主要可以使用`git diff`命令来实现。这个命令可以展示两个提交之间的差异，包括文件的添加、修改和删除等。

### 使用方法

基本的命令格式是：

```bash
git diff <commit-id1> <commit-id2>
```

其中`<commit-id1>`和`<commit-id2>`分别代表要比较的两个提交的ID。

### 示例

假设有两个提交的哈希值分别是`abc123`和`def456`，我们可以使用以下命令来比较这两个提交：

```bash
git diff abc123 def456
```

这个命令会输出从`abc123`到`def456`的所有改动。输出结果中，会以不同的颜色标示出添加的行（绿色）和删除的行（红色）。

### 高级用法

1. **比较特定文件：** 如果你只对某个特定文件的更改感兴趣，可以在命令中指定文件名：

    ```bash
    git diff abc123 def456 -- path/to/file
    ```

2. **比较不同分支的最新提交：** 如果要比较两个分支的最新提交，可以直接使用分支名：

    ```bash
    git diff branch1 branch2
    ```

3. **图形化比较工具：** 对于不习惯命令行的用户，也可以使用图形化的Git工具，如GitKraken、SourceTree等，这些工具提供了更直观的界面来查看和比较代码的变更。

### 实际应用

在我之前的一个项目中，我们需要频繁地检查代码更改以确保代码质量和功能正确性。例如，在进行代码审查时，我们就会使用`git diff`来查看提交之间的具体更改，以便更快地定位可能的问题或进行改进建议。这大大提高了我们的工作效率和代码质量。

总之，`git diff`是一种非常有用的工具，可以帮助开发者理解代码变动情况，并确保项目按预期进行。

前端面试题手册