前端

服务端

计算机基础

Git pull request 是一个非常重要的功能，它允许开发者将自己的代码变更合并到主仓库中。这个过程中涉及到几个关键步骤：

1. **分支：** 开发者首先在本地仓库创建一个新的分支，用于开发新功能或修复bug。这样做的好处是可以保持主分支的稳定性，所有新的开发都在分支上进行。

2. **提交：** 在新分支上开发完成后，开发者会在本地仓库进行提交，保存改动。

3. **推送：** 将本地分支推送到远程仓库。这样其他开发者才能看到最新的变更。

4. **创建 Pull Request：** 开发者在GitHub或其他支持Git的平台上，从自己的分支向主分支发起一个Pull Request(PR)。这是一个请求，希望项目维护者审查代码，并将其合并到主分支。

5. **代码审查：** 项目维护者或其他团队成员可以查看变更，提出建议或要求修改。这个过程可以保证代码的质量，避免引入bug。

6. **合并：** 一旦Pull Request得到批准，它就可以被合并到主分支。这样，新的代码就会成为项目的一部分。

例如，在我之前的项目中，我们团队使用Git和GitHub来管理源代码。我负责一个新功能的开发，我在本地创建了一个名为`feature-x`的分支，并在这个分支上完成了开发。之后，我将这个分支推送到GitHub，并对主分支发起了一个Pull Request。我的团队成员对我的代码进行了审查，并提出了一些优化建议。我根据这些建议修改了代码，并更新了Pull Request。最终，我的代码通过审查并成功合并到了主分支。这个过程不仅确保了代码的质量，也促进了团队之间的沟通和协作。

什么是 Git pull request？

`.gitignore` 文件是一个文本文件，它告诉 Git 哪些文件或目录是可以被忽略的，不需要添加到版本控制系统中。当我们在使用 Git 进行项目管理时，通常会有一些文件或目录不需要或不应该被提交到远程仓库中，例如用户的敏感信息、编译生成的文件或者特定的配置文件等。

在 `.gitignore` 文件中，我们可以定义一系列规则来匹配需要忽略的文件或目录。这些规则可以使用通配符等方式来指定，比如：

- `*.log` 表示忽略所有扩展名为 `.log` 的文件。
- `build/` 表示忽略整个 `build` 目录。
- `!important.log` 表示不忽略 `important.log` 文件，即使它满足之前定义的忽略规则。

举个具体的例子，假设我在开发一个 Java 项目，通常会有编译生成的 `.class` 文件，这些文件没必要加入版本控制，因为它们可以从源代码重新编译生成。此时，我可以在 `.gitignore` 文件中添加如下规则：

```
*.class
```

这样，所有的 `.class` 文件都会被 Git 忽略，不会被误加入到版本库中，从而保持仓库的干净和管理的有效性。

什么是“.gitignore”文件？

`git checkout --track <remote/branch>` 命令的作用是创建一个新的本地分支，该分支跟踪指定的远程分支。这意味着您可以在本地对这个分支进行修改和更新，同时保持与远程分支的同步。

当您使用这个命令时，Git 会自动将本地分支设置为跟踪远程分支。这样做的好处包括：

1. **自动同步远程分支的变化**：当远程分支更新时，您可以通过 `git pull` 命令轻松地将这些更新拉取到本地分支。
2. **简化推送操作**：由于本地分支已设置为跟踪远程分支，因此在使用 `git push` 命令时无需指定远程仓库和分支名称。

### 示例：

假设您在团队中工作，团队使用名为 `origin` 的远程仓库，并在其中有一个名为 `feature-x` 的分支。您想在本地创建一个新分支来跟踪这个远程分支，并开始向该特性贡献代码。您可以执行以下命令：

```bash
git checkout --track origin/feature-x
```

执行此命令后，Git 会创建一个名为 `feature-x` 的本地分支，并自动设置为跟踪 `origin/feature-x`。这样，您就可以在本地工作并保持与远程分支的同步了。

