前端

服务端

计算机基础

Git是一个由林纳斯·托瓦兹为了更好地管理linux内核开发而创立的分布式版本控制／软件配置管理软件。需要注意的是和GNU Interactive Tools，一个类似Norton Commander界面的文件管理器相区分。



### Git 二等分（Bisect）的手动实现步骤

Git 的二等分（bisect）功能是一个非常有用的工具，它能帮助我们快速定位引入 bug 的具体提交（commit）。手动实现 Git 二等分的基本步骤如下：

#### 步骤 1: 确定好和坏的版本
首先，你需要明确哪一个版本是好的（没有bug），哪一个是坏的（有bug）。这通常基于你对项目历史的了解。假设你已经知道A版本是好的，B版本是坏的。

```bash
git checkout B  # B是坏的版本
git log  # 查看提交历史确定好的版本A的commit ID
```

#### 步骤 2: 开始二分查找
找到好的（good）和坏的（bad）提交后，你可以开始二分查找。在Git中，这通常通过一系列的checkout来实现，每次选取中间的提交进行测试。

```bash
git checkout A  # 先回到已知的好的版本
```

#### 步骤 3: 二分查找过程
你可以手动通过`git log`查找到A和B之间的提交列表，然后大致找到中间的提交。

```bash
git log --oneline A..B  # 查看A和B之间的提交列表
```

找到大致的中间提交后，用`git checkout <commit-id>`切换到该提交。

```bash
git checkout <mid-commit-id>  # 切换到中间的提交
```

#### 步骤 4: 测试当前版本
在当前提交（中间提交）上运行测试，以确认这个版本是好是坏。根据测试结果，你可以更新你的A（好的）或B（坏的）标记。

- 如果测试显示当前版本是好的，那么更新A到当前提交。
- 如果测试显示当前版本是坏的，那么更新B到当前提交。

```bash
# 如果当前提交是好的:
git checkout B  # 切换到坏的版本，继续查找
git log --oneline <mid-commit-id>..B

# 如果当前提交是坏的:
git checkout A  # 切换到好的版本，继续查找
git log --oneline A..<mid-commit-id>
```

#### 步骤 5: 重复步骤 3 和 4
继续重复步骤 3 和 4，每次都缩小查找范围，直到A和B相邻，这时B提交就是最初引入bug的地方。

这个过程虽然是手动的，但它帮助你理解Git二分查找的基本原理。在实际操作中，使用Git的内置`bisect`命令可以大大简化这一过程。

### 示例

假设在项目中发现一个bug，你确定在提交`abc123`（好的）和`def456`（坏的）之间引入了这个bug。

1. 查看这两个提交之间的提交列表，找到中间的提交`git log --oneline abc123..def456`。
2. 选择中间的提交进行测试。
3. 根据测试结果更新好或坏的标记。
4. 重复这个过程，直到找到bug的具体引入位置。

通过这种方式，尽管手动操作较为繁琐，但可以在没有自动工具支持的环境中进行有效的bug追踪。

如何手动实现 Git 二等分？

### Git中的“HEAD”、“working tree”和“index”区别：

#### 1. HEAD
**定义：** 
HEAD 是当前分支引用的符号名称，指向当前分支的最新提交。它基本上是一个指针，告诉 Git 当前在哪一个提交点。

**作用：**
HEAD 的主要作用是代表当前的工作环境。例如，在执行 `git commit` 操作时，HEAD 指向的提交会变成新提交的父提交。

**示例：**
如果你刚完成一个提交，HEAD 将指向这个最新的提交。

#### 2. Working Tree（工作树）
**定义：**
工作树，或称工作目录，是用户正在工作的目录。这里的文件都是可以直接被编辑和使用的。

**作用：**
工作树的作用是提供一个可视化的、可编辑的视图来反映某个特定的项目或目录的状态。用户对文件的任何修改都会首先出现在工作树中。

**示例：**
假如你正在编辑一个名为 `example.txt` 的文件，修改保存后，这个文件的改动就存在于工作树中。

#### 3. Index（索引或暂存区）
**定义：**
索引，也被称为暂存区，是一个准备好的区域，其内容会用来作为下一个提交的快照。这是一个中介层，允许开发者更精细地控制哪些改变应该进入下一个提交。

**作用：**
索引允许开发者构建提交的内容，可以选择性地添加或移除改动来准备最终的提交。这可以通过 `git add` 或 `git rm` 命令来管理。

**示例：**
如果你修改了 `example.txt` 并且想把这个修改包含到下一个提交中，你需要执行 `git add example.txt` 来更新索引以包括这个新的修改。

### 总结：
- **HEAD** 是一个指向你最后一次提交的指针，通常是当前分支的最新状态。
- **工作树** 是你的工作目录，包含了项目的当前文件和目录。
- **索引** 是一个暂存区，用于存储准备下一次提交的文件改动。

通过理解这三者的区别和联系，你可以更有效地使用 Git 来管理你的代码变更和版本历史。

Git中的“HEAD”、“working tree”和“index”有什么区别？

### 什么是 "git show"？

`git show` 是一个命令行工具，属于 Git 版本控制系统的一部分。它主要用于查看各种类型的 Git 对象（如提交、标签、树等）的详细信息。最常见的用途是查看特定提交的详细信息，包括内容的变更、提交者信息、提交日期等。

### 如何使用 “git show”？

`git show` 命令的基本用法非常直接。你只需要在命令行中输入 `git show` 后跟对象的标识符（如提交的 SHA-1 哈希）。这会显示该对象的详细信息，对于提交而言，它会显示与该提交相关的差异、提交消息、作者和日期等信息。

#### 示例：

假设你正在工作在一个项目中，并且想查看最近一次提交的详细信息。可以使用以下命令：

```bash
git show HEAD
```

这里，`HEAD` 是指向当前分支最新提交的指针。

如果你知道某个特定提交的哈希值，比如 `abc1234`，你可以直接使用：

```bash
git show abc1234
```

#### 进阶用法：

1. **查看特定文件的变更**：
   如果你只对某个特定文件的改动感兴趣，你可以在 `git show` 命令后面加上文件路径：

   ```bash
   git show HEAD:path/to/file
   ```

2. **格式化输出**：
   `git show` 提供了许多选项来格式化输出，例如 `--stat` 会显示每个文件的更改统计信息而不显示完整的 diff：

   ```bash
   git show --stat abc1234
   ```

3. **查看标签信息**：
   也可以用来查看标签的信息，包括该标签指向的提交：

   ```bash
   git show v1.0.0
   ```

这些是 `git show` 的基本用法和一些常见的高级用法。通过灵活使用这个命令，你可以有效地了解仓库的历史和特定变更的详细信息。

什么是“git show”？以及如何使用它？

### 什么是 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面试题手册