前端

服务端

计算机基础

在 Git 中，要列出与本地仓库关联的所有远程连接，可以使用 `git remote` 命令。这个命令不仅可以显示所有远程连接的简短名称，还可以通过添加 `-v` 选项来显示关联的 URL，提供更详细的信息。

例如，假设你正在管理一个项目，并已经添加了两个远程仓库，一个是 origin，另一个是 upstream。你可以这样列出所有远程连接：

```bash
git remote -v
```

这个命令将输出类似于以下内容：

```
origin  https://github.com/yourusername/yourproject.git (fetch)
origin  https://github.com/yourusername/yourproject.git (push)
upstream  https://github.com/otheruser/project.git (fetch)
upstream  https://github.com/otheruser/project.git (push)
```

在这个输出中，每个远程存储库都列出了两次，一次用于 fetch（拉取操作），一次用于 push（推送操作），因为这些操作可以关联到不同的 URL。在大多数情况下，fetch 和 push 的 URL 是相同的，除非你手动配置它们以使用不同的 URL。

这个命令非常有用，尤其是在加入新团队或接手现有项目时，可以快速了解配置的远程仓库及其角色。通过了解所有远程连接，可以有效地协调源代码的推送、拉取和合并操作，确保源代码管理的流畅性和一致性。

Git 如何列出存储库的所有远程连接？

在GitHub上更改pull request的基本分支是一个相对简单的操作，这可以在以下情况中非常有用：比如你创建了一个pull request，但是不慎将其指向了错误的分支，或者在代码审查过程中，团队决定将更改合并至另一个分支。

### 步骤如下：

1. **打开GitHub**：首先，登录到GitHub，并导航到相应的仓库(Repository)页面。

2. **找到Pull Request**：在仓库的主页上找到并点击“Pull requests”标签，然后选择你想要修改的pull request。

3. **编辑Pull Request**：在pull request页面，你会看到一个“Edit”按钮，位于标题右侧。点击这个按钮。

4. **更改基本分支**：
    - 在编辑模式下，你会看到一个名为“base”分支的下拉菜单。这就是当前pull request的目标分支。
    - 点击这个下拉菜单，选择一个新的基本分支。这个下拉菜单会列出所有可用的分支。

5. **保存更改**：选择好新的基本分支后，页面会自动刷新，并显示新基本分支与当前pull request中的更改之间的差异。确认这些更改是你所期望的，然后点击页面上的“Change base”按钮提交你的选择。

### 注意事项：

- **确保兼容性**：在更改基本分支之前，确保你的pull request的更改与新基本分支兼容，避免合并冲突。
- **通知团队成员**：如果这个变更影响到其他团队成员，确保及时通知他们。

### 实例：

假设我最初错误地将一个pull request指向了`master`分支，但后来意识到这些更改应该合并进`develop`分支。我将按照上述步骤更改基本分支，并且在操作前，我会检查`develop`分支的最新状态，确认没有冲突。操作完成后，我还会在团队的沟通渠道（如Slack或邮件）中告知相关同事。

通过这样的操作，我们可以确保代码整合的准确性和团队协作的有效性。

解释如何更改 pull request 的基本分支。

在Git中，别名（alias）可以帮助简化命令，使得复杂的命令序列更容易记忆和执行。要列出Git中设置的所有别名，您可以使用Git的配置系统。具体命令如下：

```bash
git config --get-regexp alias
```

这条命令会检索Git配置文件（通常是`.gitconfig`或者位于仓库`.git/config`中的文件），查找所有以“alias”开头的配置项，并将它们显示出来。每个别名都会按照`alias.<name> <command>`的格式列出，其中`<name>`是别名的名称，`<command>`是与之对应的Git命令。

例如，如果您之前设置了以下别名：

- 将 `git cm` 设为 `git commit -m`
- 将 `git st` 设为 `git status`
- 将 `git lg` 设为 `git log --graph --oneline`

执行 `git config --get-regexp alias` 后的输出将类似于：

```
alias.cm commit -m
alias.st status
alias.lg log --graph --oneline
```

这样您就可以快速查看所有已设置的别名及其对应的Git命令。

如何列出Git中设置的所有别名？

`git stash drop` 是 Git 版本控制系统中的一个命令，它用于删除存储堆栈中的一个存储项。Git 的存储（stash）功能允许开发者临时保存他们未完成的工作，以便可以在不提交不完整变更的情况下，切换分支或执行其他版本控制操作。