“git checkout--track＜remote/branch＞”的作用是什么？

`git rm` 命令主要用于从工作目录和索引中删除文件。这意味着文件不再被 Git 跟踪。当文件从索引中移除后，它也会在下一次提交时从仓库中删除。

使用场景示例：

假设在一个项目中我们不再需要一个名为 `old_version.py` 的文件。为了从 Git 仓库中删除这个文件，我们可以使用以下命令：

```bash
git rm old_version.py
```

执行此命令后，`old_version.py` 会从工作目录中删除，并且此更改会被添加到暂存区，准备下一次提交。完成此操作后，我们需要进行提交，以使更改生效并更新仓库状态：

```bash
git commit -m "Remove old_version.py as it is no longer needed"
```

除了删除文件，`git rm` 还可以用于删除目录（使用 `-r` 参数来递归删除目录），或者用 `--cached` 选项从 Git 索引中删除文件而保留在工作目录中，这在处理误加入跟踪的文件时非常有用。

“git rm”有什么用？

**git checkout、git reset 和 git revert** 是 Git 中用于管理代码版本和历史的三个关键命令，它们各自有不同的用途和影响。

### git checkout

`git checkout` 主要用于切换分支或恢复工作目录中的文件。例如，如果我想切换到一个名为 `feature-x` 的分支，我会执行：

```bash
git checkout feature-x
```

此命令也可以用来检出某个特定的文件到一个指定的版本，比如我想将 `index.html` 文件恢复到上一个版本，可以使用：

```bash
git checkout HEAD^ index.html
```

### git reset

`git reset` 主要用于撤销过去的提交。它可以根据需要调整 HEAD（当前分支的指针），索引（暂存区），和工作目录的状态。

- 使用 `--soft` 参数，`git reset` 将 HEAD 移动到指定的提交，但不改变索引文件或工作目录。这常用于撤销一个还未推送的 commit，而保留所有文件的改动，以便重新提交。
  
  ```bash
  git reset --soft HEAD^
  ```

- 使用 `--mixed` 参数（默认选项），`git reset` 会将 HEAD 和索引都重置到指定的提交，但不改变工作目录。这对于撤销已暂存的文件很有用。
  
  ```bash
  git reset HEAD^
  ```

- 使用 `--hard` 参数，`git reset` 会将 HEAD、索引和工作目录都重置到指定的提交。这是一个危险的操作，因为它会丢失所有未提交的更改。
  
  ```bash
  git reset --hard HEAD^
  ```

### git revert

`git revert` 用于撤销一个特定的提交，但与 `git reset` 不同的是，它通过创建一个新的提交来实现这一点，这个新提交是旧提交的逆操作。这使得它成为一个在多人协作项目中更安全的选择，因为它不会改变项目的历史。

例如，如果我想撤销一个错误的提交（commit id 为 `a1b2c3d`），我可以使用：

```bash
git revert a1b2c3d
```

这会创建一个新的提交，其中包含了撤销 `a1b2c3d` 提交所做的所有更改。

### 总结

- **git checkout** 主要用于切换分支或恢复文件。
- **git reset** 主要用于撤销提交，并可以根据参数选择性地调整索引或工作目录。
- **git revert** 用于通过创建逆向提交来撤销过去的提交，这在多人协作环境中尤为重要。

这些命令的选择取决于你想要达成的目标和你的具体需求。

“git checkout”、“git reset”和“git revert”之间有什么区别？

**Git fsck** 的作用是用来检查并验证 Git 文件系统中的内部完整性。它全称是 "File System Consistency Check"，即“文件系统一致性检查”。这个命令会遍历所有的对象（包括提交、树、标签和blob对象）并检查它们的连接关系是否正常，以及内容的哈希值是否与存储时的哈希值相符，从而确保 Git 仓库的数据未被损坏或篡改。

### 如何使用 git fsck?

基本的使用方法是在命令行中输入：
```bash
git fsck
```
这条命令会检查仓库中所有的对象，列出存在的任何问题，比如悬空引用或损坏的对象等。

### 可选参数：
- `--verbose` 或 `-v`：显示所有被处理的对象，即使它们没有问题。
- `--full`：进行一次完全检查，这会花费更多的时间，但是检查更为彻底。
- `--dangling`：只报告悬挂对象（即在任何分支、标签或其他引用中没有引用的对象）。
- `--unreachable`：报告无法从任何引用到达的对象。
- `--no-reflogs`：在检查过程中忽略 reflog 中的引用。

### 示例：

假设你的 Git 仓库中可能因为某些操作错误或者其他原因导致了数据错误，你可以使用以下命令来检查：

1. 进行基本检查：
   ```bash
   git fsck
   ```

2. 使用详细模式，查看更多信息：
   ```bash
   git fsck --verbose
   ```

3. 查找悬空或未连接的对象：
   ```bash
   git fsck --dangling
   ```

这个命令在日常使用中比较少见，但在数据疑似被损坏或者进行系统迁移等情况下非常有用。例如，如果你从一个老旧的硬盘迁移到一个新硬盘，可以在迁移后使用 `git fsck` 来确保所有数据都被正确迁移无误。

“git fsck”的作用是什么？如何使用它？

**Git Stash** 是 Git 版本控制系统中的一个功能，主要用于临时保存还没有准备好提交的修改，从而让开发者可以干净地切换到别的分支进行工作。当你在一个分支上进行工作时，如果需要临时切换到另一个分支处理一些事情，而你当前的修改又不足以做一个完整的提交，这时你就可以使用 `git stash` 命令来保存当前工作进度。

`git stash` 会把你的工作区的和暂存区的改动保存起来，让工作目录回到最近一次的 commit 状态，从而可以切换分支而不影响当前分支。

### 使用场景示例：

假设我正在 `feature` 分支上开发一个新功能，此时需要紧急修复 `master` 分支上的一个 bug。我的当前工作还不完整，无法提交。这时，我可以使用以下命令：

```bash
git stash
```

此命令会保存我在 `feature` 分支上的改动，并将工作目录恢复到最近的 commit 状态。接下来，我可以安心切换到 `master` 分支进行 bug 修复。

修复完成后，我可以切换回 `feature` 分支，并使用以下命令恢复之前的工作状态：

```bash
git stash pop
```

这个命令会应用之前存储的 stash，并尝试将其从 stash 列表中移除。

总结来说，`git stash` 是处理多任务间切换的非常有用的工具，它确保你的工作目录和暂存区状态可以被保存和恢复，使得跨分支的工作变得更加灵活和安全。

什么是“git stash”？

**Git Submodule 有什么用？**

`git submodule` 是一个 Git 功能，它允许一个 Git 仓库中包含其他 Git 仓库作为子模块。这非常适用于以下场景：

1. **依赖管理**：当项目依赖其他特定版本的外部库或项目时，可以使用子模块来管理这些依赖。这确保了每个使用该项目的人都将使用完全相同版本的外部库。

2. **分离大项目**：对于大型项目，可以将项目拆分为多个逻辑上独立的部分或组件，每个部分作为一个单独的仓库开发和维护。这样可以提高代码的可维护性和可测试性。

例如，假设您正在开发一个大型 Web 应用，该应用使用了一个自定义的用户认证系统。为了保持主项目的简洁，您可以将用户认证系统作为独立的仓库开发，并作为子模块包含在主项目中。

**如何更新它？**

更新 git 子模块包含以下步骤：

1. **初始化子模块：** 如果是第一次检出包含子模块的仓库，需要使用 `git submodule init` 来初始化本地配置文件，并使子模块准备好被更新。

2. **更新子模块：** 使用 `git submodule update` 命令可以将子模块更新到在父仓库中记录的特定提交。如果需要将子模块更新到最新的提交，可以进入子模块的目录，切换到需要的分支（通常是 master 或 main），然后执行 `git pull`。