当使用 `git stash` 命令时，所有当前的更改（包括暂存的和非暂存的更改）都会被保存起来，这个过程称为“stashing”。这样做可以让开发者得到一个干净的工作目录，从而可以自由地切换到其他任务上。在默认情况下，每次使用 `git stash` 时，都会在 stash 列表中创建一个新的条目。

有时候，开发者可能决定某个已经保存的 stash 项不再需要了，这时候就可以使用 `git stash drop` 命令来删除它。如果不指定具体的 stash 项，默认情况下 `git stash drop` 会删除最新的 stash 项，也就是说 `stash@{0}`。如果想要删除特定的 stash 项，可以在命令后面指定它的编号，比如 `git stash drop stash@{2}`。

### 例子

假设一个开发者正在修复一个bug，但突然需要切换到另一个分支处理一个紧急问题。他可以使用以下命令保存当前的工作进度：

```bash
git stash
```

处理完紧急问题并切换回原来的分支后，他可能决定不再需要先前保存的那些更改，此时可以使用：

```bash
git stash drop
```

这样，最近一次保存的更改就会被从存储堆栈中移除。如果他有多个 stash 项，并且想要删除特定的一个，他可以查看所有存储的列表：

```bash
git stash list
```

然后根据需要删除特定编号的stash项：

```bash
git stash drop stash@{2}
```

这将删除在存储堆栈中编号为2的stash项。

什么是“git stash drop”？

**Git Archive** 是一个 Git 命令，它的主要功能是创建一个项目历史中特定的版本或者说快照的压缩包。这个命令对于将项目的特定快照导出为归档文件非常有用，特别是在需要部署或共享代码但不包含.git目录时。

例如，如果您想要生成当前分支最新提交的归档文件，可以使用以下命令：

```bash
git archive --format=zip --output=/path/to/output.zip HEAD
```

这个命令会创建一个zip格式的归档文件，包含HEAD（即当前分支最新提交）的内容，存储在指定的输出路径。

`git archive` 命令非常灵活，支持多种输出格式（如 tar, tar.gz, zip 等），同时也允许用户指定要导出的文件或目录，使其更加符合用户的具体需求。

一个常见的场景是在部署代码到生产环境时，可能不希望包含版本控制目录 .git，这时就可以使用 `git archive` 来生成一个干净的代码包。这样做既可以减少部署的文件大小，也增加了部署过程的安全性。

什么是“git archive”？

**Git Pull vs Git Fetch**

`git pull` 和 `git fetch` 都是 Git 命令，用于从远端仓库更新本地仓库的代码，但它们在功能上有明显的区别。

### git fetch
- **功能**: `git fetch` 仅仅下载远程仓库的最新数据到本地，但不会自动合并到当前工作分支。
- **用途**: 这个命令用于获取远程仓库的数据，了解变更，但不立即影响你的本地工作环境。这样做的好处是可以先审查这些变更，在合并前有选择性地检查或测试这些变更。
- **行为**: 它会将远端的分支状态更新到本地仓库的对应远端分支（通常是 `origin/master`），但不影响你的本地分支，保持你的当前工作不变。

### git pull
- **功能**: `git pull` 事实上是 `git fetch` 后面跟了一个 `git merge`。这意味着，当执行 `git pull` 时，Git 不仅会下载远程仓库的最新数据，还会将这些新数据合并到当前分支中。
- **用途**: 这个命令用于将远程仓库的变更直接下载并合并到你的本地分支，自动更新你的工作目录。
- **行为**: 如果合并是必要的，即本地分支落后于对应的远端分支，它会自动进行合并。如果合并顺利，本地分支将更新至最新状态。

### 使用场景和例子
假设你在开发一个功能，在 `feature` 分支上工作。你的同事刚刚更新了 `master` 分支并推送到了 GitHub。

- **使用 `git fetch`**: 你可以执行 `git fetch origin master` 来查看他们的改动，而你当前的开发不会受到影响。之后，你可以用 `git diff origin/master` 来比较本地 `master` 分支和远端 `master` 分支的差异，决定是否合并这些改动到你的 `feature` 分支。

- **使用 `git pull`**: 如果你直接在 `feature` 分支上执行 `git pull origin master`，那么远程的 `master` 分支的更新将被直接合并到你的 `feature` 分支中。如果你确定这些改动不会破坏你当前的工作或者你需要这些改动来继续开发，这会是一个快速的方式来更新你的分支。

通过以上解释和例子，你可以看到 `git fetch` 和 `git pull` 在实际使用上的差异，以及根据不同的需求选择使用哪一个命令。

`git pull `与`git fetch`的区别是什么？

`git blame -L` 命令在 Git 版本控制系统中用于显示特定文件的每一行的最后修改内容和修改者的信息，而 `-L` 参数允许用户指定显示文件中特定行号范围的更改信息。

例如，如果您想要查看一个名为 `example.txt` 的文件中第10行到第20行的修改记录，您可以使用以下命令：

```bash
git blame -L 10,20 example.txt
```

这个命令会列出 `example.txt` 文件中第10行到第20行每一行的最后修改者、最后修改的 commit ID 和行内容。

这个功能对于代码审查和理解特定代码段历史变更的背景非常有用。它可以帮助开发者快速识别谁最后修改了代码，以及相关的修改是在什么背景下进行的。

“git blame -L”的作用是什么？

`git checkout -- <file>`命令的作用是用来恢复工作区的特定文件到最近一次`git commit`或`git add`时的状态。它是Git版本控制系统中用于放弃对文件的本地修改的一个常用命令。

举个例子，假设你正在开发一个项目，对文件`example.txt`进行了一些修改后，发现这些修改是错误的或者不再需要。此时，你希望撤销这些更改，回到最后一次提交或添加到暂存区的状态。你可以使用以下命令来实现：

```
git checkout -- example.txt
```

执行这个命令后，`example.txt`文件会被恢复到它在最近一次commit或add时的状态，你的本地修改将会被丢弃。这对于快速撤销错误的更改非常有用，可以帮助保持代码库的整洁和稳定。

“git checkout--<file>”的作用是什么？

`git cherry-pick` 是一个非常有用的 Git 命令，它允许你选择一个或多个在其他分支上进行的提交，并将它们复制到你当前所在的分支。这个命令的主要作用是实现精细的版本控制和问题修复，可以帮助开发人员在不影响整个项目历史的情况下，将特定的改动应用到不同的分支上。

例如，假设你正在一个名为 `feature` 的分支上工作，突然你接到一个紧急任务，需要修复主分支 `master` 上的一个严重bug。你在 `master` 分支上创建了一个修复该 bug 的新分支 `bugfix`。修复完成后，你意识到这个修复对你当前的 `feature` 分支也是有益的。你可以使用 `git cherry-pick` 命令来选择性地将这个修复提交应用到 `feature` 分支上，而不需要重写代码或合并整个 `bugfix` 分支，这样可以避免引入不相关的更改。

使用方法示例：
1. 首先，你需要知道你想要复制的提交的哈希值。可以通过 `git log` 查看提交历史获取。
2. 然后，切换到你想要应用这个提交的分支。例如：`git checkout feature`
3. 使用命令 `git cherry-pick [commit-hash]` 将特定的提交应用到当前分支。

这样，你就可以灵活地管理各种修复和改进，而不必担心分支间复杂的依赖关系。

“git cherry-pick”的作用是什么？

`git-rebase`是一个Git命令，用于整合来自一个分支的修改到另一个分支。它的核心作用是修改提交历史的顺序，从而使之成为一条直线。

具体来说，当你进行rebase操作时，Git会找到两个分支（当前分支和目标基底分支）的共同祖先，然后将当前分支上在这个共同祖先之后的提交暂时保存为补丁（patches），这一过程称为`detaching`。之后，Git将当前分支的指针移动到目标基底分支的最新提交上，最后将之前保存的补丁依次应用到当前分支上。

例如，假设我们有两个分支，一个是`feature`分支，另一个是`master`分支。你在`feature`分支上完成了一些功能开发，而此时`master`分支上也有其他人提交了新的更改。如果你想将这些新的更改整合到你的`feature`分支，你可以使用`git rebase master`命令，这样`feature`分支上的的提交就会重新基于`master`分支的最新提交。

与`git-rebase`不同的是，`git-merge`也是Git中用于整合不同分支的更改的命令，但它的处理方式不同。`git-merge`会生成一个新的提交，这个提交同时指向两个合并分支的最新提交（即两个父提交）。这意味着，它不会改变现有分支的提交历史，而是在历史之上增加一个新的合并点。

举个例子，继续上述的`feature`和`master`分支的情况，如果你选择使用`git merge master`在`feature`分支上，Git会创建一个新的提交，这个提交有两个父节点：一个是`feature`分支的最新提交，另一个是`master`分支的最新提交。这样，`feature`分支的历史将包含两个分支的所有提交。

总结来说，`git-rebase`提供了一种更干净的线性历史，但可能会改变提交历史。这在某些情况下可以使版本历史更清晰易懂。而`git-merge`保留了原有分支的历史，适合在需要保持分支历史不变的情境中使用。在实际工作中，选择使用哪一个命令往往取决于团队的工作流程和偏好。

前端面试题手册