3. **提交更改：** 如果您更新了子模块到一个新的提交，并希望这个更新反映到主项目中，需要在主项目中提交这个更改。这通常包括对子模块的新提交进行 `git add` 和 `git commit`。

一个实际的例子是，如果你有一个名为 `ThirdPartyLibs` 的子模块，并且需要更新它到最新可用的版本，你可以这样做：

```bash
cd ThirdPartyLibs
git pull origin master
cd ..
git add ThirdPartyLibs
git commit -m "Update ThirdPartyLibs to latest version"
```

这个流程确保了你的主项目和子模块都被更新并记录了相应的改变。

“git submodule”有什么用？如何更新它？

**Git worktree** 是一个非常强大的 Git 功能，它允许用户在同一个仓库中同时检出多个工作树。这意味着你可以在不同的工作目录中处理同一个仓库的不同分支，而不需要进行常规的 `git checkout` 操作，这样可以避免工作目录中未提交的更改或者切换分支时的等待时间。

### 用途和优势：

1. **并行处理多个分支**：
   - 比如，你可以在一个工作树中处理新功能的开发（比如在 `feature` 分支），同时在另一个工作树中修复紧急bug（比如在 `hotfix` 分支）。这样可以轻松地在任务之间切换而不会相互影响。

2. **代码审查和测试**：
   - 当你需要审查或测试同事的代码时，你可以使用一个单独的工作树来检出他们的分支，同时保持你的主工作树干净整洁。这样做可以避免混合不同分支的代码导致的混乱。

3. **持续集成/持续部署（CI/CD）**：
   - 在自动化脚本中使用 worktree 可以同时在多个分支上触发构建和测试，这样做可以提高开发流程的效率和自动化水平。

### 实际示例：

假设你正在开发一个新功能，同时需要对生产环境中发现的一个严重错误进行快速修复。你可以这样操作：

1. 你已经在 `master` 分支的工作树中工作。
2. 使用命令 `git worktree add ../hotfix-branch hotfix` 创建一个新的工作树，专门用于修复bug。
3. 在 `hotfix-branch` 的工作树中，你可以修改代码并进行测试，而不会影响你在 `master` 分支的工作。
4. 一旦完成，你可以提交修复，并将更改合并回主分支或直接部署。

这个功能在管理复杂的项目和多任务处理时显得非常有效，可以大幅提高开发效率和团队的协作能力。

“git worktree”的用途是什么？

Git中的分支，是指在项目开发过程中，为了不同目的和任务创建的独立工作流。每个分支都是从项目的当前状态（通常是主分支，即`master`或`main`）开始，以隔离开发工作，防止对主分支的直接影响。当一个分支的开发工作完成后，它可以通过合并（merge）操作被整合回主分支中，或者与其他分支整合。

#### 分支的使用场景举例：

1. **功能开发（Feature branches）**：
   假设我们需要开发一个新的功能，比如说一个新的登录界面。为了不影响主分支上的现有代码，我们可以创建一个名为`feature-login`的分支。在这个分支上，开发人员可以自由实验和开发新功能，完成后通过代码审查和测试，再将其合并回主分支。

2. **修复错误（Bugfix branches）**：
   当在产品中发现一个严重的错误时，我们可能需要立即解决这个问题。创建一个`bugfix-error123`分支可以让我们专注于解决这个问题，而不干扰到主分支上正在进行的其他开发工作。修复完成后，该分支会被合并回主分支。

3. **实验（Experimental branches）**：
   如果开发人员想尝试一些高风险或不确定的新技术，他们可以创建一个实验性的分支，如`experimental-new-tech`。这样，他们可以在不影响主线产品稳定性的情况下自由探索和实验。

通过这样的分支管理，Git帮助团队维持代码的清晰和组织结构，同时提高了处理各种开发任务的灵活性和效率。

前端面试题手册